一、分布式事务基础：CAP理论与BASE理论
大家好，我是你们这堂课的老朋友。今天咱们聊聊分布式事务的根基——CAP和BASE。
说实话，我刚接触分布式系统那会儿，也被这些理论绕得头晕。但后来我发现，搞懂它们，就像拿到了分布式世界的「交通规则」。不懂规则，你写的代码早晚会出事故。
1.1 CAP理论：分布式系统的「不可能三角」
CAP理论是分布式系统的基石。它说：一个分布式系统，最多只能同时满足以下三个特性中的两个：
- C（Consistency）一致性：所有节点在同一时刻看到的数据是一样的。
- A（Availability）可用性：每个请求都能收到一个响应（不管成功还是失败）。
- P（Partition Tolerance）分区容错性：系统内部出现网络分区（节点间通信断了），系统仍能正常工作。
你想想看，网络分区在分布式系统里是必然发生的。所以P你必须选。剩下的，你只能在C和A之间二选一。
核心结论：分布式系统，本质上是CP或AP的选择题。
CP vs AP：怎么选？
| 场景 | 选择 | 典型系统 |
|---|---|---|
| 银行转账、库存扣减 | CP（强一致性） | ZooKeeper、Etcd |
| 社交动态、商品浏览 | AP（最终一致性） | Eureka、Cassandra |
我在项目中遇到过这么个事：一个电商系统的库存服务，为了追求高可用，选了AP。结果双十一大促时，两个用户同时下单同一件商品，库存都显示有货，但实际只够一件。嗯，这就是AP的代价——你接受了数据可能不一致。
我的建议：核心交易链路（支付、库存）选CP，非核心链路（日志、推荐）选AP。别一刀切。
1.2 BASE理论：向现实妥协的智慧
BASE理论是CAP中AP方案的实践总结。它说：既然强一致性做不到，那我们就追求「最终一致性」。
- BA（Basically Available）基本可用：系统允许部分功能降级，但核心功能必须可用。
- S（Soft State）软状态：允许系统存在中间状态，数据可以暂时不一致。
- E（Eventually Consistent）最终一致：经过一段时间后，所有数据最终会达成一致。
说白了，BASE就是「别太较真」。你想想看，你在淘宝下单后，订单状态从「待支付」变成「已支付」，中间可能有个短暂的「支付中」状态——这就是软状态。过几秒后，它最终会变成「已支付」。
注意：最终一致性不是「永远不一致」。它要求系统在某个时间窗口内（比如5秒、30秒）必须达成一致。这个时间窗口，就是你的业务容忍度。
1.3 ACID vs BASE：两种哲学
ACID是单机数据库的「完美主义」，BASE是分布式系统的「实用主义」。咱们来对比一下：
| 维度 | ACID | BASE |
|---|---|---|
| 一致性 | 强一致性，事务内立即可见 | 最终一致性，允许短暂不一致 |
| 可用性 | 低（锁冲突、死锁风险） | 高（无锁或少锁） |
| 性能 | 低（频繁IO、锁等待） | 高（异步、批量处理） |
| 典型场景 | 银行、金融、库存 | 社交、日志、推荐 |
我记得有一次，一个同事非要用ACID去实现一个点赞功能。结果呢？每次点赞都要锁行，并发一上来，数据库直接打满了。后来改成BASE，用消息队列异步处理，性能提升了10倍。所以啊，别拿ACID当万能药。
1.4 分布式事务的核心挑战
搞清楚了理论，咱们来看看实际落地时，你会遇到哪些坑。
挑战一：网络不可靠
分布式系统里，网络是最不靠谱的。你发一个请求，对方可能收到了，也可能没收到。更麻烦的是，你永远不知道对方是「没收到」还是「收到了但响应丢了」。这就是著名的「二将军问题」。
挑战二：时钟不同步
不同机器的系统时间可能差几毫秒甚至几秒。你依赖时间戳来判断先后顺序？小心翻车。我见过一个案例，因为时钟不同步，导致两个节点对同一笔订单的状态判断完全相反。
挑战三：节点故障
节点随时可能宕机。你正在执行一个跨库事务，突然一个节点挂了。已提交的部分怎么办？未提交的部分怎么回滚？这就是分布式事务要解决的核心问题。
挑战四：数据一致性
多个节点同时修改同一份数据，怎么保证最终一致？是选「悲观锁」还是「乐观锁」？是「强一致性」还是「最终一致性」？没有标准答案，只有权衡。
一句话总结：分布式事务的本质，就是在不可靠的网络和节点上，模拟出可靠的事务行为。
1.5 知识体系总览
下面这张图，是我自己梳理的本章知识体系。你可以把它当作一张「地图」，后面每讲一个技术点，你都可以回来看看它在哪个位置。
这张图把CAP、BASE和核心挑战串在了一起。你往后学的时候，可以经常回来看看，心里有个全局观。
避坑指南：我曾经在一个项目中，团队全员都懂CAP，但没人懂BASE。结果设计出来的系统，要么强一致性导致性能崩盘，要么完全不管一致性导致数据乱套。后来我强制要求每个方案都要标注「选CP还是AP？最终一致时间窗口是多少？」，这才把问题控制住。
好了，这一章就到这里。记住：理论是死的，业务是活的。别被CAP和BASE框死，要学会在它们之间找到平衡点。
公众号:蓝海资料掘金营，微信deep3321