分布式事务
分布式事务就是一个大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
CAP定理
分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。
- C（一致性）：一致性指的是多个数据副本能否保持一致性的状态。对系统的一个数据更新之后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。
- A（可用性）：可用性指分布式系统在面对各种异常时可以提供正常服务的能力。
- P（分区容忍性）：当出现网络分区后，系统能够继续工作。打个比方，集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
在分布式系统中，分区容忍性必不可少，因为需要总是假设网络是不可靠的。因此只能是保证CP或者AP。
- 为了保证一致性（CP），不能访问未同步完成的节点，失去了部分可用性。
- 为了保证可用性（AP），允许读取所有节点的数据，但是数据可能不一致。
2PC
两阶段提交（Two-phase Commit，2PC），通过引入事务协调者来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。
- 准备阶段（第一阶段）：事务协调者询问参与者事务是否执行预提交（将Undo信息和Redo信息写入日志，但不commit事务）成功，参与者返回事务预提交执行结果。
- 提交阶段（第二阶段）：如果事务在每个参与者上都预提交成功，事务协调者发送通知让参与者提交事务（执行commit操作），参与者执行事务提交成功，会释放在整个事务期间内占用的资源，然后向事务协调者发送“完成”消息。事务协调者收到所有参与者节点反馈的“完成”消息后，完成事务。回滚操作类似（参与者利用之前写入的Undo信息执行回滚）。
2PC存在的问题
- 同步阻塞：所有事务参与者在等待其他事务参与者响应的时候都处于同步阻塞状态，无法进行其他操作
- 单点问题：事务协调者在2PC中扮演着重要的角色，发生单点故障将会造成很大影响。
- 数据不一致问题：如果在提交阶段，事务协调者只发送了部分的commit消息或者因为网络原因只有部分参与者接收到了commit消息，会导致只有部分事务参与者没有提交事务，造成数据不一致。
本地消息表
本地消息表的核心就是将分布式处理的任务通过消息日志（如本地消息表）的方式来异步执行。本地消息表和业务数据表处于同一个数据库，这样就可以利用本地事务保证对这两个表的操作满足事务特性，并且利用消息队列来保证最终一致性。
例如A转账给B一百元，业务数据表中执行A-100和将B+100写入本地消息表这两个操作处于同一个本地事务中。
- 在分布式事务操作中的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
- 之后将本地消息表中的消息转发到消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
- 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。
本地消息表是BASE理论，只能保证最终一致性，适用于对一致性要求不高的场景。
RocketMQ分布式事务
RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，通过在执行本地事务前后发送两条消息来保证本地事务与发送消息的原子性，过程如下图：
事务消息详细过程说明
- 事务发起方首先发送 prepare 消息到 MQ。
- 在发送 prepare 消息成功后执行本地事务。
- 根据本地事务执行结果返回 commit 或者是 rollback。
- Producer发送确认消息到broker（也就是将步骤3执行的结果发送给broker），这里可能broker未收到确认消息，下面分两种情况分析：
- 如果broker收到了确认消息：如果收到的结果是commit，则broker视为整个事务过程执行成功，将消息下发给Conusmer端消费；如果收到的结果是rollback，则broker视为本地事务执行失败，broker删除Half消息，不下发给consumer。
- 如果broker未收到了确认消息：broker定时回查本地事务的执行结果；（由用户实现）如果本地事务已经执行则返回commit；如果未执行，则返回rollback；
- Consumer 端的消费成功机制有 MQ 保证，如果消费超时，则需要重试，Consumer端需要保证幂等。如果消息仍然消费失败（小概率事件），则需要人工来进行处理。