Chinaunix首页 | 论坛 | 博客
  • 博客访问: 387249
  • 博文数量: 273
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1430
  • 用 户 组: 普通用户
  • 注册时间: 2018-02-02 15:57
文章分类

全部博文(273)

文章存档

2018年(273)

我的朋友

分类: 大数据

2018-07-12 15:50:22

前阵子开发了公司领劵中心的项目,这个项目是以Redis作为关键技术落地的。

其中有一个功能叫做领劵的订阅推送。什么是领劵的订阅推送?就是用户订阅了该劵的推送,在可领取前的一分钟就要把提醒信息推送到用户的App中。本来这个订阅功能应该是消息中心那边做的,但他们说这个短时间内做不了,所以让我这个负责优惠劵的做了。具体方案就是到具体的推送时间点了,Coupon系统调用消息中心的推送接口,把信息推送出去。

下面我们分析一下这个功能的业务情景:

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

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

然而推送体量又会影响到推送的实效性。这真是一个让人头疼的问题……那就让我们把问题一个个解决掉吧!

推送的实效性的问题

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

方案1:MQ的延迟投递


阅读(1209) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~