分布式事务
1，什么是分布式事务
本地事务：用关系型数据库来控制的事务，事务都具有 ACID 四大特性，其中这里的 C 指的是强一致性，依赖于 AID 实现而实现。Mysql 实现事务依靠日志、MVCC、ReadView 等手段。
分布式事务：指在分布式系统中，多个系统共同操作一个事务，这个事务可以是发生在一个数据库，也可以发生在多个数据库，这些都是分布式事务问题。还有一种情况是，我们的业务进行了分库操作，一个业务涉及到多个数据源，也算是分布式事务问题。
可见，只要出现跨系统的数据交互操作都涉及到分布式事务问题。典型的场景有，电商系统的订单系统和库存系统；金融场景中的充值缴费等。
2，分布式事务处理的理论依据
2.1，CAP 理论
分布式事务问题该如何处理，通常我们要遵循 CAP 理论。
CAP：—致性 (Consistency)；可用性 (Availability)；分区容错性 (Partition Tolerance)。只能三选其二。
一致性要求，客户端从节点读取数据必须是一致的；可用性要求，客户端从节点读取数据不一定是最新的，但必须能读到数据；分区容错性要求，节点故障时，其他节点仍能提供服务。P 是分布式系统中必须要实现的。
CAP 的组合方式：
1、CA：放弃分区容忍性，加强一致性和可用性，比如关系数据库按照 CA 进行设计；
2、AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多 NoSQL 数据库按照 AP 进行设计。 说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可。
3、CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按 CP 进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
我们实际系统设计中，采用的是 AP+最终一致性的方案。比如我们的订单退款，延迟到账的形式。
2.2，Base 理论
BASE 理论是 CAP 理论中 AP 的延申，强调基本可用（Basically Available）、软状态 (Soft State) 和最终一致性 (Eventual Consistency)。
基本可用：牺牲部分可用，保障核心系统的正常运行；
软状态：运行中存在中间状态，比如主从同步中的延时；
最终一致性：在最终的某个时间达到一致性。
3，分布式事务解决方案
3.1，2PC
即两阶段提交协议，通过引入一个事务管理器作为协调者实现。
第一阶段：投票。事务管理器向参与者发送 CanCommit 请求，其他节点同意，则执行请求中的事务操作，写入日志；不同意则终止操作；
第二阶段：提交。事务管理器收到所有节点的 yes 回复后，则向参与者发送 DoCommit 提交指令执行提交操作；否则，则发送回滚指令 DoAbort，参与者在本地执行回滚操作，事务结束。
分析：事务中存在同步阻塞问题，单点故障问题，数据不一致问题（部分参与者网络异常了）。2PC 实现了强一致性，比如 Mysql 中的 redolog 日志提交就采用了 2PC 方案。
3.2，3PC
2PC 的改进，引入预提交和超时机制，解决 2PC 中的同步阻塞问题。分为 CanCommit，PreCommit，DoCommit 阶段。3PC 的特点是，如果长时间没有收到响应，则默认提交事务，而不像 2PC 那样一致阻塞。
但是 3PC 无疑增加了系统的通信复杂度，而且也会锁住资源，不能解决数据一致性问题。
3.3，TCC
2PC 的改进，注重事务补偿。不同于 2PC，3PC 在数据库层面实现事务，TCC 是在业务层面解决事务问题。包括 Try，Confirm，Cancle 三个阶段。TCC 事务方案接口需要满足幂等性，而且每个接口需要实现 Try，Confirm，Cancle 接口，开发成本高。
3.4，消息队列实现最终一致性
即通过消息队列的重试机制，不断重试，实现最终一致性。前提是业务接口具备幂等性。