分布式事务解决方案

背景

分布式事务，后端开发中比较常见啦。因为在面试的时候，总是有interviewers让我给他普及一下分布式事务，虽然我会的也不多呀但是还是浅浅说一说；
今天心血来潮，好好地总结一下分布式事务，希望每一位后端工程师都能彻底理解分布式事务。

什么是分布式事务?

答：既然是分布式，首先必然是分布式系统中的一个概念啦。单体应用没这个东西，也不需要这个东西。本地事务就够啦，Spring给我们提供的注解@Transactional, InnoDB引擎会为我们保证事务的ACID特性。但是分布式系统中，目前大多数互联网公司都在用分布式系统，微服务架构等。所以，学好分布式事务太有必要。废话不多说，直接上原理。
总结来说，分布式事务涉及了多个独立的数据源（数据库）或者参与者的事务操作，这些数据源分布在不同的计算机或网络中；分布式事务确保在不同节点之间的多个操作要么全部成功，要么全部失败。

分布式事务解决方案

2PC

两阶段提交协议，也叫XA协议。主要包含两个阶段，第一个阶段是预备阶段，第二个阶段是提交阶段。
2PC协议首先有分事务协调者角色和事务参与者。协调者是事先指定好的一个节点。参与者是一些涉及到数据库操作的表，暂时可以这样理解。这些多个参与者一般是分布在不同的节点上。

• 准备阶段。协调者向所有参与者发送事务准备请求，参与者执事务操作，并回复协调者准备就绪的消息；如果多个参与者中有一个参与者未准备就绪或者发生错误，那么协调者会发送中止请求。只有所有参与者都回复准备就绪，才会进入第二阶段。
• 提交阶段。所有参与者都已经准备就绪，协调者分别发送提交的消息，参与者收到消息以后，执行事务的提交操作，并向协调者回复提交完成。
  协调者收到了所有事务参与者提交完成的消息后，整个分布式事务才算提交完成。如果有一个参与者未能提交或者发生错误，那么协调者会向所有参与者发送中止请求，进行事务的回滚操作。

如何评价2PC？

1、2PC有单点故障的问题。一旦事务协调者故障（因为是使用到了某个节点嘛），那么整个事务将无法继续进行，陷入故障。
2、数据不一致。如果协调者在发送提交信息时，只有部分参与者收到了消息，并执行了提交，此时网络异常，就导致只有部分参与者执行了事物的提交，另一部分则没有提交，从而造成一个数据不一致性。
3、阻塞风险。如果准备阶段，有一个参与者无法响应或者失败，那么整个系统都会陷入阻塞状态，等待超时处理。
4、性能问题。整个链路是串行的，响应时间较长，不适合高并发的场景。

3PC

三阶段提交又称3PC，相对于2PC来说增加了CanCommit阶段和超时机制。如果某段时间内没有收到协调者的commit请求，那么就会自动进行commit，解决了2PC单点故障的问题。
但是性能问题和数据不一致性问题还是没解决。3PC的步骤是这样的：
1、询问节点。CanCommit, 首先询问参与者，是否有能力完成此次事务？

• 如果都返回yes，则进入第二阶段
• 有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求。
  2、准备阶段；同2PC。需要注意的是，参与者收到消息后开始执行事务操作，会首先将Undo和Redo信息记录到事务日志中。参与者执行完事务操作后，向协调者反馈ACK, 表示已经准备好提交了。
  3、提交阶段。同2PC。

TCC

本地消息表

本地消息表+MQ最终一致性事务

Seate

Saga