持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第23天，点击查看活动详情
分布式事务解决方案
分布式事务的解决方案有很多，比如：2PC、3PC、TCC、本地消息表、MQ 事务（Kafka 和 RocketMQ 都提供了事务相关功能）、Saga 等等。这些方案的适用场景有所区别，我们需要根据具体的场景选择适合自己项目的解决方案。
2PC（两阶段提交协议）
2PC（Two-Phase Commit）这三个字母的含义：
● 2 -> 指代事务提交的 2 个阶段
● P-> Prepare (准备阶段)
● C ->Commit (提交阶段)
2PC 将事务的提交过程分为 2 个阶段：准备阶段 和 提交阶段 。
准备阶段(Prepare)
准备阶段的核心是“询问”事务参与者执行本地数据库事务操作是否成功。
- 事务协调者/管理者 向所有参与者发送消息询问：“你是否可以执行事务操作呢？”，并等待其答复。
- 事务参与者 接收到消息之后，开始执行本地数据库事务预操作比如写 redo log/undo log 日志。但是，此时并不会提交事务！
- 事务参与者 如果执行本地数据库事务操作成功，那就回复：“就绪”，否复：“未就绪”。
提交阶段(Commit)
提交阶段的核心是“询问”事务参与者提交事务是否成功。
当所有事务参与者都是“就绪”状态的话：
- 事务协调者/管理者 向所有参与者发送消息：“你们可以提交事务啦！”(commit 消息)
- 事务参与者 接收到 commit 消息 后执行 提交本地数据库事务 操作，执行完成之后 释放整个事务期间所占用的资源。
- 事务参与者 回复：“事务已经提交”（ack 消息）
- 事务协调者/管理者 收到所有 事务参与者 的 ack 消息 之后，整个分布式事务过程正式结束。
总结
简单总结一下 2PC 两阶段中比较重要的一些点：
- 准备阶段 的主要目的是测试 事务参与者 能否执行 本地数据库事务 操作 (!!!注意：这一步并不会提交事 务）。
- 提交阶段 中 事务协调者/管理者 会根据 准备阶段 中 事务参与者 的消息来决定是执行事务提交还是回滚操 作。
- 提交阶段 之后一定会结束当前的分布式事务
优点与存在的问题
2PC 的优点：
● 实现起来非常简单，各大主流数据库比如MySQL、Oracle 都有自己实现。
● 针对的是数据强一致性。不过，仍然可能存在数据不一致的情况。
2PC 存在的问题：
● 同步阻塞：事务参与者会在正式提交事务之前会一直占用相关的资源。比如用户小明转账给小红，那其他事务也要操作用户小明或小红的话，就会阻塞。
● 数据不一致：由于网络问题或者事务协调者/管理者宕机都有可能会造成数据不一致的情况。比如在第2阶段（提交阶段），部分网络出现问题导致部分参与者收不到commit/rollback 消息的话，就会导致数据不一致。
● 单点问题： 事务协调者/管理者在其中也是一个很重要的角色，如果事务协调者/管理者在准备(Prepare)阶段完成之后挂掉的话，事务参与者就会一直卡在提交(Commit)阶段。
