前言

okey, 现在又发现一个小问题，哎，命运多舛，换了个毕设方向，不想直接硬刚造轮子，结果现在还是得造个轮子。先来说说我的场景吧，这个场景估计很多项目也是用得到，那就是保证任务的一致性执行。举个简单的例子，就是在我们编写提交博问的时候。他有对应的验证服务，存储服务，消息通知服务，推流服务。整个过程是需要一致性执行的，也就是保证原子性，事务操作。有一个环节出现问题就得G，然后，就是对应的各种'保熟'操作。再或者还有这个支付的问题，如果支付成功，失败了又怎么处理。

基本设计概念

这个过程，再结合上次做智能小车导航主控功能那里发现的骚操作，于是我打算实现一个一致性的任务执行框架，以业务为导向进行封装，那么接下来编码的时候，我就只需要单独实现对应的方法，然后通过这个进行调度接口。换一句话说，我只需要对外暴露一个API接口，其他的都是方法，不需要暴露，提高了系统安全，同时顺序调度执行。然后做好调度器，然后还有保熟操作即可。

于是问题来到了我要如何设计，设计一个任务调度器固然不难，但问题在于，要做到“保熟”，这里麻烦一点儿。于是在这里我定义如下概念：

1. 任务清单： 对业务模块，例如支付流程，搞一个任务清单，按照清单任务执行 任务清单具备以下特性：
   1. 清单具备“清单事务”：原子性，一致性，隔离性，状态可恢复性
   2. 外部异步性，内部顺序同步性
   3. 相同属性顺序执行性
   4. 强回退：清单执行失败，是否直接回退到当前清单执行前状态。
   5. 弱回退：仅回退失败清单项
   6. 强提交：失败之后，进行失败备份，继续执行（不超过n次）
   7. 弱提交：失败之后，只进行记录
   8. 任务恢复性：服务器G了，重启之后将重新恢复清单任务。
   9. 面向方法：我所有的任务都是方法执行，那么我直接面向方法进行处理
2. 清单项 任务清单上面每一条具体的任务执行计划，同样需要具备以下特性：
   1. 包容性：任务清单可以是具体任务，同时也可以是新的任务子清单
   2. 原子性，一致性，隔离性，状态可恢复性
   3. 条件创建：任务清单完成创建，表示清单item全部完成创建，item创建时，可以通过判断当前条件是否满足进行创建，不满足不创建，当前任务清单作废。
   4. 执行时条件： 由于某写特殊原因，例如在购物场景下，商家突然发现商品不够了，在用户支付阶段，商家下架了商品，当用户支付完成之后，或者刚刚好在支付之前，条件不成立，终止清单任务，或者跳过item.
   5. 执行后条件： 任务执行完毕之后，条件不满足，终止任务，回退。注意：某一项失败，如果选择跳过，视为item执行成功，选择终止，那么直接进行回退，回退清单执行前状态

仔细查看，在后面几个条件判断的特性，恢复特性，其实和seata的：AT（自动化补偿事务）模式很像。即：

开发人员需要在业务逻辑代码中显式编写事务补偿逻辑。当一个分布式事务提交时，Seata会自动记录所有参与者的操作日志，如果事务失败或回滚，Seata将根据事务日志执行相应的补偿操作来回滚已提交的操作。

在清单执行阶段，我也一样会进行记录，也必须进行记录，因为任务恢复性，我不得不做，反正都做了，这些状态我也要进行补偿，所以干脆一起做得了。这玩意的话，预计开发事件不会太长，先做dome级别的。先混个毕设再说。主要原因是，这种清单需求，在我的项目里面，有好几个。不做的话，写起来的话就有点难受了。这个小轮子，我已经想好了，定义几个注解就可以完成了，当然注解分两类：1. 我自己的小框架的注解，毕竟我也要扫描，到对应的方法，然后拼接执行方法。2. 给SpringBoot 使用的注解，一个是启动注解，还有一个是开启任务清单的注解，什么意思，你的请求过来到比如订单API，我才需要创建这个订单清单啊，需要一个触发，而这个需要和spring打交道，当然搞个config类，暴露容器清单实例，然后代码上面手动调用也可以。这个注解我可以做也可以不做，做了就是全面拥抱spring。

总体设计流程

很好接下来的话，来看到总体的一个设计流程，大致需要哪些组件，编码的话，不难。有时间的话估计很快就能做好，在这块的话，我先确定灵感，到时候忘了就尴尬了。而且说实话，这也是第一次做Java这边的小轮子。Python这边的话，造的轮子就比较多了，有时间再捋一捋。

那么废话不多说，先来看到这个流程，这里图画的不标准哈。能看清楚流程即可，没必要，我也没时间搞那样。 至于用了哪些设计模式的话，那得看我想做多大了~，这里的话我只想能跑起来的dome，没时间，先凑活下。当然具体的代码实现，还没有，思路大概是这样的思路。慢慢来呗 ~，没办法。

ok,这里的话，差不多了，慢慢填写代码即可。