最近由于校验工具出现bug，但无法定位问题，又涉及到数据库的创建和更新，所以在武哥的帮助下，学习了下DTC，也就是分布式事务协调管理，主要解决事务完整性问题和提供自动修复功能。当然现在我只涉及到了监测功能，修复功能需要运维的配合。
函数原型
当一个函数对数据库执行多步操作需要保证其完整性的时候（同时数据的复杂性也会导致某些执行成功，某些失败，不一定是逻辑错误，当然如果百分百执行不到下一步，很有可能逻辑错误）
fun(storevalue){ dtc(order1,storevalue) //初始化参数，如果只有order1得到了增长，则表明 step1fun()执行失败 step1fun()===========执行完之后产生参数A dtc(order2,storevalue) //第一步函数执行后参数，如果order1和order2得到了增长，order3没有增长，则表明 step2fun()执行失败 step2fun()===========执行完之后产生参数B dtc(order3,storevalue) //第二步函数执行后参数，如果order1、order2和order3得到了增长，order4没有增长，则表明 step3fun()执行失败 step3fun()=========== dtc(order4,storevalue) //第三步函数执行后参数，如果order1、order2、order3和order4都得到了增长，则表明 全部执行成功 }
数据巴士
上边的函数部分可以图形化为上图，也就是上下文数据再不断膨胀，但在每一步执行完时候都会将下一个步骤执行所需的数据序列化存储到DTC日志，方便复现当时场景。
线上监测
线上发现order1执行了3次，而order2只执行了2次，说明step1fun()有一次执行失败，同时，order4只执行了1次，说明，step3fun()有两次执行失败，当四次执行都成功的时候，每一个order都抵消1
注意：这里不光是自己的代码要写完，还要往配置里加东西，具体来说我从本地代码往运维的数据库里存入数据，运维不管是在什么环境下，只要有配置文件就可以依赖其从自己的库里读取数据，所以我只需要给运维他需要的配置就行，数据库（不管是线上还是测试）大家都能看到，他也不用关心我的代码实现。
如果步骤都执行完了，完成数加1，如果有没有执行完的，流程中各步数量柱状图会有所不同
