我是如何用redis作实时订阅推送的

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

      先说一下领劵中心的项目吧，这个项目就相似京东app的领劵中心，固然图是截取京东的，公司的就不截了。。。

     

 

      其中有一个功能叫作领劵的订阅推送。什么是领劵的订阅推送？就是用户订阅了该劵的推送，在可领取前的一分钟就要把提醒信息推送到用户的app中。原本这个订阅功能应该是消息中心那边作的，但他们说这个短期内作不了。因此让我这个负责优惠劵的作了-.-!。具体方案就是到具体的推送时间点了，coupon系统调用消息中心的推送接口，把信息推送出去。

 

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

     一、推送的实效性：推送慢了，用户会抱怨没有及时通知他们错过了开抢时机。

     二、推送的体量大：爆款的神劵，人人都想抢！

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

 

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

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

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

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

 

可否支持多机同时跑	通常不能，同一时刻只能单机跑。
存储数据源	通常是mysql或者其它传统数据库，而且是单表存储
频率	支持秒、分、时、天，通常不能太快

 

        总上所述咱们就知道了通常传统的定时任务存在如下缺点：

       一、性能瓶颈。只有一台机在处理，在大致量数据面前力不从心！

       二、实效性差。定时任务的频率不能过高，过高会业务数据库形成很大的压力！

       三、单点故障。万一跑的那台机挂了，那整个业务不可用了-。- 这是一个很可怕的事情！

        因此传统定时任务也不太适合这个业务。。。 

       那咱们是否是就一筹莫展了呢？其实不是的! 咱们只要对传统的定时任务作一个简单的改造！就能够把它变成能够同时多机跑,而且实效性能够精确到秒级，而且拒绝单点故障的定时任务集群！这其中就要借助咱们的强大的redis了。

     

方案3：定时任务集群

     首先咱们要定义定时任务集群要解决的三个问题！

     一、实效性要高

     二、吞吐量要大

     三、服务要稳定，不能有单点故障 

     下面是整个定时任务集群的架构图。 

       

 

     架构很简单：咱们把用户的订阅推送记录存储到redis集群的sortedSet队列里面,而且以提醒用户提醒时间戳做为score值，而后在咱们个每业务server里面起一个定时器频率是秒级，个人设定就是1s，而后通过负载均衡以后从某个队列里面获取要推送的用户记录进行推送。下面咱们分析如下这个架构

    一、性能：除去带宽等其它因素，基本与机器数成线性相关。机器数量越多吞吐量越大，机器数量少时相对的吞吐量就减小。

    二、实效性：提升到了秒级，效果还能够接受。

    三、单点故障？不存在的！除非redis集群或者全部server全挂了。。。。

 

    这里解析一下为何用redis？

    第一redis 能够做为一个高性能的存储db，性能要比MySQL好不少，而且支持持久化，稳定性好。

    第二redis SortedSet队列自然支持以时间做为条件排序，完美知足咱们选出要推送的记录。

    

    ok~既然方案已经有了那如何在一天时间内把这个方案落地呢？是的我设计出这个方案到基本编码完成，时间就是一天。。。 由于时间太赶鸟。

     首先咱们以user_id做为key，而后mod队列数hash到redis SortedSet队列里面。为何要这样呢，由于若是用户同时订阅了两张劵而且推送时间很近，这样的两条推送就能够合并成一条~，而且这样hash也相对均匀。下面是部分代码的截图：

  

    而后要决定队列的数量，通常正常来讲咱们有多少台处理的服务器就定义多少条队列。由于队列太少，会形成队列竞争，太多可能会致使记录得不到及时处理。

    然而最佳实践是队列数量应该是可动态配置化的，由于线上的集群机器数是会常常变的。大促的时候咱们会加机器是否是，而且业务量增加了，机器数也是会增长是否是~。因此我是借用了淘宝的diamond进行队列数的动态配置。

 

    咱们每次从队列里面取多少条记录也是能够动态配置的 

   这样就能够随时根据实际的生产状况调整整个集群的吞吐量~。  因此咱们的定时任务集群仍是具备一个特性就是支持动态调整~。

   最后一个关键组件就是负载均衡了。这个是很是重要的！由于这个作得很差就会可能致使多台机竞争同时处理一个队列，影响整个集群的效率！在时间很紧的状况下我就用了一个简单实用的利用redis一个自增key 而后 mod 队列数量算法。这样就很大程度上就保证不会有两台机器同时去竞争一条队列~.

 

    最后咱们算一下整个集群的吞吐量

     10（机器数） * 2000（一次拉取数） = 20000。而后以MQ的形式把消息推送到消息中心，发MQ是异步的，算上其它处理0.5s。

     其实发送20W的推送也就是10几s的事情。

    ok~ 到这里咱们整个定时任务集群就差很少基本落地好了。若是你问我后面还有什么能够完善的话那就是：

    一、加监控， 集群怎么能够木有监控呢，万一出问题有任务堆积怎么办~

    二、加上可视化界面。

    三、最好有智能调度，增长任务优先级。优先级高的任务先运行嘛。

    四、资源调度，万一机器数量不够，力不从心，优先保证重要任务执行。

 

     目前项目已上前线，运行平稳~。