1. 分布式事务概述：什么是分布式事务、为什么需要分布式事务、CAP理论与BASE理论
大家好，我是你们的老朋友。今天咱们正式开讲分布式事务。
说实话，我刚开始做分布式系统那会儿，最头疼的就是事务问题。单体应用里，一个 @Transactional 注解搞定的事，到了微服务架构下，怎么就变得这么复杂？
嗯，别急。咱们一步步来。
1.1 什么是分布式事务
先说说定义。
分布式事务，说白了就是跨多个独立数据库或服务的事务操作。它要保证这些分散的资源，要么全部成功，要么全部失败。
举个例子。你在电商平台下单：
- 订单服务要创建订单
- 库存服务要扣减库存
- 账户服务要扣钱
这三个操作，分别由三个不同的微服务处理，数据也落在不同的数据库里。但它们必须作为一个整体来对待——这就是分布式事务要解决的问题。
核心要点：分布式事务的本质，是在分布式环境下维持数据的一致性。
1.2 为什么需要分布式事务
你可能会问：单体应用不是挺好的吗？为什么非要搞分布式？
我个人的经验是，当业务规模大到一定程度，单体应用就扛不住了。
- 数据库连接数不够：一个库撑不住高并发
- 业务耦合严重：改一行代码要重启整个应用
- 扩展性差：某个模块流量暴涨，却要整体扩容
所以，我们不得不把系统拆成多个服务。但拆完之后，问题就来了——数据一致性怎么保证？
我在项目中遇到过这样一个场景：用户支付成功后，订单状态更新了，但积分系统挂了，积分没加上。用户投诉说「我付了钱，为什么没给我积分？」
你看，这就是典型的分布式事务问题。
1.3 CAP理论
聊分布式事务，绕不开CAP理论。这是分布式系统的基石。
| 特性 | 说明 |
|---|---|
| C - Consistency（一致性） | 所有节点在同一时刻看到的数据是一样的 |
| A - Availability（可用性） | 每个请求都能获得一个响应（无论成功或失败） |
| P - Partition Tolerance（分区容错性） | 系统允许网络分区，即使部分节点失联，系统仍能运行 |
CAP理论告诉我们：三者不可兼得，最多只能满足两个。
为什么会这样？
你想想看，如果网络发生了分区（比如机房断网），你只能二选一：
- 要么放弃一致性，让各节点继续提供服务（AP）
- 要么放弃可用性，等数据同步后再响应（CP）
我刚开始做分布式系统时，总想着「我全都要」。结果呢？系统要么慢得要死，要么数据对不上。后来才明白，在分布式世界里，你必须做出取舍。
避坑指南：我曾经在一个金融项目中，为了追求强一致性，选择了CP架构。结果网络抖动时，整个系统不可用，业务直接瘫痪。后来改成了AP + 最终一致性方案，虽然数据有短暂不一致，但系统可用性从99%提升到了99.99%。
1.4 BASE理论
既然CAP理论告诉我们不能全都要，那实际工程中怎么玩？
BASE理论给出了答案。它是CAP理论在实践中的延伸。
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 允许系统在故障时损失部分可用性 |
| S | Soft State（软状态） | 允许数据存在中间状态 |
| E | Eventually Consistent（最终一致性） | 经过一段时间后，数据最终会达到一致 |
说白了，BASE理论就是放弃强一致性，追求最终一致性。
我个人的习惯是，在大多数业务场景下，优先选择BASE方案。因为：
- 用户能接受「稍后到账」，但不能接受「系统打不开」
- 数据短暂不一致，可以通过补偿机制修复
- 系统可用性高，用户体验更好
我的经验：判断用强一致性还是最终一致性，有个简单标准——看业务是否涉及「钱」或「法律」。比如转账、订单状态变更，可以用最终一致性；但账户余额扣减，建议用强一致性。
1.5 小结
好了，咱们总结一下今天的内容：
- 分布式事务：跨多个服务/数据库的事务操作
- 为什么需要：微服务拆分后，数据一致性无法靠单库事务保证
- CAP理论：一致性、可用性、分区容错性，三者只能选其二
- BASE理论：基本可用、软状态、最终一致性——工程实践中的妥协方案
下一章，咱们会深入聊聊2PC（两阶段提交），看看这个经典的分布式事务协议到底是怎么工作的。到时候我会分享一个我踩过的坑——嗯，那可真是一段难忘的经历。
咱们下章见。