背景
互联网架构中的数据最终一致性，最常用的手段就是不断重试+幂等性保证。
比如我们的业务需要跨库事务，需要操作A和B两个数据库，如下图所示：
很难在保证性能的前提下直接操作不同的数据库或资源保证同时成功，这时候我们可以换个思路：
- 先把要做A和B两件事通过事务落入任务表
- 拆分任务为子任务A和子任务B，插入子任务和更新父任务用数据库事务保证
- 通过重试+幂等性来保证A成功
- 通过重试+幂等性来保证B成功
实时任务调度系统设计
根据上面的思路，我们可以把任务调度开发为业务无关的框架。
状态机引擎设计核心原理：利用数据库事务，父任务完成与子任务生成在同一事务中。
性能优化：落任务后，不用等待扫描任务执行，任务落库直接是锁定态，内存直接用线程池调度任务；补漏程序只是为了处理异常任务。
整体架构图如下：
任务状态变化图
定时任务调度
定时任务调度：可以落任务的时候指定执行时间，在指定时间执行；和实时的区别是任务内存不直接执行，任务落库是待执行态，等待任务扫描worker锁定执行：
定时调度任务状态图：定时状态机和实时状态机只有初始状态不一样。
调用实例序列分析
通过实例来加深了解，本例为了简化未画出超时重试等异常流程，原理都是一样的；比如我们如果有如下流程，A是总任务，涉及扩库任务BC，A执行完成后返回B和C两个子任务；B和C会被状态机并行调用，最终完成跨库任务；D可能是在C完成后，还需要比如更新缓存；
任务调度时序交互如下：
使用指南
本架构可以支撑大型互联网高并发场景，基于一些原因，不给出详细设计了，有缘者根据本设计可以根据本设计用于实际项目。
搭配分库分表使用，可以支撑水平扩展。
开发周期与收益：大概需要一到两个人月左右；如果你需要这些场景，开发可重用框架花费的时间并不一定比开发不可重用的程序多花时间，而且更好维护。
任务调度可以作为状态机引擎
- 任务调度系统如果再加上流程编排的控制，就是完整的状态机了（状态机定义可自行Baidu），所以本程序是名副其实的状态机引擎。
- 任务调度系统自身的调度流程，其实也是通过状态机来实现的。
如果有需要，可以按照本设计来构造一个完整的状态机；状态机引擎本身也非常有用，可以作为互联网数据强一致的通用调度机制。
本文地址：https://blog.csdn.net/qrycf/article/details/110559544