背景
分布式场景下，我们会对每个独立出来的服务进行集群，来提升服务的可用性，但集群环境下就会出现当前服务模块的定时任务重复进行的情况。
那么解决方案实际上有多种：
1.将定时任务提取出来，存放在后台管理系统
2.将定时任务单独部署成一个服务
3.将不同的服务部署不同的定时任务服务，用任务调度中心将其进行整合管理，也就是本文所说的分布式任务调度平台
原理
如图：
在分布式任务调度中心中（这里以XXL-JOB的架构图为例），分为两部分。
1.任务调度中心：即任务中心管理系统，处理所有的任务分发，执行器管理，日志分析处理等
2.执行器注册中心：管理所有微服务模块的定时任务注册
其次是定时任务模块，这里统称为执行器，每个执行器都会注册，原理类似于注册中心。
如此架构图部署进行数据交互后，我们只需要在任务调度平台配置对应所需要执行的任务，点击启动，可以配置对应的负载均衡策略轮询到需要运行的执行器上。确保无重复运行。并能在大数据量下进行分片与动态扩容与收缩。
数据分片
产生于任务调度平台与大数量的背景下，如实际场景中：
小李需要对公司的100万用户进行双十一秒杀活动数据推送，虽然部署了多台服务集群，但是为了避免重复进行任务，便使用单台数据节点运行定时任务，运行非常缓慢，第一个用户和最后一个用户的时间差有非常大的差异。导致用户不满。活动达不到理想效果，小李也被领导一顿吊。
那么如何通过任务调度平台去处理这个问题呢？
在任务调度平台中有个数据分片的概念，根据平台注册的执行器下标（index），根据其可将分为多个数据片段。
小李经过上一次的秒杀活动推送后，下定决心要优化推送，他决定使用分布式任务调度平台，开启十台服务，并且通过index下标将百万数据分片，配置每台服务器按各自的下标获取到10万的数据。配如下标为1的服务器获取第1条-10万条，下标为2的服务器获取第10万-20万条。以此类推。从而将此次的速度提升了十倍，用户体验度顿时好了许多。领导还请了小李喝可乐。
动态扩容与收缩
那么现在的场景又改变了，用户暴增到一千万，原有的十台服务器又慢了，领导一声令下叫回来周末度假的小李，令其将活动推送优化。
小李不慌不忙的直接启动了九十台服务器集群，因为数据分片原理是根据index下标，我们只需要提前定义好每台服务器获取多少数据，即可由此进行动态的扩容。由此，每台服务器又变成了各自领取十万数据进行推送。
数据量突然减少怎么办呢？
非双十一的情况下，用户的剁手欲望急剧下降，对服务器的需求远远不需要原有的一百台，领导希望小李能够腾出服务器资源提供别的项目使用。小李直接关闭了九十台服务器，由注册中心实时进行了收缩，由此，腾出了服务器资源。
优化
我们仔细看会发现，在单台服务器拿到十万数据进行处理时，仍然会出现第一个用户和最后一个用户收到消息的时间差，这时我们可以采用多线程方式进行任务跑批，提升程序运行数据，当然无论是多线程还是数据分片，我们都要通过日志记录分析确保每个用户收到了活动信息，如果发送失败则对其进行相应的补偿。不然就等着领导请喝茶吧。
