前阵子开发了公司领劵中心的项目，这个项目是以Redis作为关键技术落地的。
其中有一个功能叫做领劵的订阅推送。什么是领劵的订阅推送？就是用户订阅了该劵的推送，在可领取前的一分钟就要把提醒信息推送到用户的App中。本来这个订阅功能应该是消息中心那边做的，但他们说这个短时间内做不了，所以让我这个负责优惠劵的做了。具体方案就是到具体的推送时间点了，Coupon系统调用消息中心的推送接口，把信息推送出去。
下面我们分析一下这个功能的业务情景：
公司目前注册用户6000W+，是哪家就不要打听了，比如有一张无门槛的优惠劵下单立减20元，那么抢这张劵的人就会比较多，我们保守估计10W+，百万级别不好说。我们初定为20W万人，那么这20W条推送信息要在一分钟推送完成，并且一个用户是可以订阅多张劵的。所以我们知道了这个订阅功能有两个突出的难点：
推送的实效性：推送慢了，用户会抱怨没有及时通知他们错过了开抢时机；
推送的体量大：爆款的神劵，人人都想抢。
然而推送体量又会影响到推送的实效性。这真是一个让人头疼的问题……那就让我们把问题一个个解决掉吧！
推送的实效性的问题
当用户在领劵中心订阅了某个劵的领取提醒后，在后台就会生成一条用户的订阅提醒记录，里面记录了在哪个时间点给用户发送推送信息。所以问题就变成了系统如何快速实时选出哪些要推送的记录。
方案1：MQ的延迟投递
MQ虽然支持消息的延迟投递但尺度太大1s 5s 10s 30s 1m，用来做精确时间点投递不行。并且用户执行订阅之后又取消订阅的话，要把发出去的MQ消息Delete掉这个操作有点头大，短时间内难以落地，而且用户可以取消之后再订阅，这又涉及到去重的问题，所以MQ的方案否掉。
方案2：传统定时任务
扫描二维码关注公众号，回复：
2145934 查看本文章
