分布式事务在当下互联网场景下是比较多的现象。例如下单场景下，库存和订单如果不在同一个节点上，就涉及到分布式事务。

在分布式系统中，要实现分布式事务，有以下几种解决方案。

主流的是如下三种思想：

两阶段提交，通过引入协调者来协同参与者的行为，并最终决定这些参与者是否真正执行事务。

1.1协调者询问参与者事务是否执行成功，参与者发回事务执行结果。

1.2如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回事务。

需要注意，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

1.3存在的问题有下面两点：

01.同步阻塞，所有的事务参与者都在等待其他参与者响应的时候都是处于阻塞状态，无法进行其他的操作。

02.单点问题，协调者在2PC中起到非常大的作用，发生故障将会造成很大的影响。特别是阶段二发生故障，所有参与者会一直等待，无法完成其他操作。

03.数据不一致，在阶段二，如果协调者只发送了部分commit消息，此时网络故障，那么只有部分参与者接收到commit消息，也就是只有部分参与者提交了事务，会造成数据的不一致。

04.任意一个节点的失败都会导致整个事务失败，没有完整的容错机制。

本地消息表与业务数据表在同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。

1、在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。2、之后将本地消息表中的消息转发到kafka等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。3、在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

优点：一种经典的实现，避免了分布式事务，实现了最终一致性。

缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多多余的操作。

MQ事务消息

有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ是不支持事务消息的，kafka等都不支持。以阿里的RocketMQ中间件为例，其思路大致为：

第一阶段prepared消息，会拿到消息的地址。第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。也就是说业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了，RocketMQ会定期扫描消息集群中的事务消息，这时候发现了prepared消息，他会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置额的策略来决定回滚还是继续发送确认消息。这样就保证了消息发送和本地事务同成功或者同时失败。

优点是：实现了最终的一致性，不需要依赖本地数据库事务。

缺点：实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。

番外篇：

架构设计思维模型：

1. 大道至简，回归到事物的本质

2. CAP思维模型

3. BASE思维模型

4. 业务场景Blance思维模型

架构设计能力：
    1.以不变应万变：不变：思维模型；变：场景

    2.给出优雅的架构设计方案：优雅，合适，适度超前

架构设计的终极之道：降本增效