无中心化调度下主从触发时序不一致的兜底修正

Elastic-Job的作业执行本身是无中心化的——各个服务器并不依赖一个中心调度器来分配任务、触发执行，而是各自根据本地状态和约定好的时间自行触发；但重分片这个动作只能由主节点（通过ZooKeeper的leader机制选出）来完成。这个”执行去中心化、分片有中心”的组合会带来一个不那么直观的时序风险：无调度中心的架构无法保证主节点一定先于其他从节点触发本次作业——完全可能出现从节点先按照旧的分片结果触发执行，而主节点这时才刚完成重新分片，导致这一次的执行结果和刚刚算出来的新分片状态对不上。面对这种理论上无法完全杜绝的时序竞态，Elastic-Job没有试图去强行保证”主节点必须先触发”这个更难实现的强顺序保证，而是退而求其次，让专门负责保存运行时状态的execution节点来承担一致性的最终兜底：本次执行即使用了错误（过期）的分片信息，只要之后没有再发生新的服务器波动，下一次执行时之前的分片错误会被自动修正过来。这个设计思路提示了一条分布式系统里常见的实用主义原则：当”完全杜绝某种竞态”的成本过高（这里是要在无中心调度架构里额外引入严格的全局顺序保证）时，一个务实的替代方案是承认这种竞态短暂存在的可能性，转而设计一套”下一轮自动收敛”的兜底机制，用最终一致性去覆盖那些概率低、影响可控、而且会被后续状态自动修正的边缘情况。