分布式事务 一些新的建议
可用性和一致性的冲突：CAP 理论 CAP 定理又被称作布鲁尔定理
P - Partition Tolerance 分区容忍性：The system will continue to function when network partitions occur.
当出现网络分区后，系统能够继续“履行职责”。
这里网络分区是指：一个分布式系统里面，节点组成的网络本来应该是连通的。
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。
因此，分布式系统理论上不可能选择 CA （一致性 + 可用性）架构，只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中选择
CAP 理论的延伸：BASE 理论
BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。
幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。
分布式事务的实现有许多种，其中较经典是由 Tuxedo 提出的 XA 分布式事务协议，XA 协议包含二阶段提交（2PC）和三阶段提交（3PC）两种实现。
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
2PC 方案实现起来简单，实际项目中使用比较少，主要因为以下问题： 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。数据一致性问题：在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。
3PC(三阶段提交)方案：
三阶段提交协议，是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。
优点：相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段 3 中协调者出现问题时，参与者会继续提交事务。
缺点：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
TCC 事务：最终一致性
TCC 事务的 Try、Confirm、Cancel 可以理解为 SQL 事务中的 Lock、Commit、Rollback。
①Try 阶段 主要完成： 完成所有业务检查( 一致性 ) 。预留必须业务资源( 准隔离性 ) 。
②Confirm / Cancel 阶段 根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。
方案总结
TCC 事务机制相对于传统事务机制（X/Open XA），TCC 事务机制相比于上面介绍的 XA 事务机制，有以下优点：性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。 数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。
缺点： TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。
本地消息表：最终一致性
本地消息表的方案最初是由 eBay 提出，核心思路是将分布式事务拆分成本地事务进行处理。
方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。
步骤1：事务主动方处理本地事务。
步骤 2：事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息。
步骤 3：事务被动方通过消息中间件，通知事务主动方事务已处理的消息。
为了数据的一致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等
方案的优点如下： 从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖。 方案轻量，容易实现。
缺点如下：与具体的业务场景绑定，耦合性强，不可公用。消息数据与业务数据同库，占用业务系统资源。业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。
MQ 事务：最终一致性
方案总结
相比本地消息表方案，MQ 事务方案优点是： 消息数据独立存储 ，降低业务系统与消息系统之间的耦合。吞吐量由于使用本地消息表方案。
缺点是： 一次消息发送需要两次网络请求(half 消息 + commit/rollback 消息) 。业务处理服务需要实现消息状态回查接口。
—— 阿里中间件技术专家沈询
有些问题，看起来很重要，但实际上我们可以通过合理的设计或者将问题分解来规避。
设计分布式事务系统也不是需要考虑所有异常情况，不必过度设计各种回滚，补偿机制。
如果硬要把时间花在解决问题本身，实际上不仅效率低下，而且也是一种浪费。
如果系统要实现回滚流程的话，有可能系统复杂度将大大提升，且很容易出现 Bug，估计出现 Bug 的概率会比需要事务回滚的概率大很多。
在设计系统时，我们需要衡量是否值得花这么大的代价来解决这样一个出现概率非常小的问题，可以考虑当出现这个概率很小的问题，能否采用人工解决的方式，这也是大家在解决疑难问题时需要多多思考的地方。
