个中有一个功能叫做领劵的订阅推送。什么是领劵的订阅推送？便是用户订阅了该劵的推送，在可领取前的一分钟就要把提醒信息推送到用户的app中。本来这个订阅功能该当是中央那边做的，但他们说这个短韶光内做不了。以是让我这个卖力优惠劵的做了-.-!。详细方案便是到详细的推送韶光点了，coupon系统调用中央的推送接口，把信息推送出去。
下们我们剖析一下这个功能的业务情景。公司目前注册用户6000W+，是哪家就不要打听了。。。比如有一张无门槛的优惠劵下单立减20元，那么抢这张劵的人就会比较多，我们守旧估计10W+，百万级别不好说。我们初定为20W万人，那么这20W条推送信息要在一分钟推送完成！
并且一个用户是可以订阅多张劵的。以是我们知道了这个订阅功能的有两个突出的难点：
1、推送的实效性：推送慢了，用户会抱怨没有及时关照他们错过了开抢机遇。
2、推送的体量大：爆款的神劵，大家都想抢！
然而推送体量又会影响到推送的实效性。这真是一个让人头疼的问题！
那就让我们把问题一个个办理掉吧！
推送的实效性的问题：当用户在领劵中央订阅了某个劵的领取提醒后，在后台就会天生一条用户的订阅提醒记录，里面记录了在哪个韶光点给用户发送推送信息。以是问题就变成了系统如何快速实时选出哪些要推送的记录！
方案1：MQ的延迟投递。MQ虽然支持的延迟投递但尺度太大1s 5s 10s 30s 1m，用来做精确韶光点投递弗成！
并且用户实行订阅之后又取消订阅的话，要把发出去的MQdelete掉这个操作有点头大，短韶光内难以落地！
并且用户可以取消之后再订阅，这又涉及到去重的问题。以是MQ的方案否掉。
方案2：传统定时任务。这个相对来说就大略一点，用定时任务是去db里面load用户的订阅提醒记录，从中选出当前可以推送的记录。但有句话说得好任何分开实际业务的设计都是耍泼皮~。下面我们就剖析一下传统的定时任务到底适不适宜我们的这个业务!
总上所述我们就知道了一样平常传统的定时任务存在以下缺陷：
1、性能瓶颈。只有一台机在处理，在大体量数据面前力不从心！
2、实效性差。定时任务的频率不能太高，太高会业务数据库造成很大的压力！
3、单点故障。万一跑的那台机挂了，那全体业务不可用了-。- 这是一个很恐怖的事情！
以是传统定时任务也不太适宜这个业务。。。
那我们是不是就束手无策了呢？实在不是的! 我们只要对传统的定时任务做一个大略的改造！
就可以把它变成可以同时多机跑,并且实效性可以精确到秒级，并且谢绝单点故障的定时任务集群！
这个中就要借助我们的强大的redis了。
方案3：定时任务集群
首先我们要定义定时任务集群要办理的三个问题！
1、实效性要高
2、吞吐量要大
3、做事要稳定，不能有单点故障
下面是全体定时任务集群的架构图。
架构很大略：我们把用户的订阅推送记录存储到redis集群的sortedSet行列步队里面,并且以提醒用户提醒韶光戳作为score值，然后在我们个每业务server里面起一个定时器频率是秒级，我的设定便是1s，然后经由负载均衡之后从某个行列步队里面获取要推送的用户记录进行推送。下面我们剖析以下这个架构
1、性能：撤除带宽等其它成分，基本与机器数成线性干系。机器数量越多吞吐量越大，机器数量少时相对的吞吐量就减少。
2、实效性：提高到了秒级，效果还可以接管。
3、单点故障？不存在的！
除非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~ 到这里我们全体定时任务集群就差不多基本落地好了。如果你问我后面还有什么可以完善的话那便是：
1、加监控， 集群怎么可以木有监控呢，万一出问题有任务堆积怎么办~
2、加上可视化界面。
3、最好有智能调度，增加任务优先级。优先级高的任务先运行嘛。
4、资源调度，万一机器数量不足，力不从心，优先担保主要任务实行。
目前项目已上前哨，运行平稳~。
原文作者：浮云骑士LIN
原文地址：https://www.cnblogs.com/linlinismine/p/9214299.html
