文/升哲科技劉鵬

摘要：本文主要描述升哲科技在打造物聯(lián)智慧城市平臺過程中關(guān)于如何實現(xiàn)延時隊列服務(wù)的技術(shù)選型經(jīng)驗、延時隊列服務(wù)的架構(gòu)設(shè)計以及延時隊列的底層細節(jié)實現(xiàn)原理。

背景

升哲科技是一家物聯(lián)網(wǎng)與人工智能領(lǐng)域的國家高新技術(shù)企業(yè)、獨角獸企業(yè)。

要打造物聯(lián)智慧城市平臺，在業(yè)務(wù)中涉及到各種延時任務(wù)的需求，例如設(shè)備定時空氣開關(guān)，定時更新設(shè)備狀態(tài)，定時提醒等等，基于這些需求，需要一個可靠、實時、海量的延時隊列服務(wù)作為基礎(chǔ)設(shè)施。

那么延時隊列是什么呢？延時隊列不同于消息隊列按照先入先出（FIFO）的順序來消費，而是根據(jù)消息指定時間延時消費。延時隊列的使用在我們?nèi)粘?yīng)用也非常多，比如：

· 在電商平臺購物，在30分鐘內(nèi)沒有支付自動取消訂單；

· 待處理的工單超過1天未處理，二次發(fā)送提醒。

以上場景往往都需要延時隊列實現(xiàn)。

早期延時隊列的實現(xiàn)采用了數(shù)據(jù)庫掃表方式，服務(wù)定期查詢到期的任務(wù)，再通過Kafka來中轉(zhuǎn)消息。當(dāng)任務(wù)量小，延時精度要求低時掃表方式還能應(yīng)對，然而隨著業(yè)務(wù)增長、任務(wù)數(shù)量不斷增多，延時時間精度要求也變高，掃表的方式已經(jīng)無法滿足我們的業(yè)務(wù)，于是我們開始探索新的技術(shù)方案來支撐百萬級任務(wù)的延時隊列。

延時隊列的設(shè)計目標(biāo)

1.高可用：多副本部署，保證服務(wù)不出現(xiàn)單點故障；

2.可擴展：可隨著業(yè)務(wù)量增長來擴容，同時生產(chǎn)消費的請求延時也要低；

3.兼容舊接口，保證舊的服務(wù)不需要做任何修改；

4.消息傳遞可靠，至少保證一次送達。

技術(shù)選型

在開源社區(qū)已經(jīng)存在一些解決方案：

考慮到運維難度和可擴展性，最終我們選擇了開源項目Lmstfy作為基礎(chǔ)來進行二次開發(fā)，選擇Lmstfy的原因如下：

● 無狀態(tài)服務(wù)，使用Redis來持久化，Redis的高可用方案已經(jīng)非常成熟，在公/私有云都有Paas服務(wù)可使用；

● 支持擴容，可以配置多個Redis集群；

● 提供Java/Go/Rust/PHP客戶端，監(jiān)控面板完善；

● 采用Golang開發(fā)，高并發(fā)性能優(yōu)秀，也方便后續(xù)二次開發(fā)。

整體架構(gòu)設(shè)計

1.Delayer：無狀態(tài)服務(wù)，提供給業(yè)務(wù)服務(wù)調(diào)用，兼容舊接口，在Delayer這一層直接操作Redis實現(xiàn)了任務(wù)刪除和更新任務(wù)等等功能；

2.Lmstfy：無狀態(tài)服務(wù)，提供延時隊列基礎(chǔ)服務(wù)，底層實現(xiàn)采用；

3.Redis Sentinel集群：保證Redis發(fā)生故障時自動主備切換。

基礎(chǔ)概念

● namespace -用于隔離業(yè)務(wù)，也可以通過配置namespace綁定不同的Redis集群;

● queue -隊列，用區(qū)分同一業(yè)務(wù)不同消息類型；

● job -業(yè)務(wù)定義的業(yè)務(wù)，主要包含以下幾個屬性:

○ id:任務(wù) ID，全局唯一；

○ delay:任務(wù)延時下發(fā)時間，單位是秒；

○ tries:任務(wù)最大重試次數(shù)，tries = N表示任務(wù)會最多下發(fā) N次；

○ ttr(time to run):任務(wù)預(yù)期執(zhí)行時間，超過 ttr則認為任務(wù)消費失敗，觸發(fā)任務(wù)自動重試。

數(shù)據(jù)存儲

Lmstfy的 Redis存儲由四部分組成:

● Timer:使用ZSET結(jié)構(gòu)來存儲延時任務(wù)，Score即任務(wù)的到期時間來排序；

● Ready queue - 使用LIST結(jié)構(gòu),存儲已經(jīng)到期的延時任務(wù),實現(xiàn)FIFO消費；

● Deadletter-使用LIST結(jié)構(gòu)，消費失敗(重試次數(shù)到達上限)的任務(wù)，可以手動重新放回到隊列;

● Job pool– string類型，存儲消息meta信息；

● Job mapping - string -存儲應(yīng)用自定義id和job的關(guān)聯(lián)關(guān)系。

創(chuàng)建任務(wù)

創(chuàng)建任務(wù)會生成一個Job ID, Job ID包括寫入時間戳、隨機數(shù)和延時時長，然后將任務(wù)的meta信息寫入Redis，Key為 j/{namespace}/queue/{id}，當(dāng)任務(wù)延時時間（delay）= 0，(實時消息隊列我們使用Kafka)表示不需要延時則直接寫到 Ready Queue(List)，當(dāng)延時時間（delay） = n(n > 0)，表示需要延時，將延時加上當(dāng)前系統(tǒng)時間作為絕對時間戳寫到 Timer(sorted set)，Timer的實現(xiàn)是利用 ZSET根據(jù)絕對時間戳進行排序，再由一個goroutine定期輪詢將到期的任務(wù)通過 redis lua script來將數(shù)據(jù)轉(zhuǎn)移到 Ready Queue(List)中。

任務(wù)消費

支持延時的任務(wù)隊列本質(zhì)上是兩個數(shù)據(jù)結(jié)構(gòu)的結(jié)合: Ready Queue（LIST）和 Sorted Set。

Sorted Set用來實現(xiàn)延時的部分，將任務(wù)按照到期時間戳升序存儲，隨后定期將到期的任務(wù)遷移至 Ready Queue(LIST)。

任務(wù)的具體內(nèi)容只會存儲一份在 Job pool里面，其他的如 Ready Queue只是存儲Job id，這樣可以節(jié)省內(nèi)存空間。

任務(wù)更新和刪除

Lmstfy本身不支持刪除和更新，我們在Delayer層中在創(chuàng)建任務(wù)同時在Redis中創(chuàng)建了一個Mapping Key，客戶端可以自定一個ID關(guān)聯(lián)到Job id，Delayer提供了刪除和更新（先刪除再創(chuàng)建）API，我們業(yè)務(wù)還需要支持多次執(zhí)行的功能，在處理Job Ack時根據(jù)任務(wù)參數(shù)重新插入隊列，結(jié)合我們二次開發(fā)整體結(jié)構(gòu)如下：

性能表現(xiàn)

通過本地限定1核CPU壓測生產(chǎn)消息數(shù)據(jù)如下：

200萬任務(wù)量占內(nèi)存600MB+，其中包括mapping key導(dǎo)致key數(shù)量翻倍。

以下是單核CPU的環(huán)境下壓測結(jié)果，任務(wù)創(chuàng)建可高達1500TPS：

延時任務(wù)到期時間比較分散的情況下，消費表現(xiàn)如下接800TPS：

總結(jié)

封裝lmstfy的方案已足夠支撐當(dāng)前的使用場景，但還是有一些不足之處，比如：

● 在Delayer中操作Redis中的任務(wù)，無法保證原子性；

● 任務(wù)創(chuàng)建和消費另外會多一次網(wǎng)絡(luò)請求，產(chǎn)生不必要的開銷；

● 無法支持循環(huán)任務(wù)；

● Lmstfy采用HTTP協(xié)議，無法發(fā)揮更好性能。

未來，我們計劃融合兩個服務(wù)，完善任務(wù)CRUD功能，減少網(wǎng)絡(luò)開銷，并采用GRPC來替換HTTP協(xié)議通訊。