分布式事务这玩意儿，说白了就是多个节点上的操作要么dou成功，要么dou失败，听起来简单，但Zuo起来可不容易。

Zui直接的思路就是锁。事务在读写数据前先获取锁，其他事务Ru果请求冲突的锁就必须等待。由此衍生出两种设计哲学：悲观并发控制与乐观并发控制。

说实话，咱就是说这两种策略没有绝对的优劣，hen多数据库会混合使用。

而在分布式事务中，使用严格两阶段锁——实际系统中Zui常用的变体——规则geng加严格：事务在提交或中止之前，必须持有所有Yi经获取的锁。不允许在中间释放任何锁。

两阶段提交是Zui经典的原子提交协议。

协调者向所有参与者发送 Prepare 消息，询问：“你们准备好提交这个事务了吗？”

每个参与者收到后：持久化日志并加锁，然后回复 Vote-Yes 或 Vote-No。

sequenceDiagram participant C as 协调者 participant P1 as 参与者 A participant P2 as 参与者 B C->P1: Prepare C->P2: Prepare P1->P1: 持久化日志，加锁 P2->P2: 持久化日志，加锁 P1-->C: Vote-Yes P2-->C: Vote-Yes . 第二阶段：提交/中止阶段 情况 A：所有参与者dou回复 Vote-Yes

协调者决定提交向所有参与者发送 Commit 消息，参与者收到后完成事务提交并释放锁。

协调者决定中止向所有参与者发送 Abort 消息，参与者回滚事务并释放锁。

flowchart TD Start --> WaitVotes WaitVotes --> VoteCheck{收集投票} %% 正常流程分支 VoteCheck -->|全部 Vote-Yes| SendCommit VoteCheck -->|任一 Vote-No 或超时| SendAbort SendCommit --> |没有意外情况发生| ParticipantCommit SendAbort --> ParticipantAbort %% ========== 故障处理子图 ========== subgraph 故障处理 %% 参与者准备阶段崩溃 P1 --> P1Check{崩溃前Yi持久化<br>Vote-Yes 日志？} P1Check -->|是| P1Yes P1Check -->|否| P1No

在发送 Commit 前崩溃若协调者在Zuo出提交决定后、发送 Commit 消息前崩溃，所有投了 Vote-Yes 的参与者会因收不到Zui终决策而超时。此时参与者绝对不Neng单方面中止，因为协调者Yi经决定了提交，只是消息未发出。害，你懂的，这就是典型的阻塞问题。

为啥百度不收录我的文章？哈哈，这个问题问得好，其实主要原因是内容质量、关键词优化、以及外链建设没Zuo好，你得确保你的内容是有价值且原创的，同时关键词要合理分布，还要多和其他高质量站点Zuo些链接，说白了就是要让搜索引擎觉得你的内容值得被收录。

假设有两个事务：转账事务 T1 把 A 账户的 x 元转入 B 账户 步骤① ：A 余额减去 x 步骤② ：B 余额加上 x 统计事务 T2 计算 A 、B 的总资产，并将结果写入数据库 操作 ：Write

sequenceDiagram participant T1 as 转账事务 T1 participant DB as 数据库 participant T2 as 统计事务 T2 T1->DB: 读取 A 余额 T1->DB: 写入 A = A - x T2->DB: 读取 A T2->DB: 读取 B Note over T2: 求和得到 + B = A + B - x T1->DB : 写 入 B = B + x T1->DB : 提 交 T2->DB : 写 入统 计结 果 A + B - x 结果 ：T2 Zui终写入的总额比实际少了 x 。Ru果这是银行系统的日终报表，就会造成对账错误 。你kan，这多么危险 ！咱就是说这种错误是不Neng接受的 。

Ru果允许事务在使用数据后立即释放锁，就会破坏可串行化，甚至破坏原子性 。这就像那个那个，不对不对，应该是举个例子，比如 T1 先修改了某个数据，然后立即释放了写锁，随后 T2 马上读取并使用了这个数据，但此时 T1 还没提交呢 ！这不就乱套了吗 ？所以必须坚持“两阶段锁 ”原则 —— 所有加锁dou在扩张阶段完成，所有释放dou在收缩阶段完成 。咱就是说这样才Neng保证万无一失 。你懂的 ！

常见死锁处理方法 两个事务互相等待对方持有的锁，导致dou无法推进： 预防死锁：一开始就一次性申请所需的所有资源，或者严格按固定顺序加锁。 检测死锁：周期性扫描“等待图”，一旦发现环路就主动 Abort 其中一个事务。 那为啥工业界后来又搞出了 Paxos Commit 、三阶段提交这些改进方案 ？其实就是为了缓解这个阻塞问题嘛 ！虽然复杂性增加了不少，但总得想办法提升系统的可用性呀 ！你说是吧 ！