分布式事务实现原理

（1）引入了CanCommit阶段（2）在DoCommit阶段，各个库自己也有超时机制，也就是说，如果一个库收到了PreCommit自己还返回成功了，等了一会儿，如果超时时间到了，还没收到TM发送的DoCommit消息或者是abort消息，直接判定为TM可能出故障了，人家库自己颠儿颠儿的就执行DoCommit操作，提交事务了。因为这里就是说，如果这个库接收到了PreCommit消息，说明第一阶段各个库对CanCommit都返回成功了啊，这样TM才会发送PreCommit来，那么就默认为基本上各个库的PreCommit都会成功，所以大家没接收到DoCommit，直接自己执行提交操作了所以这个超时的机制是基于CanCommit的引入来实现的，有了一个CanCommit多了一个阶段，大家才能自己执行超时commit机制，这不就解决了TM挂掉的单点问题么，大家想想是不是这样子另外资源阻塞问题也能减轻一下，因为一个库如果一直接收不到DoCommit消息，不会一直锁着资源，人家自己会提交释放资源的，所有能减轻资源阻塞问题，比2PC稍微好一些吧而已3PC的缺陷：但是其实这种的话，也不是完全就一定好的，因为还是可能有问题啊，如果人家TM在DoCommit阶段发送了abort消息给各个库，结果因为脑裂问题，某个库没接收到abort消息，自己还颠儿颠儿的执行了commit操作，不是也不对么所以啊，其实2PC也好，3PC也好，都没法完全保证分布式事务的ok的，要明白这一点，总有一些特殊情况下会出问题的 

2、单点故障：TM是个单点，一旦挂掉就完蛋了3、事务状态丢失：即使把TM做成一个双机热备的，一个TM挂了自动选举其他的TM出来，但是如果TM挂掉的同时，接收到commit消息的某个库也挂了，此时即使重新选举了其他的TM，压根儿不知道这个分布式事务当前的状态，因为不知道哪个库接收过commit消息，那个接收过commit消息的库也挂了，兄弟4、脑裂问题：在阶段二中，如果发生了脑裂问题，那么就会导致某些数据库没有接收到commit消息，那就完蛋了，有些库收到了commit消息，结果有些库没有收到，这咋整呢，那肯定完蛋了 

2PC的缺陷

本地消息表方案

XA规范及2PC分布式事务理论XA规范指TM与RM交互时的协议

最大努力通知方案

文本

可靠消息最终一致性方案

1：try：尝试锁定资源2：confirm：确认执行sql3：cancel：如果执行失败则进行回滚

TCC协议Try、Confirm、Cancel

3PC

1：资源同步阻塞，prepare消息时候会锁住资源，直到commit才会释放资源，如果在这个阶段第三方来访问这个资源，就会被阻塞，直到资源释放