文/升哲科技劉鵬

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

背景

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

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

那么延時隊列是什么呢？延時隊列不同于消息隊列按照先入先出（FIFO）的順序來消費，而是根據(jù)消息指定時間延時消費。延時隊列的使用在我們?nèi)粘靡卜浅６?，比如?/p>

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

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

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

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

延時隊列的設計目標

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

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

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

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

技術選型

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

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

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

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

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

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

整體架構(gòu)設計

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

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

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

基礎概念

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

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

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

○ id:任務 ID，全局唯一；

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

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

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

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

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

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

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

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

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

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

創(chuàng)建任務

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

任務消費

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

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

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

任務更新和刪除

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

性能表現(xiàn)

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

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

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

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

總結(jié)

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

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

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

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

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

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