为什么双十一零点你抢不到票？

🔒 事务：最初的“一手交钱一手交货”

在业务看来，转账就是原子操作：A 少钱，B 多钱。要么都成功，要么都失败，绝不能出现 A 扣了钱 B 没收到的情况。

动作	代码行数 (理想状态)	描述
开启事务	1 行	`BEGIN TRANSACTION;`
扣钱	1 行	`UPDATE account SET balance = balance - 100 WHERE id = A;`
加钱	1 行	`UPDATE account SET balance = balance + 100 WHERE id = B;`
提交	1 行	`COMMIT;`

总计：4 行 SQL。

程序员觉得这逻辑完美无缺。直到并发（Concurrency）这个恶魔降临。

⚛️ 第一关：原子性的代价 (Atomicity)

刚上线，服务器断电了。

A 的钱扣了。
电断了。
B 的钱没加上。
结果：100 块钱凭空蒸发了。用户打爆了客服电话。

代码增加：你必须引入复杂的回滚机制 (Rollback)。在代码里包裹try-catch，一旦第二步报错，必须把第一步扣的钱吐出来。如果数据库本身挂了，还得靠日志（Redo Log/Undo Log）恢复。+30 行异常处理逻辑。

👻 第二关：脏读与幻读的迷魂阵 (Isolation)

为了快，数据库允许很多人同时读写。

脏读：事务甲正在改 A 的余额（还没提交），事务乙读取了 A 的余额。结果事务甲回滚了！事务乙读到的是假数据。
幻读：事务甲查了一下：“现在有 3 个订单”。事务乙突然插进去新增了一个订单。事务甲一回头：“怎么变成 4 个了？见鬼了？”

代码增加：你开始调整隔离级别 (Isolation Level)。
级别越高（如 Serializable），数据越安全，但速度越慢（排队）。
级别越低（如 Read Committed），速度越快，但全是 Bug。
你需要在性能和数据准确性之间走钢丝。+N 行配置和锁策略分析。

🔫 第三关：死锁——墨西哥僵局 (Deadlock)

这是最经典的灾难。两个线程同时操作，互相卡死。

场景：两个人同时转账。

线程 1 (A 转给 B)：

锁住 A（扣钱）。
准备去锁 B（加钱）。

线程 2 (B 转给 A)：

锁住 B（扣钱）。
准备去锁 A（加钱）。

僵局：

线程 1 拿着 A，瞪着 B。
线程 2 拿着 B，瞪着 A。
谁也不松手，谁也走不掉。

后果：
数据库连接被这两个人占着，永远不释放。后续的请求全部排队，直到连接池爆满，全站瘫痪。

代码增加：强制规定**“加锁顺序”。所有转账必须先锁 ID 小的，再锁 ID 大的**。
if (idA < idB) { lock(A); lock(B); } else { lock(B); lock(A); }
+20 行逻辑判断，且很容易写错。

🚧 第四关：全表锁的误杀 (Table Lock)

你写了个 SQL：UPDATE account SET balance = balance - 100 WHERE name = '张三';
注意：你用了name，但name字段没有索引！

数据库的逻辑：
“你要锁张三？但我不知道张三在哪行啊。为了防止你改错，我先把整张表锁起来吧！”

后果：
一个人买牛奶（锁表），导致全超市的人都不能结账。
本来是行级锁（Row Lock），瞬间升级为表级锁（Table Lock）。系统吞吐量从 10000 QPS 跌到 1 QPS。

代码增加：疯狂补索引，做 Explain 分析，严禁在事务中使用非索引字段作为条件。+DBA 的咆哮。

🕸️ 第五关：分布式事务的深渊 (Distributed Transaction)

系统做大了，拆成了微服务。

账户服务在数据库 A。
积分服务在数据库 B。
本地事务（@Transactional）失效了！因为它管不了两个数据库。

后果：
钱扣了（库 A），积分没加（库 B 挂了）。
你不能回滚库 A，因为那是别人的库。

代码增加：欢迎来到地狱。
TCC (Try-Confirm-Cancel)：每个接口都要写三个方法：预留、确认、撤销。
Seata / 2PC：引入沉重的分布式事务框架。
最终一致性：写消息队列，不断重试，告诉用户“处理中”，其实是后台在疯狂补救。
代码量翻倍，逻辑复杂度指数级上升。