MQ如何保证分布式事务

什么是分布式事务？

多个库实例实现ACID

下面咱们思考几个问题：

1. 数据库如何实现事务？undo log+redo log+MVCC
2. 多个数据库实例共享undo、redo、mvcc吗？不共享
3. 既然多个库事务相互隔离，那如何保证多个库之间数据一致？

相信大家猜到了，一个应用系统多个数据库实例保证数据一致性就是分布式事务。

分布式事务演变（软状态）

基本实现

首先咱们先看一张图

正常情况

假设DB1和DB2不存在任何问题，且应用系统不会挂机
1、同时开启DB1和DB2事务
2、执行sql语句
3、未出现异常提交
4、如果出现异常回滚

非正常情况

#假如出现这几种情况怎么办
1、DB1或者DB2长时间连接不上或者超时
	--长事务，占用大量资源
2、sql执行完后未提交之前，服务宕机
	当前资源一直存在，别的线程无法操作（超时时间内）

缺点

1、同步阻塞
2、占用大量的资源
3、性能低下

tcc和t3c

过程

# tcc
1、第一阶段准备
2、提交
# 但是这个过程还是存在上述问题
#t3c 在tcc的基础上增加了最终一致性
假如在提交的事务时候协调者宕机，可以自动提交，
但是还是没有解决上面的问题

非事务MQ事务一致性

咱们试想一下，如果用MQ保证事务一致性，是不是只需要做到发送端本地事务提交后，MQ中有数据即可
那接收端呢，是不是只需要保证数据从MQ中取出数据，然后在确认消费之前保证本地事务一定提交就可以了

# 那么这个过程还是需要保证MQ是高可用的状态，目前能保证高可用的MQ市面上有很多。
# 那么流程咱们可以简单的拆解下

先执行本地事务：
	1、执行本地事务
	2、发送消息
	那么咱们做一个假设，先执行本地事务，后发送消息
		如果消息发送失败怎么办？如何保证MQ中一定存在数据？
			咱们试想下，DB1中有两张表是不是一定可以做到ACID？可以是吧
			那么咱们是不是可以在DB1中新建一个消息表，这时候业务数据是消息表数据是一致的。
			假如消息发送失败了，咱们可以使用定时器轮训发送消息表，通过回调服务重新发送消息。如果达到发送次数，再考虑下面操作。
如果是先执行发送消息呢？
	如果消息发送成功，本地事务执行失败，就会造成数据不一致了。

事务MQ

上面咱们分析过非事务MQ，如果先发送消息，会导致数据不一致，那如果支持事务的MQ呢

# 如果是支持事务的MQ咱们先发送消息是不是可以呢？可以的
支持事务的MQ有消息确认的特性；
咱们可以先梳理下
1、发送消息
2、执行本地事务
3、本地事务执行成功，确认消息
4、如果消息确认失败，流程结束
5、如果本地事务执行失败，回滚消息	
这样就保证了数据的一致性

大家是不是发现事务的MQ消息就不需要定时任务去支持了？

结论

MQ保证分布式事务时，如果MQ不支持事务，那么一定需要定时任务支持，如果支持事务，不需要额外处理