作者：我是林林
www.cnblogs.com/linlinismine/p/9214299.html
前陣子開發了公司領劵中心的專案，這個專案是以redis作為關鍵技術落地的，
先說一下領劵中心的專案吧，這個專案就類似京東app的領劵中心，當然圖是截取京東的，公司的就不截了，，，
其中有一個功能叫做領劵的訂閱推送，什么是領劵的訂閱推送？就是用戶訂閱了該劵的推送，在可領取前的一分鐘就要把提醒資訊推送到用戶的app中，
本來這個訂閱功能應該是訊息中心那邊做的，但他們說這個短時間內做不了，所以讓我這個負責優惠劵的做了-.-!，
具體方案就是到具體的推送時間點了，coupon系統呼叫訊息中心的推送介面，把資訊推送出去，
下面我們分析一下這個功能的業務情景，
公司目前注冊用戶6000W+，如果有一張無門檻的優惠劵下單立減20元，那么搶這張劵的人就會比較多，我們保守估計10W+，
我們初定為20W萬人，那么這20W條推送資訊要在一分鐘推送完成！并且一個用戶是可以訂閱多張劵的，
所以我們知道了這個訂閱功能的有兩個突出的難點：
1、推送的實效性：推送慢了，用戶會抱怨沒有及時通知他們錯過了開搶時機，
2、推送的體量大：爆款的神劵，人人都想搶！
然而推送體量又會影響到推送的實效性，這真是一個讓人頭疼的問題！
那就讓我們把問題一個個解決掉吧！！！
推送的實效性的問題：當用戶在領劵中心訂閱了某個劵的領取提醒后，在后臺就會生成一條用戶的訂閱提醒記錄，里面記錄了在哪個時間點給用戶發送推送資訊，
所以問題就變成了系統如何快速實時選出哪些要推送的記錄！
方案1：MQ的延遲投遞，推薦：MQ 到底有啥用？MQ雖然支持訊息的延遲投遞但尺度太大1s 5s 10s 30s 1m，用來做精確時間點投遞不行！并且用戶執行訂閱之后又取消訂閱的話，要把發出去的MQ訊息delete掉這個操作有點頭大，短時間內難以落地！并且用戶可以取消之后再訂閱，這又涉及到去重的問題，所以MQ的方案否掉，
方案2：傳統定時任務，這個相對來說就簡單一點，用定時任務是去db里面load用戶的訂閱提醒記錄，從中選出當前可以推送的記錄，但有句話說得好任何脫離實際業務的設計都是耍流氓~，下面我們就分析一下傳統的定時任務到底適不適合我們的這個業務!
能否支持多機同時跑
一般不能，同一時刻只能單機跑
存盤資料源
一般是mysql或者其它傳統資料庫，并且是單表存盤
頻率
支持秒、分、時、天，一般不能太快
綜上所述我們就知道了一般傳統的定時任務存在以下缺點：
1、性能瓶頸，只有一臺機在處理，在大體量資料面前力不從心！
2、實效性差，定時任務的頻率不能太高，太高會業務資料庫造成很大的壓力！
3、單點故障，萬一跑的那臺機掛了，那整個業務不可用了-，- 這是一個很可怕的事情！
所以傳統定時任務也不太適合這個業務，，，
那我們是不是就束手無策了呢？****其實不是的! 我們只要對傳統的定時任務做一個簡單的改造！就可以把它變成可以同時多機跑,并且實效性可以精確到秒級，并且拒絕單點故障的定時任務集群！這其中就要借助我們的強大的redis了，
推薦：史上最全 Redis 高可用解決方案總結
更多可以關注微信公眾號：Java技術堆疊，在后臺回復：redis，可以獲取我整理的 N 篇最新 Redis 教程，都是干貨，
方案3：定時任務集群
首先我們要定義定時任務集群要解決的三個問題：
1、實效性要高
2、吞吐量要大
3、服務要穩定，不能有單點故障
下面是整個定時任務集群的架構圖，
架構很簡單：我們把用戶的訂閱推送記錄存盤到redis集群的sortedSet佇列里面,并且以提醒用戶提醒時間戳作為score值，然后在我們每個業務server里面起一個定時器頻率是秒級，我的設定就是1s，然后經過負載均衡之后從某個佇列里面獲取要推送的用戶記錄進行推送，下面我們分析一下這個架構
1、性能：除去帶寬等其它因素，基本與機器數成線性相關，機器數量越多吞吐量越大，機器數量少時相對的吞吐量就減少，
2、實效性：提高到了秒級，效果還可以接受，
3、單點故障？不存在的！除非redis集群或者所有server全掛了，，，，
這里決議一下為什么用redis？
1、redis 可以作為一個高性能的存盤db，性能要比MySQL好很多，并且支持持久化，穩定性好，為什么分布式一定要Redis? 值得一讀，
2、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~ 到這里我們整個定時任務集群就差不多基本落地好了，如果你問我后面還有什么可以完善的話那就是：
1、加監控， 集群怎么可以木有監控呢，萬一出問題有任務堆積怎么辦~
2、加上可視化界面，
3、最好有智能調度，增加任務優先級，優先級高的任務先運行嘛，
4、資源調度，萬一機器數量不夠，力不從心，優先保證重要任務執行，
目前專案已上前線，運行平穩~
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/162473.html
標籤：Java