我是如何基于二阶段递交及悲观锁实现分布式事务的( 二 )_由于框架一开始的定位就是需要支持强一

5. 协调者发送事务递交命令至事务主记录所在表1的RaftLeader，在表1RaftGroup持久化事务主记录状态后通知协调者立即向业务服务返回事务是否成功递交；

6. 事务主记录所在的RaftLeader向其他参与者的RaftLeader异步通知事务递交。

每个RaftGroup's Leader都有定时器进行事务状态检测：

* 如果检测到挂起的命令是事务主记录，则与协调者通信检测其是否存活；

* 如果检测到挂起的命令非事务主记录，则与事务主记录所在的RaftLeader通信检测事务状态。

二、上锁及冲突检测流程：

简单说明一下每个Raft节点的状态机的处理流程：

1. Apply事务命令的RaftLog时，先检测当前锁列表是否存在冲突，如果没有冲突上锁成功持久化锁信息后返回；如果存在冲突则排入已上锁队列并持久化锁信息，等待上级锁事务递交后再返回；

2. Apply事务递交命令时，从当前锁列表内找到对应的命令，持久化写入命令对应的KV数据至底层的RocksDB内，如果当前锁有等待队列，则依次将队列重新尝试上锁；

我是如何基于二阶段递交及悲观锁实现分布式事务的( 二 )