作者|无敌多么寂寞
来源| urlify.cn/B7ru22
简述
分布式事务是指事务的操作位于不同的节点上，必须确保事务的AICD特性。
例如，在订单场景中，如果库存和订单不在同一节点上，则涉及分布式事务。
解决方案
在分布式系统中，有几种解决方案可以实现分布式事务。
一、分两个阶段提交(2PC )。
两阶段提交(Two-phase Commit，2PC )通过引入协调员)来协调参与者的行为，最终决定这些参与者是否实际执行事务。
1 .运行过程1.1准备阶段
协调员询问参与者事务的执行是否成功，参与者返回事务的执行结果。
1.2提交阶段
如果事务在每个参与者上成功执行，事务协调员将发送通知，以使参与者能够提交事务，否则协调员将发送通知，以使参与者能够回滚事务。
请注意，在准备阶段，参与者执行了事务，但尚未提交。 提交或回滚仅在提交阶段收到协调员的通知后发生。
2 .存在的问题
2.1同步块所有事务参与者在等待其他参与者的响应时都处于同步块状态，不能进行其他操作。
2.2单点问题协调员在2PC上起非常大的作用，一旦发生故障将产生很大的影响。 特别是在阶段2发生故障时，所有参与者都将继续等待，无法完成其他操作。
2.3在数据不匹配阶段2，如果协调员仅发送了部分Commit消息，而网络出现异常，则只有部分参与者会收到Commit消息。 这意味着只有一些参与者发送事务，导致系统数据不匹配。
2.4如果其中一个过于保守的节点失败，整个事务将失败，并且没有完整的容错机制。
二.补偿事务(TCC )
TCC是一种实际采用的补偿机制，其核心思想是对每个操作注册相应的确认和补偿(撤销)操作。 分为三个阶段：
Try阶段主要进行业务系统的检查和资源预约
Confirm阶段主要是业务系统的确认提交，如果Try阶段成功运行，且Confirm阶段开始运行，则默认的Confirm阶段是正确的。 也就是说，如果Try成功，Confirm一定会成功。
在取消阶段，主要保留业务执行错误、取消在需要回滚的情况下执行的业务以及释放资源。
例如，要冒充勤劳的星星汇款给Smith，也许我们有一个本地方法，从那里开始依次调用
首先在Try阶段，必须调用远程接口冻结Smith和勤星的钱。
在Confirm阶段，执行远程调用转账的操作，转账成功解压。
如果步骤2执行成功，则转移成功；如果步骤2执行失败，则调用对应于远程冻结接口的解压缩方法Cancel。
优点：与2PC相比，实施和流程相对简单，但数据一致性不如2PC
缺点：缺点还是比较明显的，两三步都有可能失败。 因为TCC是APP应用层的补偿方式，所以程序员在实现时需要编写很多补偿的代码。 在某些情况下，某些业务流程可能在TCC中没有很好地定义和处理。
三、本地消息单(异步确保) ) ) ) ) ) )。
由于本地消息表与业务数据表位于同一数据库中，因此可以利用本地事务在对这两个表的操作中满足事务特性。 它还使用消息队列来保证最终的完整性。
在分布式事务操作之一完成写入业务数据的操作后，本地事务会向本地消息表发送消息，以确保该消息始终写入本地消息表。
然后将本地消息表中的消息传输到消息队列(如Kafka )，如果传输成功，则从本地消息表中删除消息，否则继续重新传输。
在分布式事务处理操作的另一端从消息队列读取消息，并在消息中执行操作。
优点：在非常经典的实现中，避免了分布式事务，实现了最终的一致性。
缺点：消息单与业务系统相耦合，如果没有封装的解决方案，就会处理很多琐事。
四. MQ事务消息
还有第三方MQ支持事务性消息，如RocketMQ。 类似于采用支持事务性消息的方法的两级提交，如RocketMQ，但也有一些主要的MQ不支持事务性消息，如RabbitMQ和Kafka。
以蚂蚁RocketMQ中间件为例，其思路大致如下。
第一阶段的保留消息获取消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段获得的地址访问消息并修改状态。
也就是说，在业务方法内向消息队列提交两次请求，发送一次消息和一次确认消息。 如果确认消息发送失败，RocketMQ会定期扫描消息群集中的事务性消息。 此时，将检测到Prepared消息，并向消息发送者进行确认。 因此，生产方必须实现check接口。 RocketMQ根据发送方设置的策略，确定是回滚还是继续发送确认消息。 这可以确保消息发送和本地事务同时成功或同时失败。
gn="center">优点： 实现了最终一致性，不需要依赖本地数据库事务。
缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。
总结
通过本文我们总结并对比了几种分布式分解方案的优缺点，分布式事务本身是一个技术难题，是没有一种完美的方案应对所有场景的，具体还是要根据业务场景去抉择吧。阿里RocketMQ去实现的分布式事务，现在也有出了很多分布式事务的协调器，比如LCN等，大家可以多去尝试。