分布式事务

分布式两阶段提交和三阶段提交

总结就是：

有两种角色，协调者和参与者
两阶段：
    1. 协调者给所有参与者发送准备消息，每个参与者要么直接返回失败，或者执行本地事务，写本地redo和undo日志，但不提交，并响应给协调者；
    2. 协调者根据反馈情况给所有参与者发送是要中止操作还是提交操作，如果提交，则所有参与者提交事务，释放资源，如果中止，则所有参与者中止事务，释放资源，并响应给协调者。

三阶段：
    1. 协调者给所有参与者发送是否可以准备，参与者根据自己是否能够顺利执行事务，要么响应Yes，要么响应No;
    2. 协调者根据反馈情况通知参与者，如果都是Yes，则执行，否则中止，参与者就根据是执行来进行本地事务，写本地redo和undo日志，或者中止，并响应协调者；
    3. 协调者根据响应情况通知参与者是要提交操作还是中止操作，同二阶段第2点。
    
缺陷：
两阶段： 1. 协调者需要等待所有的参与者的回复才通知全局事务提交或回滚，如果过程很长，就会长时间占用资源，而且当协调者宕机了，参与者就会出现一直阻塞等待的情况；
        2. 当协调者通知全局事务提交或回滚时，如果出现网络故障，导致部分节点没有接收到通知，也会导致这部分参与者循坏等待，并且由于这部分参与者没有参与事务提交，就会导致数据不一致。
三阶段： 1. 三阶段解决了两阶段的循环等待，设置了超时机制，会在超时之后默认提交事务。但是这还是会导致数据不一致的问题。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
TCC事务补偿机制

TCC是基于服务层实现的一种二阶事务提交
TCC分为三个阶段，Try、Confirm、Cancle
    1. Try阶段：只要尝试执行业务，执行各个服务的Try方法，主要包括预留操作；
    2. Confirm阶段：当各个服务的Try都执行成功，则执行各个服务的Confirm方法，进行事务提交；
    3. Cancle阶段：当有服务的Try执行失败，则执行各个服务的Cancle方法，进行事务回滚；
以上只保证Try阶段执行成功或失败的提交或回滚操作，如果Confirm阶段或Cancle阶段出现异常，则TCC会不停的重试调用Confirm方法或Cancle方法，直到成功为止。
1
2
3
4
5
6
可靠性消息投递机制（使用MQ来处理分布式事务）：

    1. 服务A先把消息持久化到本地数据库，并把状态设为待发送；
    2. 服务A把消息发送到消息队列当中；
    3. 服务B从消息队列获取消息并执行；
    4. 服务B如果执行成功，则发送一个消息到消息队列响应服务A，如果失败，则不操作；
    5. 服务A从消息队列获取响应结果；
    6. 更改本地数据库对应的消息状态，改为完成；
    7. 有一个定时任务，从本地数据库查找消息状态为未完成的，并重新投递到消息队列当中。
1
2
3
4
5
6
7

————————————————
版权声明：本文为CSDN博主「Hanyinh」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_43871678/article/details/106427596