金融社区优惠文章是基于京东商城优惠商品批量化自动生成的,每日通过不同的渠道获取到待生成的SKU列表,并根据条件生成优惠文章.
但是,生成优惠文章之后续衍生问题：
该商品无优惠了,对应文章需要做取消推荐或下架处理,怎样能更快的知道该商品无优惠了呢?
承接该商品所有变更信息的消息,发生变更后二编文章.
优点：
实时,一旦变更立刻知道并更新文章.
缺点：
①. 开销大,是要承接的消息多,可能100台机器也不一定能承接（亿级变更）.
通过任务轮训文章,调外部接口判断该商品是否有优惠,之后做相应的处理.
①. 业务模型较简单,只需要判断是否有优惠或优惠变更即可.
不实时,数据量大了,对任务的实时性是个挑战.
即自己实现分布式调度增强,提高数据处理能力,提高调度鲁棒性、自动化等能力,同时采用首次曝光监测的方式,利用用户访问文章时判断是否有优惠,并做相应取消推荐或文章下线处理
①. 较实时,第一批被推荐推到C端用户的文章有可能会看到无优惠兜底方案,其它人便不再被推送.
需要实现可伸缩自动任务组件
至此,如何保证千万量级的优惠文章监测优惠变更不至于周期太长成了难点.
此时此刻呢介绍可伸缩任务组件,是如何解决上述问题的：
我们希望组件拥有的能力
任务自动化,结束自动重新执行
任务鲁棒性强,意外中断可从断点处重新唤起
任务可分治,可利用线程池及分布式集群将整体任务拆分成多个子任务执行
任务可扩展,具备新任务探测能力
任务可熔断,可以监测连续异常并终止执行
任务指令：触发某个任务的一条指令信息
任务开关：控制整体任务执行情况,如：停止执行,分时段执行等
redo指令：当任务执行完成后,发出的重做指令
任务监测：负责监测任务执行情况,根据任务状态处理任务
能否复用现有中间件?如：分布式任务,消息队列等
答案是可以,并且个人觉得最好是优先利用中间件能力,并将中间件的能力定义成组件的可扩展能力,方便中间件替换,提高组件的通用性
如果使用现有中间件实现该如何实现?
传统思路：
分布式任务负责查询全量文章,将查询结果发送MQ,消费者消费单条消息,并进行业务处理
那么问题来了,
①. 查询一轮任务需要多长时间呢?随着文章量的增加,调度周期设置多少合适呢?
显然这种方式不太适合数据量大的情况
那么我们的思路是：
至此,我们使用到了分布式调度、消息队列、Redis、分布式共识、ES等中间件能力.
①. 指令的定义：
工作流程说明：
①. 任务监测模块负责周期性的监测现有任务执行情况及是否有新任务加入到任务列表中.
首先当拿到某个任务时,检验该任务最近活跃时间是否超出10分钟（可配置）,如果超出则认为当前任务因某种原因已经终止执行了,此时发送唤起任务执行的指令.
接着执行新任务监测,如果有新任务加入,则将该任务加入到任务列表中.此时不需要发出任务唤起指令,下次任务监测则会根据上述逻辑发出唤起指令
合法性校验点包括：
①.）任务控制能力监测即相关开关监测
任务熔断能力监测,异常信息是否超出阈值,如果超出终止执行
任务防重监测,任务当前指令是否有其它线程在同时执行,如果有终止执行
执行的过程为：
①.）任务采用异步线程池模式,收到执行指令(MQ)后立即开启异步线程执行,防止单条指令执行时间太长
安全性：大促或下游压力大,可随时停止或分时段执行
鲁棒性：在微服务上线时,或接口调用异常时,任务产生中断,但过10分钟后,又会被从断点处重新唤起,不需要人工干预
该组件,可根据业务逻辑做任何相关业务处理,如监测到已下架或取消推荐的文章,判断优惠存在时,依然可以做重新上架处理,不过此能力依赖业务系统配合
该组件目前缺少两个能力
①. 任务出错后,可将错误信息发送告警,可通过接入监控系统实现,提高组件的告警能力
以上就是土嘎嘎小编为大家整理的如何实现千万级优惠文章的优惠信息同步相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！