新型计划任务：以接口形式实现的计划任务.pdfVIP

新型计划任务：以接⼜形式实现的计划任务 1.31.1 这⾥所说的计划任务 计划任务主要负责处理⼀些耗时的操作，或者⾮⽤户触发的作业。 有些⼈会称 为后台任务，或者推送作业，又或者定时任务。这时则统称为：计划任 务。 例如，当你发布⼀条微信朋友圈后需要通知上百个好友时；当⼀条后台的推荐资讯需 要推送到每个⽤户的客户端时；当需要将本地的静态资源如图⽚同步到CDN 时。 显然这些动则需要分钟级别的操作，不应该在客户端调⽤接⼜时同步处理 （但让我惊 讶的是现实真的有⼈会这么做 ！），又或者⾮⽤户触发⽽需要后台处理 （但更让我惊 讶的是竟然也有系统是在⽤户请求时附带进⾏处理，⽽且还是国内某个知名的会员中 ⼼ ！）。 这⾥不仅仅是提供实现计划任务的约束和机制，更多的是引导⼤家更好地应对此类问 题。 1.31.2 计划任务的关键环节 (1)触发 ⾸先，是何时何地由何⽤户产⽣⼀条待执⾏的计划任务，我们可以把这个场景点称为 ⼀个触发点。 通常的做法，我们会先纪录下此触发点的场景信息，并放⼊到⼀个队列⾥⾯，以便等 待计划任务消费。 (2)调度 其次，是通过何种机制进⾏计划任务的调度。 这⾥不仅有技术层⾯的问题，还有业务的问题，如每次批量处理多少，间隔多少，是 否需要失败重试等等？ (3)消费 最后，则是具体的计划任务执⾏，以完成必要的操作，也称为消费。 很多传统的做法，都是把这些操作和接⼜混在⼀起的，⽽这⾥，PhalApi则会以⼀种更 为明朗的⽅式来实现，从⽽⾃底⽽上，⽀持更多的调度⽅式和触发机制。 1.31.3 传统的计划任务 如果以⼀图⽽鳖之，上图虽然简化，但可以很好地说明传统计划任务的结构体系。 即：很多项⽬都是使⽤内嵌的⽅式来包含计划任务，这样明显会把接⼜服务系统和后 台计划任务混在⼀起，增加了系统间的耦合性。 虽然⼩项⽬可以忍受或者适合这种混合，但是出于长远考虑，进⾏有意识地分解还是 很有好处的。 ⽽且这种混合潜意识下又让开发⼈员不加判断就进⾏调⽤，这会严重增加接⼜的反应 时间。 我曾⽬睹⼀个接⼜耗时了近36秒之久，在对这个旧系统的接⼜进⾏⼀番排查后，原来 是这个接⼜在发布后对上百个好友做了通知推送导致产⽣了上百条insert语句。 (1)传统的调度 式 我们重点关注⼀下传统计划任务的调度⽅式，在过去，我们通常会有两种⽅式：⼀种 是启动死循环的进程，另⼀种是启动⼀个crontab之类的定时任务。 当然，上述的在接⼜请求时同步进⾏调度也算⼀种⽅式，但不是正规的做法。 如果采⽤死循环的⽅式，我们还需要考虑代码更新升级后，对脚本的重启，以便载⼊ 新的代码。如果是sh循环调⽤PHP脚本，则可以忽略。 1.31.4 新型的计划任务 (1) 以接⼜的形式提供计划任务服务 PhalApi 中最具特⾊的做法是，将计划任务的执⾏消费实现，以接⼜形式来提供。 这样的好处在于，我们作为接⼜开发⼈员，可以以熟悉的⽅式来进⾏计划任务的开 发。 但更⼤的得益在于，将计划任务通过接⼜的形式提供后，我们会看到更为⼴阔的使⽤ 场景：我们可以使⽤MQ队列消费，可以同步请求也可以异步请求。 (2)系统架构 我们所做的，不仅仅只是把原来混合型的代码作简单分解，如下： ⽽是以⼀种更为正统的做法，为此我们添加了⼀些必要的节点来设计此构架。新的实 现⽅式下的体系结构如下： 节点说明 在上图中，应⽤节点还是我们的接⼜系统；MQ队列则是⽤于存放待消费的场景信 息，同其他的MQ⼀样；计划任务则可以分为两部分，API接⼜实现和任务调度。 计划任务这两部分，物理部署上可以合在⼀起，也可以分开，这取决于应⽤系统是采 ⽤分布式的做法，还是单⼀的服务器。 执⾏流程 由上图可以看出，⼀个完整的计划任务流程为： 1、应⽤产⽣⼀条新的计划任务，并存放于MQ队列 2、计划任务定时或者不停扫描新的计划任务；若有，则进⾏调度 3、计划任务API完成需要的⼯作，并将结果返回调度器 (3)单个添加，批量处理 这⾥只⽀持单个MQ添加，⽽处理则是批量的，且每批处理的数据可指定配置。 (4)MQ共享 ⽆论是分布式还是本地⼀体化，MQ队列都应该是可以共享访问的，以便为应⽤节 点、计划任务调度节点所访问，如下图所⽰： ⾸选redis MQ 因为MQ作为频繁读写的媒介，应该优先使⽤⾼效缓存来提⾼系统的吞吐率以及增加 并发的能⼒。此外，作为临时⼀次性的数据，使⽤⾼效缓存也是⼤有好处的 （但我们 也需要考虑到数据丢失的情况）。 ⽽且，为了⽀持 单个添加，批量处理，第三⽅缓存应该很好地⽀持队列的操作。 所以，redis是