如何用Redis做实时订阅推送的

功能应该是消息中心那边做的，但他们说这个短时间内做不了。所以让我这个负责优惠劵的做了 -.-!。具体方案就是到具体的推送时间点了，coupon 系统调用消息中心的推送接口，把信息推送出去。

下们我们分析一下这个功能的业务情景。公司目前注册用户 6000W+，是哪家就不要打听了。。。比如有一张无门槛的优惠劵下单立减 20 元，那么抢这张劵的人就会比较多，我们保守估计 10W+，百万级别不好说。我们初定为 20W 万人，那么这 20W 条推送信息要在一分钟推送完成！并且一个用户是可以订阅多张劵的。所以我们知道了这个订阅功能的有两个突出的难点：

1.  推送的实效性：推送慢了，用户会抱怨没有及时通知他们错过了开抢时机。
2.  推送的体量大：爆款的神劵，人人都想抢！

然而推送体量又会影响到推送的实效性。这真是一个让人头疼的问题！

那就让我们把问题一个个解决掉吧！

推送的实效性的问题：当用户在领劵中心订阅了某个劵的领取提醒后，在后台就会生成一条用户的订阅提醒记录，里面记录了在哪个时间点给用户发送推送信息。所以问题就变成了系统如何快速实时选出哪些要推送的记录！

方案 1：

MQ 的延迟投递。MQ 虽然支持消息的延迟投递但尺度太大 1s 5s 10s 30s 1m，用来做精确时间点投递不行！并且用户执行订阅之后又取消订阅的话，要把发出去的 MQ 消息 delete 掉这个操作有点头大，短时间内难以落地！并且用户可以取消之后再订阅，这又涉及到去重的问题。所以 MQ 的方案否掉。

方案 2：

传统定时任务。这个相对来说就简单一点，用定时任务是去 db 里面 load 用户的订阅提醒记录，从中选出当前可以推送的记录。但有句话说得好任何脱离实际业务的设计都是耍流氓~。下面我们就分析一下传统的定时任务到底适不适合我们的这个业务!

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!