两阶段提交-分布式事务

存在多个节点，其中一个为主节点，负责协调

这里假设每个节点不存在数据丢失的可能，也就是节点可以实例失败，并且可以正常重启，但是不能节点失效后无法恢复。当然这里如果分布式事务的其中一个数据节点失败，似乎整个集群都会失效，因为数据丢失了，但是如何保证数据丢失不是两阶段提交协议需要考虑的重点，所以这里不考虑

 

两阶段提交分为两个阶段：

 

1.预提交阶段：

         所有节点执行各自事务，但是不提交事务，并将自己的事务执行状态发送给协调者

2.全局提交阶段：

         协调者接受所有节点发过来的消息，根据消息来确定分布式事务是否提交，如果协调者收到了所有消息都为READY（事务已经正常执行完毕，等待提交），则协调者向所有人发送commit消息进行提交。否则协调者向所有人发送ROLLBACK命令将事务回滚

 

一些细节：

         预提交阶段：每个节点的事务执行状态有两种可能，一个是事务中的操作都可以正常完成，那么完成后事务状态就是READY。另一个就是某个节点事务执行过程中遇到了一些错误（例如死锁），此时事务的状态就是CANCLE    

以上就是两阶段提交的大致内容，接下来将重点考虑为何两阶段提交可以保证分布式数据库事务的一致性：

         正常状态：

         协调者发送提交信息后提交事务，并将信息记录到数据库中，其他节点也提交事务，数据一致性得到保护

         异常状态：

         节点执行异常： 协调者收到CANCLE消息，发送ROLLBACK信息，其他节点回滚事务并提交，协调者也回滚事务并提交

         节点宕机：

                   节点在发送READY前宕机，节点重启后重做完成后因为不能确定本事务是否执行完，需要向协调者发送CANCLE消息，并回滚事务。协调者收到CANCLE消息后全局回滚事务

                   节点在发送READY后宕机，节点重启后发送READY消息给协调者等待反馈。协调者收到消息后根据事务的状态发送提交或者回滚

         协调者宕机：

                   节点收不到协调者的消息将一直等待，直到协调者恢复并反馈消息为止

 

从以上可以看出两阶段提交有些弊端：

1.      每个节点的提交动作不可失败，如果失败，后续没有处理

2.      节点与协调者的等待是阻塞的，如果总是收不到反馈则一直等待，直到反馈消息为止

 

当然我们还可以将上述协议做的更复杂些，比如引入超时机制，如果协调者在规定时间内没有收到消息则认为节点失效，此时全局回滚事务。

还可以考虑容忍部分节点的失效，也就是节点失败数目少于某个数字时，还是可以全局提交该分布式事务，当然这与传统数据库的数据一致性是相违背的，但是当数据一致性不是那么重要时，倒是可以考虑这么做。