一、分布式事务的起源：从单机到分布式的演进
1.1 单机时代的“岁月静好”
说实话，我刚入行那会儿，哪有什么分布式事务的概念。
那时候一个应用就部署在一台服务器上，数据库也在一台机器上。业务逻辑简单，数据量也不大。用户下单，扣库存，生成订单——这三个操作都在同一个数据库事务里完成。
代码大概长这样：
BEGIN TRANSACTION;
UPDATE inventory SET stock = stock - 1 WHERE product_id = 123;
INSERT INTO orders (user_id, product_id, amount) VALUES (1, 123, 99.00);
COMMIT;你看，一个事务搞定。要么全部成功，要么全部回滚。数据一致性？天然就是一致的。我当年做电商系统时，这种写法用了好几年，从来没出过问题。
核心要点：单机环境下，ACID 特性天然保障了数据一致性。你不需要额外操心。
2.2 为什么要走向分布式？
但好景不长。用户量上来了，数据量也上来了。
单机扛不住了。CPU 飙到 100%，数据库连接池被打满，磁盘 IO 成了瓶颈。我记得有一次双十一，系统直接挂了半小时，老板急得直跺脚。
怎么办？拆！
- 垂直拆分：把订单、库存、用户拆成独立的服务
- 水平拆分：把一张表拆成多张表，分散到不同数据库
- 读写分离：主库写，从库读
你想想看，一个下单请求，现在要跨三个服务、三个数据库。原来一个事务能搞定的事，现在变成了三个独立的事务。
注意：分布式不是你想拆就能拆的。拆完之后，数据一致性问题就来了。
2.3 数据一致性问题的本质
说白了，分布式事务要解决的核心问题就一个：多个独立节点之间的数据，如何保持最终一致？
举个例子。用户下单，扣库存成功，但生成订单失败了。库存少了，订单没生成。用户付了钱，拿不到货。这能忍？
反过来，扣库存失败，但订单生成了。库存没少，订单却多了一个。用户下单成功，发货时发现没货。这更坑。
为什么会这样？因为每个服务都有自己的数据库，它们之间没有全局的事务管理器。每个服务只能保证自己那一亩三分地的 ACID，跨服务的操作就失控了。
本质总结：分布式事务 = 在多个自治节点上，模拟出单机事务的原子性和一致性。
2.4 CAP 定理：分布式系统的“不可能三角”
说到分布式系统，CAP 定理是绕不开的。我当年第一次看到这个定理时，心里想的是：这不就是“鱼和熊掌不可兼得”吗？
CAP 定理说：一个分布式系统，最多只能同时满足以下三个特性中的两个：
| 特性 | 含义 | 通俗理解 |
|---|---|---|
| C（一致性） | 所有节点在同一时刻看到的数据是一样的 | 你写入了数据，别人立刻就能读到 |
| A（可用性） | 每个请求都能得到响应（成功或失败） | 系统不挂，随时能用 |
| P（分区容错性） | 系统在网络分区时仍能正常工作 | 网络断了，系统还能跑 |
你想想看，网络分区是必然发生的。所以 P 是必选的。剩下的 C 和 A，你只能二选一。
- CP 系统：牺牲可用性，保证一致性。比如 Zookeeper、Etcd。网络分区时，非主节点不可用。
- AP 系统：牺牲一致性，保证可用性。比如 Eureka、Cassandra。网络分区时，数据可能不一致，但系统还能用。
我的经验：大部分业务场景，选 AP 更合适。因为用户不能接受系统不可用。数据不一致，可以通过补偿机制修复。系统挂了，用户直接流失。
2.5 BASE 理论：对 CAP 的妥协与升华
既然 CAP 告诉我们不能既要又要，那怎么办？BASE 理论给出了答案。
BASE 是 Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）的缩写。
- 基本可用：系统允许出现部分功能降级，但核心功能必须可用。比如双十一时，订单查询可以延迟几秒，但不能查不了。
- 软状态：允许系统存在中间状态，数据可以暂时不一致。比如订单状态是“处理中”，而不是“成功”或“失败”。
- 最终一致性：经过一段时间后，所有节点的数据会达成一致。比如转账后，A 账户扣了钱，B 账户可能延迟几秒才到账，但最终会到账。
说白了，BASE 理论就是：别追求强一致性，追求最终一致性就够了。
我做过一个支付系统，用户付款后，订单状态先标记为“支付中”，然后异步通知库存服务扣库存。如果库存扣失败了，再发补偿消息回滚支付。整个过程可能持续几秒，但用户感知不到。最终数据是一致的。
核心思想：BASE 理论不是放弃一致性，而是用“最终一致性”换“高可用性”。
2.6 本章知识体系图
下面这张图，帮你理清本章的核心逻辑：
2.7 避坑指南
我曾经踩过的坑：
- 别一上来就上分布式事务。先问问自己：真的需要拆吗？单机能扛就扛着。
- 别迷信强一致性。大部分业务场景，最终一致性就够了。强一致性意味着高延迟和低可用性。
- 别忽略网络分区。网络一定会出问题，你的系统必须能优雅降级。
我的建议：先从 BASE 理论入手，理解“最终一致性”的设计思想。然后根据业务场景，选择合适的分布式事务方案。别想着一个方案打天下。
好了，这一章就到这里。分布式事务的起源和理论基础，我们已经讲清楚了。下一章，我们会深入具体的分布式事务方案，看看 2PC、TCC、消息队列这些技术到底怎么用。