快速實現一個分佈式定時器

作者：劉若愚，騰訊 WXG 後臺開發工程師

定時器（Timer）是一種在業務開發中常用的組件，主要用在執行延時通知任務上。本文以筆者在工作中的實踐作爲基礎，介紹如何使用平時部門最常用的組件快速實現一個業務常用的分佈式定時器服務。同時介紹了過程中遇到問題的一些解決方案，希望能夠給類似場景提供一些解決思路。

1. 什麼是定時器

定時器（Timer）是一種在指定時間開始執行某一任務的工具（也有周期性反覆執行某一任務的 Timer，我們這裏暫不討論）。它常常與延遲隊列這一概念關聯。那麼在什麼場景下我才需要使用定時器呢？

我們先看看以下業務場景：

爲了解決以上問題，最簡單直接的辦法就是定時去掃表。每個業務都要維護一個自己的掃表邏輯。當業務越來越多時，我們會發現掃表部分的邏輯會非常類似。我們可以考慮將這部分邏輯從具體的業務邏輯裏面抽出來，變成一個公共的部分。這個時候定時器就出場了。

2. 定時器的本質

一個定時器本質上是這樣的一個數據結構：deadline 越近的任務擁有越高優先級，提供以下幾種基本操作：

  1. Add 新增任務；

  2. Delete 刪除任務；

  3. Run 執行到期的任務 / 到期通知對應業務處理；

  4. Update 更新到期時間 (可選)。

Run 通常有兩種工作方式：1. 輪詢 每隔一個時間片就去查找哪些任務已經到期；2. 睡眠 / 喚醒 不停地查找 deadline 最近的任務，如到期則執行；否則 sleep 直到其到期。在 sleep 期間，如果有任務被 Add 或 Delete，則 deadline 最近的任務有可能改變，線程會被喚醒並重新進行 1 的邏輯。

它的設計目標通常包含以下幾點要求：

  1. 支持任務提交（消息發佈）、任務刪除、任務通知（消息訂閱）等基本功能。

  2. 消息傳輸可靠性：消息進入延遲隊列以後，保證至少被消費一次（到期通知保證 At-least-once ，追求 Exactly-once）。

  3. 數據可靠性：數據需要持久化，防止丟失。

  4. 高可用性：至少得支持多實例部署。掛掉一個實例後，還有後備實例繼續提供服務，可橫向擴展。

  5. 實時性：盡最大努力準時交付信息，允許存在一定的時間誤差，誤差範圍可控。

3. 數據結構

下面我們談談定時器的數據結構。定時器通常與延遲隊列密不可分，延時隊列是什麼？顧名思義它是一種帶有延遲功能的消息隊列。而延遲隊列底層通常可以採用以下幾種數據結構之一來實現：

  1. 有序鏈表，這個最直觀，最好理解。

  2. 堆，應用實例如 Java JDK 中的 DelayQueue、Go 內置的定時器等。

  3. 時間輪 / 多級時間輪，應用實例如 Linux 內核定時器、Netty 工具類 HashedWheelTimer、Kafka 內部定時器等。

這裏重點介紹一下時間輪（TimeWheel）。一個時間輪是一個環形結構，可以想象成時鐘，分爲很多格子，一個格子代表一段時間（越短 Timer 精度越高），並用一個 List 保存在該格子上到期的所有任務，同時一個指針隨着時間流逝一格一格轉動，並執行對應 List 中所有到期的任務。任務通過取模決定應該放入哪個格子。示意圖如下所示：

時間輪

如果任務的時間跨度很大，數量也多，傳統的單輪時間輪會造成任務的 round 很大，單個格子的任務 List 很長，並會維持很長一段時間。這時可將 Wheel 按時間粒度分級（與水錶的思想很像），示意圖如下所示：

多級時間輪. png

時間輪是一種比較優雅的實現方式，且如果採用多級時間輪時其效率也是比較高的。

4. 業界實現方案

業界對於定時器 / 延時隊列的工程實踐，則通常基於以下幾種方案來實現:

  1. 基於 Redis ZSet 實現。

  2. 採用某些自帶延時選項的隊列實現，如 RabbitMQ、Beanstalkd、騰訊 TDMQ 等。

  3. 基於 Timing-Wheel 時間輪算法實現。

5. 方案詳述

介紹完定時器的背景知識，接下來看下我們系統的實現。我們先看一下需求背景。在我們組的實際業務中，有延遲任務的需求。一種典型的應用場景是：商戶發起扣費請求後，立刻爲用戶下發扣費前通知，24 小時後完成扣費；或者發券給用戶，3 天后通知用戶券過期。基於這種需求背景，我們引出了定時器的開發需求。

我們首先調研了公司內外的定時器實現，避免重複造輪子。調研了諸如例如公司外部的 Quartz、有讚的延時隊列等，以及公司內部的 PCG tikker、TDMQ 等，以及微信支付內部包括營銷、代扣、支付分等團隊的一些實現方案。最後從可用性、可靠性、易用性、時效性以及代碼風格、運維代價等角度考慮，我們決定參考前人的一些優秀的技術方案，並根據我們團隊的技術積累和組件情況，設計和實現一套定時器方案。

首先要確定定時器的存儲數據結構。這裏借鑑了時間輪的思想，基於微信團隊最常用的存儲組件 tablekv 進行任務的持久化存儲。使用到 tablekv 的原因是它天然支持按 uin 分表，分表數可以做到千萬級別以上；其次其單表支持的記錄數非常高，讀寫效率也很高，還可以如 mysql 一樣按指定的條件篩選任務。

我們的目標是實現秒級時間戳精度，任務到期只需要單次通知業務方。故我們方案主要的思路是基於 tablekv 按任務執行時間分表，也就是使用使用方指定的 start_time（時間戳）作爲分表的 uin，也即是時間輪 bucket。爲什麼不使用多輪時間輪？主要是因爲首先 kv 支持單表上億數據， 其二 kv 分表數可以非常多，例如我們使用 1000 萬個分表需要約 115 天的間隔纔會被哈希分配到同一分表內。故暫時不需要使用到多輪時間輪。

最終我們採用的分表數爲 1000w，uin = 時間戳 mod 分表數。這裏有一個注意點，通過 mod 分表數進行 Key 收斂, 是爲了避免時間戳遞增導致的 key 無限擴張的問題。示例圖如下所示：

kv 時間輪. png

任務持久化存儲之後，我們採用一個 Daemon 程序執行定期掃表任務，將到期的任務取出，最後將請求中帶的業務信息（biz_data 添加任務時帶來，定時器透傳，不關注其具體內容）回調通知業務方。這麼一看流程還是很簡單的。

這裏掃描的流程類似上面講的時間輪算法，會有一個指針（我們在這裏不妨稱之爲 time_pointer）不斷向後移動，保證不會漏掉任何一個 bucket 的任務。這裏我們採用的是 commkv（可以簡單理解爲可以按照 key-value 形式讀寫的 kv，其底層仍是基於 tablekv 實現）存儲 CurrentTime，也就是當前處理到的時間戳。每次輪詢時 Daemon 都會通過 GetByKey 接口獲取到 CurrentTime，若大於當前機器時間，則 sleep 一段時間。若小於等於當前機器時間，則取出 tablekv 中以 CurrentTime 爲 uin 的分表的 TaskList 進行處理。本次輪詢結束，則 CurrentTime 加一，再通過 SetByKey 設置回 commkv。這個部分的工作模式我們可以簡稱爲 Scheduler。

Scheduler 拿到任務後只需要回調通知業務方即可。如果採用同步通知業務方的方式，由於業務方的超時情況是不可控的，則一個任務的投遞時間可能會較長，導致拖慢這個時間點的任務整體通知進度。故而這裏自然而然想到採用異步解耦的方式。即將任務發佈至事件中心（微信內部的高可用、高可靠的消息平臺，支持事務和非事務消息。

由於一個任務的投遞到事件中心的時間僅爲幾十 ms，理論上任務量級不大時 1s 內都可以處理完。此時 time_pointer 會緊跟當前時間戳。當大量任務需要處理時，需要採用多線程 / 多協程的方式併發處理，保證任務的準時交付。broker 訂閱事件中心的消息，接受到消息後由 broker 回調通知業務方，故 broker 也充當了 Notifier 的角色。整體架構圖如下所示：

架構圖小. png

主要模塊包括：

任務掃描 Daemon：充當 Scheduler 的角色。掃描所有到期任務，投遞到事件中心，讓它通知 broker，由 broker 的 Notifier 通知業務方。

定時器 broker：集業務接入、Notifier 兩者功能於一身。

任務狀態機圖如下所示，只有兩種狀態。當任務插入 kv 成功時即爲 pending 狀態，當任務成功被取出並通知業務方成功時即爲 finish 狀態。

狀態圖. png

6. 實現細節與難點思考

下面就上面的方案涉及的幾個技術細節進行進一步的解釋。

6.1 業務隔離

通過 biz_type 定義不同的業務類型，不同的 biz_type 可以定義不同的優先級（目前暫未支持），任務中保存 biz_type 信息。業務信息（主鍵爲 biz_type）採用境外配置中心進行配置管理。方便新業務的接入和配置變更。業務接入時，需要在配置中添加諸如回調通知信息、回調重試次數限制、回調限頻等參數。業務隔離的目的在於使各個接入業務不受其他業務的影響，這一點由於目前我們的定時器用於支持本團隊內部業務的特點，僅採取對不同的業務執行不同業務限頻規則的策略，並未做太多優化工作，就不詳述了。

6.2 時間輪空轉問題

由於 1000w 分表，肯定是大部分 Bucket 爲空，時間輪的指針推進存在低效問題。聯想到在飯店排號時，常有店員來登記現場尚存的號碼，就是因爲可以跳過一些號碼，加快叫號進度。同理，爲了減少這種 “空推進”，Kafka 引入了 DelayQueue，以 bucket 爲單位入隊，每當有 bucket 到期，即 queue.poll 能拿到結果時，才進行時間的 “推進”，減少了線程空轉的開銷。在這裏類似的，我們也可以做一個優化，維護一個有序隊列，保存表不爲空的時間戳。大家可以思考一下如何實現，具體方案不再詳述。

6.3 限頻

由於定時器需要寫 kv，還需要回調通知業務方。因此需要考慮對調用下游服務做限頻，保證下游服務不會雪崩。這是一個分佈式限頻的問題。這裏使用到的是微信支付的限頻組件。保證 1. 任務插入時不超過定時器管理員配置的頻率。2.Notifier 回調通知業務方時不超過業務方申請接入時配置的頻率。這裏保證了 1.kv 和事件中心不會壓力太大。2. 下游業務方不會受到超過其處理能力的請求量的衝擊。

6.4 分佈式單實例容災

出於容災的目的，我們希望 Daemon 具有容災能力。換言之若有 Daemon 實例異常掛起或退出，其他機器的實例進程可以繼續執行任務。但同時我們又希望同一時刻只需要一個實例運行，即 “分佈式單實例”。所以我們完整的需求可以歸納爲 “分佈式單實例容災部署”。

實現這一目標，方式有很多種，例如：

主要從開發成本，運維支撐兩方面來考慮，選取了基於 chubby 分佈式鎖的方案來實現單實例容災部署。這也使得我們真正執行業務邏輯的機器具有隨機性。

6.5  可靠交付

這是一個核心問題，如何保證任務的通知滿足 At-least-once 的要求？

我們系統主要通過以下兩種方式來保證。

  1. 任務達到時即存入 tablekv 持久化存儲，任務成功通知業務方纔設置過期（保留一段時間後刪除），故而所有任務都是落地數據，保證事後可以對賬。

  2. 引入可靠事件中心。在這裏使用的是事件中心的普通消息，而非事務消息。實質是當做一個高可用性的消息隊列。

這裏引入消息隊列的意義在於：

事件中心相比普通的消息隊列還具有哪些優點呢？

事件中心的引入，基本保證了任務從 Scheduler 到 Notifier 的可靠性。

當然，最爲完備的方式，是增加另一個異步 Daemon 作爲兜底策略，掃出所有超時還未交付的任務進行投遞。這裏思路較爲簡單，不再詳述。

6.6 及時交付

若同一時間點有大量任務需要處理，如果採用串行發佈至事件中心，則仍可能導致任務的回調通知不及時。這裏自然而然想到採用多線程 / 多協程的方式併發處理。在本系統中，我們使用到了微信的 BatchTask 庫，BatchTask 是這樣一個庫，它把每一個需要併發執行的 RPC 任務封裝成一個函數閉包（返回值 + 執行函數 + 參數），然後調度協程（BatchTask 的底層協程爲 libco）去執行這些任務。對於已有的同步函數，可以很方便的通過 BatchTask 的 Api 去實現任務的批量執行。Daemon 將發佈事件的任務提交到 BatchTask 創建的線程池 + 協程池（線程和協程數可以根據參數調整）中，充分利用流水線和併發，可以將任務 List 處理的整體時延大大縮短，盡最大努力及時通知業務方。

6.7 任務過期刪除

從節省存儲資源考慮，任務通知業務成功後應當刪除。但刪除應該是一個異步的過程，因爲還需要保留一段時間方便查詢日誌等。這種情況，通常的實現方式是啓動一個 Daemon 異步刪除已完成的任務。我們系統中，是利用了 tablekv 的自動刪除機制，回調通知業務完成後，除了設置任務狀態爲完成外，同時通過 tablekv 的 update 接口設置 kv 的過期時間爲 1 個月，避免了異步 Daemon 掃表刪除任務，簡化了實現。

6.8 其他風險項

  1. 由於 time_pointer 的 CurrentTime 初始值置爲首次運行的 Daemon 實例的機器時間，而每次輪詢時都會對比當前 Daemon 實例的機器時間與 CurrentTime 的差別，故機器時間出錯可能會影響任務的正常調度。這裏考慮到現網機器均有時間校正腳本在跑，這個問題基本可以忽略。

  2. 本系統的架構對事件中心構成了強依賴。定時器的可用性和可靠性依賴於事件中心的可用性和可靠性。雖然目前事件中心的可用性和可靠性都非常高，但如果要考慮所有異常情況，則事件中心的短暫不可用、或者對於訂閱者消息出隊的延遲和堆積，都是需要正視的問題。一個解決方案是使用 MQ 做雙鏈路的消息投遞，解決對於事件中心單點依賴的問題。

結語

這裏的定時器服務目前僅用於支持境外的定時器需求，調用量級尚不大，已可滿足業務基本要求。如果要支撐更高的任務量級，還需要做更多的思考和優化。隨時歡迎大家和和我交流探討。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ggPftQm2ewGOJwlRDQGgDQ

猜你喜歡