本篇文章為大家展示了redis中怎么實現(xiàn)實時訂閱推送功能，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

創(chuàng)新互聯(lián)服務(wù)項目包括古城網(wǎng)站建設(shè)、古城網(wǎng)站制作、古城網(wǎng)頁制作以及古城網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，古城網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到古城省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

方案1：MQ的延遲投遞。MQ雖然支持消息的延遲投遞但尺度太大1s 5s 10s 30s 1m，用來做精確時間點投遞不行！并且用戶執(zhí)行訂閱之后又取消訂閱的話，要把發(fā)出去的MQ消息delete掉這個操作有點頭大，短時間內(nèi)難以落地！并且用戶可以取消之后再訂閱，這又涉及到去重的問題。所以MQ的方案否掉。

方案2：傳統(tǒng)定時任務(wù)。這個相對來說就簡單一點，用定時任務(wù)是去db里面load用戶的訂閱提醒記錄，從中選出當(dāng)前可以推送的記錄。但有句話說得好任何脫離實際業(yè)務(wù)的設(shè)計都是耍流氓~。下面我們就分析一下傳統(tǒng)的定時任務(wù)到底適不適合我們的這個業(yè)務(wù)!

綜上所述我們就知道了一般傳統(tǒng)的定時任務(wù)存在以下缺點：

1、性能瓶頸。只有一臺機在處理，在大體量數(shù)據(jù)面前力不從心！

2、實效性差。定時任務(wù)的頻率不能太高，太高會業(yè)務(wù)數(shù)據(jù)庫造成很大的壓力！

3、單點故障。萬一跑的那臺機掛了，那整個業(yè)務(wù)不可用了-。- 這是一個很可怕的事情！

所以傳統(tǒng)定時任務(wù)也不太適合這個業(yè)務(wù)。。。 

那我們是不是就束手無策了呢？其實不是的! 我們只要對傳統(tǒng)的定時任務(wù)做一個簡單的改造！就可以把它變成可以同時多機跑,并且實效性可以精確到秒級，并且拒絕單點故障的定時任務(wù)集群！這其中就要借助我們的強大的redis了。

方案3：定時任務(wù)集群

首先我們要定義定時任務(wù)集群要解決的三個問題！

1、實效性要高

2、吞吐量要大

3、服務(wù)要穩(wěn)定，不能有單點故障 

下面是整個定時任務(wù)集群的架構(gòu)圖。 

  

架構(gòu)很簡單：我們把用戶的訂閱推送記錄存儲到redis集群的sortedSet隊列里面,并且以提醒用戶提醒時間戳作為score值，然后在我們個每業(yè)務(wù)server里面起一個定時器頻率是秒級，我的設(shè)定就是1s，然后經(jīng)過負(fù)載均衡之后從某個隊列里面獲取要推送的用戶記錄進(jìn)行推送。下面我們分析以下這個架構(gòu)

1、性能：除去帶寬等其它因素，基本與機器數(shù)成線性相關(guān)。機器數(shù)量越多吞吐量越大，機器數(shù)量少時相對的吞吐量就減少。

2、實效性：提高到了秒級，效果還可以接受。

3、單點故障？不存在的！除非redis集群或者所有server全掛了。。。。

這里解析一下為什么用redis？

第一redis 可以作為一個高性能的存儲db，性能要比MySQL好很多，并且支持持久化，穩(wěn)定性好。

第二redis SortedSet隊列天然支持以時間作為條件排序，完美滿足我們選出要推送的記錄。

ok~既然方案已經(jīng)有了那如何在一天時間內(nèi)把這個方案落地呢？是的我設(shè)計出這個方案到基本編碼完成，時間就是一天。。。因為時間太趕鳥。

首先我們以user_id作為key，然后mod隊列數(shù)hash到redis SortedSet隊列里面。為什么要這樣呢，因為如果用戶同時訂閱了兩張劵并且推送時間很近，這樣的兩條推送就可以合并成一條~，并且這樣hash也相對均勻。下面是部分代碼的截圖：

然后要決定隊列的數(shù)量，一般正常來說我們有多少臺處理的服務(wù)器就定義多少條隊列。因為隊列太少，會造成隊列競爭，太多可能會導(dǎo)致記錄得不到及時處理。

然而最佳實踐是隊列數(shù)量應(yīng)該是可動態(tài)配置化的，因為線上的集群機器數(shù)是會經(jīng)常變的。大促的時候我們會加機器是不是，并且業(yè)務(wù)量增長了，機器數(shù)也是會增加是不是~。所以我是借用了淘寶的diamond進(jìn)行隊列數(shù)的動態(tài)配置。

我們每次從隊列里面取多少條記錄也是可以動態(tài)配置的 

這樣就可以隨時根據(jù)實際的生產(chǎn)情況調(diào)整整個集群的吞吐量~。  所以我們的定時任務(wù)集群還是具有一個特性就是支持動態(tài)調(diào)整~。

最后一個關(guān)鍵組件就是負(fù)載均衡了。這個是非常重要的！因為這個做得不好就會可能導(dǎo)致多臺機競爭同時處理一個隊列，影響整個集群的效率！在時間很緊的情況下我就用了一個簡單實用的利用redis一個自增key 然后 mod 隊列數(shù)量算法。這樣就很大程度上就保證不會有兩臺機器同時去競爭一條隊列~.

最后我們算一下整個集群的吞吐量

10（機器數(shù)） * 2000（一次拉取數(shù)） = 20000。然后以MQ的形式把消息推送到消息中心，發(fā)MQ是異步的，算上其它處理0.5s。

其實發(fā)送20W的推送也就是10幾s的事情。

ok~ 到這里我們整個定時任務(wù)集群就差不多基本落地好了。如果你問我后面還有什么可以完善的話那就是：

1、加監(jiān)控， 集群怎么可以木有監(jiān)控呢，萬一出問題有任務(wù)堆積怎么辦~

2、加上可視化界面。

3、最好有智能調(diào)度，增加任務(wù)優(yōu)先級。優(yōu)先級高的任務(wù)先運行嘛。

4、資源調(diào)度，萬一機器數(shù)量不夠，力不從心，優(yōu)先保證重要任務(wù)執(zhí)行。

上述內(nèi)容就是Redis中怎么實現(xiàn)實時訂閱推送功能，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章名稱：Redis中怎么實現(xiàn)實時訂閱推送功能
網(wǎng)頁鏈接：http://aaarwkj.com/article34/pjcppe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、品牌網(wǎng)站建設(shè)、移動網(wǎng)站建設(shè)、定制網(wǎng)站、用戶體驗、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)