Redis中怎么實現(xiàn)實時訂閱推送

這篇文章將為大家詳細講解有關(guān)Redis中怎么實現(xiàn)實時訂閱推送，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

什么是領(lǐng)劵的訂閱推送？

就是用戶訂閱了該劵的推送，在可領(lǐng)取前的一分鐘就要把提醒信息推送到用戶的 app 中。

本來這個訂閱功能應(yīng)該是消息中心那邊做的，但他們說這個短時間內(nèi)做不了。所以讓我這個負責優(yōu)惠劵的做了 -.-!。具體方案就是到具體的推送時間點了，coupon 系統(tǒng)調(diào)用消息中心的推送接口，把信息推送出去。

下們我們分析一下這個功能的業(yè)務(wù)情景。公司目前注冊用戶 6000W+，是哪家就不要打聽了。。。比如有一張無門檻的優(yōu)惠劵下單立減 20 元，那么搶這張劵的人就會比較多，我們保守估計 10W+，百萬級別不好說。我們初定為 20W 萬人，那么這 20W 條推送信息要在一分鐘推送完成！并且一個用戶是可以訂閱多張劵的。所以我們知道了這個訂閱功能的有兩個突出的難點：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  推送的實效性：推送慢了，用戶會抱怨沒有及時通知他們錯過了開搶時機。

3.  推送的體量大：爆款的神劵，人人都想搶！

然而推送體量又會影響到推送的實效性。這真是一個讓人頭疼的問題！

那就讓我們把問題一個個解決掉吧！

推送的實效性的問題：當用戶在領(lǐng)劵中心訂閱了某個劵的領(lǐng)取提醒后，在后臺就會生成一條用戶的訂閱提醒記錄，里面記錄了在哪個時間點給用戶發(fā)送推送信息。所以問題就變成了系統(tǒng)如何快速實時選出哪些要推送的記錄！

方案 1：

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

方案 2：

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

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

4.  單點故障。萬一跑的那臺機掛了，那整個業(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)過負載均衡之后從某個隊列里面獲取要推送的用戶記錄進行推送。下面我們分析以下這個架構(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 進行隊列數(shù)的動態(tài)配置。

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

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

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

關(guān)于Redis中怎么實現(xiàn)實時訂閱推送就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。