携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第7天
事务确认/取消定时重试
CompensableWork
一、系统每次启动，对还没执行结束的事务，进行恢复，继续执行分布式事务。
二、CompensableWork定时不断的去重试服务的confirm接口。分布式事务中所有服务的try都成功了，然后执行confirm，其他服务的confirm都成功了，可能就1个服务的confirm失败了。此时一直重试，直到服务的confirm接口执行成功，才能认为分布式事务执行成功了。
timingRecover
timingRecover进行定时不断执行的恢复。
confirm或者是cancel有某个服务没有执行成功，bytetcc框架的CompensableWork会不断的去进行重试
通过源码，揭示出来了，如果有confirm或者cancel没成功的服务，CompensableWork会每隔60s去调用一次commit接口或者是rollback接口，尝试去完成分布式事务中的confirm操作或者是cancel操作。
TransactionRecoveryImpl
TransactionRecoveryImpl负责事务恢复的组件。
CompensableWork每隔60s会去调用一次TransactionRecoveryImpl组件的timeingRecovery()方法，会去调用recoverCommit()方法，底层会去执行SpringCloudCoordinator的方法，去发送一个http请求，调用服务的commit接口
服务重启自动去恢复执行未完成的事务
CompesnableWork刚启动的时候会先去恢复一次事务，才会开始尝试每隔60s去恢复一次未完成的事务。
如果有的服务try都没执行完毕，然后直接挂掉了，此时会怎么样呢？其实此时可以让已经try成功的服务直接全部cancel掉。
如果是try都成功了，confirm没有都成功，此时主服务重启，会调用子服务的confirm接口。
其实在重启的过程中，没完成的分布式事务会进行恢复的一个过程，也是通过timingRecover()方法实现的，在刚开始启动的时候，这个方法就会执行一次，就承担了系统重启恢复事务的过程。
读取主服务的分布式事务的活动日志，找出来没完成的分布式事务，对没完成的服务，发起对应的confirm/cancel接口的调用，如果还是没法成功，后续timeingRecover会不断的去执行对应的接口的调用，来完成这个事务。
