小Hub領讀：
20w+的推送用戶，如何做到秒級併發完成，文中分別介紹了MQ、傳統定時任務以及Redis的SortSet隊列三種方案，一一分析可行性，並且最後給出了Redis的邏輯與部分代碼實現。你學會了嗎？
作者：我是林林
https://www.cnblogs.com/linlinismine/p/9214299.html
前陣子開發了公司領劵中心的項目，這個項目是以 redis 作爲關鍵技術落地的。
先說一下領劵中心的項目吧，這個項目就類似京東 app 的領劵中心，當然圖是截取京東的，公司的就不截了。。。
其中有一個功能叫做領劵的訂閱推送。
什麼是領劵的訂閱推送？
就是用戶訂閱了該劵的推送，在可領取前的一分鐘就要把提醒信息推送到用戶的 app 中。
本來這個訂閱功能應該是消息中心那邊做的，但他們說這個短時間內做不了。所以讓我這個負責優惠劵的做了 -.-!。具體方案就是到具體的推送時間點了，coupon 系統調用消息中心的推送接口，把信息推送出去。
下們我們分析一下這個功能的業務情景。公司目前註冊用戶 6000W+，是哪家就不要打聽了。。。比如有一張無門檻的優惠劵下單立減 20 元，那麼搶這張劵的人就會比較多，我們保守估計 10W+，百萬級別不好說。我們初定爲 20W 萬人，那麼這 20W 條推送信息要在一分鐘推送完成！並且一個用戶是可以訂閱多張劵的。所以我們知道了這個訂閱功能的有兩個突出的難點：
推送的實效性：推送慢了，用戶會抱怨沒有及時通知他們錯過了開搶時機。
推送的體量大：爆款的神劵，人人都想搶！
然而推送體量又會影響到推送的實效性。這真是一個讓人頭疼的問題！
那就讓我們把問題一個個解決掉吧！
推送的實效性的問題：當用戶在領劵中心訂閱了某個劵的領取提醒後，在後臺就會生成一條用戶的訂閱提醒記錄，裏面記錄了在哪個時間點給用戶發送推送信息。所以問題就變成了系統如何快速實時選出哪些要推送的記錄！
方案 1：
MQ 的延遲投遞。MQ 雖然支持消息的延遲投遞但尺度太大 1s 5s 10s 30s 1m，用來做精確時間點投遞不行！並且用戶執行訂閱之後又取消訂閱的話，要把發出去的 MQ 消息 delete 掉這個操作有點頭大，短時間內難以落地！並且用戶可以取消之後再訂閱，這又涉及到去重的問題。所以 MQ 的方案否掉。
方案 2：
傳統定時任務。這個相對來說就簡單一點，用定時任務是去 db 裏面 load 用戶的訂閱提醒記錄，從中選出當前可以推送的記錄。但有句話說得好任何脫離實際業務的設計都是耍流氓~。下面我們就分析一下傳統的定時任務到底適不適合我們的這個業務!
| 能否支持多機同時跑 | 一般不能，同一時刻只能單機跑。 |
| 存儲數據源 | 一般是 mysql 或者其它傳統數據庫，並且是單表存儲 |
| 頻率 | 支持秒、分、時、天，一般不能太快 |
綜上所述我們就知道了一般傳統的定時任務存在以下缺點：
性能瓶頸。只有一臺機在處理，在大體量數據面前力不從心！
實效性差。定時任務的頻率不能太高，太高會業務數據庫造成很大的壓力！
單點故障。萬一跑的那臺機掛了，那整個業務不可用了 -。- 這是一個很可怕的事情！
所以傳統定時任務也不太適合這個業務。。。
那我們是不是就束手無策了呢？其實不是的! 我們只要對傳統的定時任務做一個簡單的改造！就可以把它變成可以同時多機跑, 並且實效性可以精確到秒級，並且拒絕單點故障的定時任務集羣！這其中就要藉助我們的強大的 redis 了。
方案 3：定時任務集羣
首先我們要定義定時任務集羣要解決的三個問題！
1、實效性要高
2、吞吐量要大
3、服務要穩定，不能有單點故障
下面是整個定時任務集羣的架構圖。
架構很簡單：我們把用戶的訂閱推送記錄存儲到 redis 集羣的 sortedSet 隊列裏面, 並且以提醒用戶提醒時間戳作爲 score 值，然後在我們個每業務 server 裏面起一個定時器頻率是秒級，我的設定就是 1s，然後經過負載均衡之後從某個隊列裏面獲取要推送的用戶記錄進行推送。下面我們分析以下這個架構。
1、性能：除去帶寬等其它因素，基本與機器數成線性相關。機器數量越多吞吐量越大，機器數量少時相對的吞吐量就減少。
2、實效性：提高到了秒級，效果還可以接受。
3、單點故障？不存在的！除非 redis 集羣或者所有 server 全掛了。。。。
這裏解析一下爲什麼用 redis？
第一 redis 可以作爲一個高性能的存儲 db，性能要比 MySQL 好很多，並且支持持久化，穩定性好。
第二 redis SortedSet 隊列天然支持以時間作爲條件排序，完美滿足我們選出要推送的記錄。
ok~ 既然方案已經有了那如何在一天時間內把這個方案落地呢？是的我設計出這個方案到基本編碼完成，時間就是一天。。。因爲時間太趕鳥。
首先我們以 user_id 作爲 key，然後 mod 隊列數 hash 到 redis SortedSet 隊列裏面。爲什麼要這樣呢，因爲如果用戶同時訂閱了兩張劵並且推送時間很近，這樣的兩條推送就可以合併成一條~，並且這樣 hash 也相對均勻。下面是部分代碼的截圖：
然後要決定隊列的數量，一般正常來說我們有多少臺處理的服務器就定義多少條隊列。因爲隊列太少，會造成隊列競爭，太多可能會導致記錄得不到及時處理。
然而最佳實踐是隊列數量應該是可動態配置化的，因爲線上的集羣機器數是會經常變的。大促的時候我們會加機器是不是，並且業務量增長了，機器數也是會增加是不是~。所以我是借用了淘寶的 diamond 進行隊列數的動態配置。
我們每次從隊列裏面取多少條記錄也是可以動態配置的
這樣就可以隨時根據實際的生產情況調整整個集羣的吞吐量~。 所以我們的定時任務集羣還是具有一個特性就是支持動態調整~。
最後一個關鍵組件就是負載均衡了。這個是非常重要的！因爲這個做得不好就會可能導致多臺機競爭同時處理一個隊列，影響整個集羣的效率！在時間很緊的情況下我就用了一個簡單實用的利用 redis 一個自增 key 然後 mod 隊列數量算法。這樣就很大程度上就保證不會有兩臺機器同時去競爭一條隊列~.
最後我們算一下整個集羣的吞吐量
10（機器數） * 2000（一次拉取數） = 20000。然後以 MQ 的形式把消息推送到消息中心，發 MQ 是異步的，算上其它處理 0.5s。
其實發送 20W 的推送也就是 10 幾 s 的事情。
ok~ 到這裏我們整個定時任務集羣就差不多基本落地好了。如果你問我後面還有什麼可以完善的話那就是：
加監控， 集羣怎麼可以木有監控呢，萬一出問題有任務堆積怎麼辦~
加上可視化界面。
最好有智能調度，增加任務優先級。優先級高的任務先運行嘛。
資源調度，萬一機器數量不夠，力不從心，優先保證重要任務執行。
目前項目已上前線，運行平穩~。
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。