作者：京东科技 文涛
背景
金融社区优惠文章是基于京东商城优惠商品批量化主动生成的，每日通过不同的渠道获取到待生成的 SKU 列表，并依据条件生成优惠文章。
然而，生成优惠文章之后续衍生问题：
该商品无优惠了，对应文章须要做勾销举荐或下架解决，怎么能更快的晓得该商品无优惠了呢？
计划介绍
计划比照
计划 1
承接该商品所有变更信息的音讯，产生变更后二编文章。
长处：
实时，一旦变更立即晓得并更新文章。
毛病：
1 开销大，是要承接的音讯多，可能 100 台机器也不肯定能承接（亿级变更）。
2 耦合高，须要对接的业务方多，全副对接须要很长的周期及人力，同时对方产生业务变更须要通过人员同步更新逻辑。
计划 2
通过工作轮训文章，调内部接口判断该商品是否有优惠，之后做相应的解决。
长处：
1 业务模型较简略，只须要判断是否有优惠或优惠变更即可。
2 优惠侧投入较小，只须要投入调度工作的机器即可。
毛病：
不实时，数据量大了，对工作的实时性是个挑战。
计划 3
针对形式 2 的毛病，咱们推出了【可伸缩主动工作】+【首次曝光监测】的组合模式。
即本人实现散布式调度加强，进步数据处理能力，进步调度鲁棒性、自动化等能力，同时采纳首次曝光监测的形式，利用用户拜访文章时判断是否有优惠，并做相应勾销举荐或文章下线解决
长处：
1 较实时，第一批被举荐推到 C 端用户的文章有可能会看到无优惠兜底计划，其它人便不再被推送。
2 形式 2 的长处
毛病：
须要实现可伸缩主动工作组件
至此，如何保障千万量级的优惠文章监测优惠变更不至于周期太长成了难点。
接下来介绍可伸缩工作组件，是如何解决上述问题的：
可伸缩工作组件
要害能力
咱们心愿组件领有的能力
•工作自动化，完结主动从新执行
•工作鲁棒性强，意外中断可从断点处从新唤起
•工作可分治，可利用线程池及分布式集群将整体工作拆分成多个子工作执行
•工作可扩大，具备新工作探测能力
•工作可熔断，能够监测间断异样并终止执行
实现
名词解释
工作指令：触发某个工作的一条指令信息
工作开关：管制整体工作执行状况，如：进行执行，分时段执行等
redo 指令：当工作执行实现后，收回的重做指令
工作监测：负责监测工作执行状况，依据工作状态解决工作
实现思路
是否复用现有中间件？如：分布式工作，音讯队列等
答案是能够，并且集体感觉最好是优先利用中间件能力，并将中间件的能力定义成组件的可扩大能力，不便中间件替换，进步组件的通用性
如果应用现有中间件实现该如何实现？
传统思路：
分布式工作负责查问全量文章，将查问后果发送 MQ，消费者生产单条音讯，并进行业务解决
那么问题来了，
1 查问一轮工作须要多长时间呢？随着文章量的减少，调度周期设置多少适合呢？
2 MQ 的音讯将海量
显然这种形式不太适宜数据量大的状况
那么咱们的思路是：
1 将散布式调度形象成一个 心跳监测 模块，用于监测工作状态，以及探测新工作，这样工作执行周期固定 10min 即可，工作执行工夫也不会太长（理论执行工夫 200ms 左右）
2 将 MQ 形象成 工作指令 的载体，用于发送指令，接管指令，利用分布式的能力解决工作
3 将千万级的一次查问，拆分 成多个查问，放大单次指令执行的周期，将千万级文章信息同步至 ES，应用 ES 的滚动查问能力，在执行单次工作时，可滚动查问 10-20 万的文章
4 将分布式共识组件用作 开关能力，用于管制组件执行，在大促或上游压力过高时动态控制工作执行
5 将 Redis 用于工作 信息存储 和分布式 指令防重
至此，咱们应用到了 散布式调度、音讯队列、Redis、分布式共识、ES等中间件能力。
实现计划
1 指令的定义：
| 属性 | 阐明 |
|---|---|
| breakPoint | 断点标识 |
| rangeBegin | 边界起 |
| rangeEnd | 边界终 |
| startTime | 开始执行工夫 |
| endTime | 完结工夫 |
| lastExeTime | 最初一次执行工夫 |
| exceptionTimes | 产生谬误次数 |
| threadKey | 分布式工作线程标识 |
2 工作流程图：
工作流程阐明：
1 工作监测模块 负责周期性的监测现有工作执行状况及是否有新工作退出到工作列表中。
首先当拿到某个工作时，测验该工作最近沉闷工夫是否超出 10 分钟（可配置），如果超出则认为当前任务因某种原因曾经终止执行了，此时发送唤起工作执行的指令。
接着执行新工作监测，如果有新工作退出，则将该工作退出到工作列表中。此时不须要收回工作唤起指令，下次工作监测则会根据上述逻辑收回唤起指令
2 工作执行模块收到指令后首先会校验当前任务的合法性，而后再执行工作
合法性校验点包含：
1）工作控制能力监测即相干开关监测
2) 工作熔断能力监测，异样信息是否超出阈值，如果超出终止执行
3) 工作防重监测，工作以后指令是否有其它线程在同时执行，如果有终止执行
执行的过程为：
1）工作采纳异步线程池模式，收到执行指令 (MQ) 后立刻开启异步线程执行，避免单条指令执行工夫太长
2）执行接口调用办法，分批滚动查问待执行列表
3）循环待执行列表，执行相应业务逻辑
4）列表中每执行完一条数据，就会记录一下工作执行状况，用于作于异常中断后（机器重启），从断点处继续执行
5）工作产生异样记录异样信息
6）监测到工作真正执行实现，后发动 redo 指令，用于唤起下周期工作执行
目前成果
机器应用状况：微服务 2 台
工作拆分状况：目前工作被拆分成了 30 个子工作，均匀每个扫描 30 万文章
实时性：1 千万文章产生一次监测耗时 4 小时，上游接口 TPS700 左右
安全性：大促或上游压力大，可随时进行或分时段执行
鲁棒性：在微服务上线时，或接口调用异样时，工作产生中断，但过 10 分钟后，又会被从断点处从新唤起，不须要人工干预
中间件压力：复用调度和 MQ 等中间件但不连累中间件，每天产生 300 条左右 MQ 音讯，每条音讯生产耗时 10ms 以内，每次心跳监测模块（分布式工作执行）耗时 200ms 左右
扩大
该组件，可依据业务逻辑做任何相干业务解决，如监测到已下架或勾销举荐的文章，判断优惠存在时，仍然能够做从新上架解决，不过此能力依赖业务零碎配合
该组件目前短少两个能力
1 工作出错后，可将错误信息发送告警，可通过接入监控零碎实现，进步组件的告警能力
2 如何动态控制工作拆分逻辑，比方感觉 4 小时监测不够实时或太频繁时，想动静调整工作分治的粒度目前未实现