分布式事务

1.两阶段提交法

第一阶段是表决阶段，告诉上层管理的协调器这个执行成功（sql执行完成）还是失败（本地故障）了，注意此时还没有提交；
第二阶段是执行阶段，如果都成功了，那大家一起提交，如果有失败的机器，那大家都回滚;

1.png

分析问题出现在哪：
这种一般都是考虑单点的失败和阻塞、网络波动、顺序不一致

1.单点故障，事务协调器挂了，GG
2.这可都是事务啊，在执行的时候都是上锁的（事务的行级锁）,然后机器又多，大家返回的时间不一样，上锁时间很长，性能太差
3.系统收到全部就绪后，发送提交之后，出现网络波动，一部分机器没有收到，没有提交事务，出现数据不一致的问题。

2.借助消息队列实现最终一致性

目前比较火的消息队列kafka ，RoketeMQ，此方法一般需要做到幂等接口的设计
幂等接口一般指同一个请求不管调用几次这个接口，结果都是一样的。
具体了解请转步我的另一篇文章幂等接口的设计

222.jpg

先看一下消息队列到底解决了什么问题?

1.保证了生产出来的消息一定会发送到MQ中
2.保证了MQ消息一定会被消费,结合图来看一下

A服务保证消息发送成功，MQ保证消息不会丢失，B服务保证消息消费成功。期间各种情况的失败可以做个模拟，结合图片来看更能理解：

1.A服务生产消息，MQ持久化失败，不执行操作,从头来过。
2.MQ持久化成功，A服务执行失败，删除MQ中序列化的数据，从头来过。
3.A服务执行成功，此时把消息队列中的消息状态从待确认改为待发送
4.发送消息给B服务，B服务执行失败，重试（可以无限次重试，也可以自己按情况设置）。
5.B服务执行成功，删除序列化的消息。

事实上这只是消息队列的一个好处，他还解决其他很多问题，概括下来就是异步、削峰、解耦，详情请移步我的另一篇文章为什么要用消息队列？会带来什么问题？

参考：《吊打面试官》系列-分布式事务、重复消费、顺序消费