1. 数据一致性基础
聊数据一致性之前，我先问大家一个问题：你往数据库里写了一条记录，下一秒读到的数据，一定是你刚写进去的吗？
嗯，这个问题看似简单，但在分布式系统里，答案可没那么绝对。我当年刚接触分布式时，就被这个问题坑过——一个订单系统，用户付款成功了，结果查询订单状态还是"待支付"。用户炸了，我也懵了。
说白了，数据一致性就是：多个副本之间的数据，能不能保持同步。你更新了一个节点，其他节点知不知道？什么时候知道？知道后怎么处理冲突？
核心定义：数据一致性是指分布式系统中，多个数据副本在任意时刻都保持逻辑上的相同状态。它决定了系统对外呈现的数据视图是否"正确"。
1.1 CAP定理：分布式系统的"不可能三角"
2000年，Eric Brewer教授提出了CAP定理。我记得第一次看到这个定理时，心里想的是：这不就是"鱼和熊掌不可兼得"吗？
CAP三个字母分别代表：
- C（Consistency）一致性：所有节点在同一时刻看到的数据是一样的
- A（Availability）可用性：每个请求都能获得一个响应（无论成功或失败）
- P（Partition Tolerance）分区容错性：系统允许网络分区，即节点之间通信中断时仍能工作
定理说得很清楚：三者最多同时满足两个。你想想看，网络分区在分布式系统中是必然发生的，所以P必须选。剩下的就是在C和A之间做取舍。
| 选择 | 典型系统 | 特点 |
|---|---|---|
| CP（一致+分区） | ZooKeeper、Etcd | 网络分区时，牺牲可用性保证数据一致 |
| AP（可用+分区） | Cassandra、DynamoDB | 网络分区时，允许数据不一致，但保证始终可用 |
| CA（一致+可用） | 单机数据库 | 不存在网络分区时才能同时保证，分布式场景不现实 |
我的经验：实际项目中，我建议先问自己一个问题——"我的系统能接受短暂的数据不一致吗？"如果能，走AP；如果不能，走CP。没有绝对的对错，只有适合不适合。
1.2 BASE理论：对CAP的务实妥协
CAP定理太"硬"了，现实中很多系统其实不需要那么严格的一致性。于是就有了BASE理论。说白了，BASE就是"别那么较真"。
BASE三个核心思想：
- BA（Basically Available）基本可用：系统允许部分功能降级，但核心功能必须可用。比如双十一时，订单系统可以延迟非核心数据的查询
- S（Soft State）软状态：允许数据在一段时间内处于"中间状态"。比如订单刚创建时是"待支付"，过一会儿才变成"已支付"
- E（Eventually Consistent）最终一致性：数据最终会达到一致，但中间可以不一致。这个"最终"可能是几毫秒，也可能是几秒
我曾经在一个电商项目中，把库存扣减从强一致性改成了最终一致性。刚开始团队很担心，怕超卖。后来我们加了一层补偿机制——如果发现超卖，就自动退款。结果呢？用户体验反而更好了，因为响应速度从200ms降到了20ms。
注意：BASE不是"随便搞"的借口。最终一致性需要配合补偿机制、幂等设计、冲突检测等手段，否则数据会乱成一锅粥。我曾经见过一个团队，把最终一致性理解成"不管了"，结果数据对账对了一周。
1.3 一致性模型：从强到弱的谱系
一致性模型，说白了就是"数据同步的严格程度"。从最严到最松，大概有这么一个谱系：
强一致性（Strong Consistency）
这是最严格的一致性模型。你写入一条数据后，任何后续的读操作，都能读到最新的值。就像你写了一张纸条贴在墙上，任何人来看，看到的都是你刚贴上去的那张。
实现方式：通常使用分布式共识算法，比如Paxos、Raft。ZooKeeper就是典型的强一致性系统。
代价：性能差。每次写入都要等所有节点确认，延迟高。我做过一个测试，强一致性的写入延迟是最终一致性的10倍以上。
最终一致性（Eventual Consistency）
这是最宽松的模型。你写入数据后，系统不保证你立刻能读到。但只要没有新的写入，所有副本最终都会达到一致。
DNS系统就是典型例子。你修改了一个域名解析记录，全球的DNS服务器可能需要几分钟甚至几小时才能全部更新。但最终，所有人都会看到新的记录。
适用场景：社交媒体的点赞数、评论数、非关键的业务数据。
因果一致性（Causal Consistency）
这个模型比较有意思。它不强求所有操作都一致，但要求有因果关系的操作必须按顺序被看到。
举个例子：你发了一条朋友圈"我辞职了"，然后朋友评论"恭喜"。如果另一个用户先看到"恭喜"，再看到"我辞职了"，那逻辑就乱了。因果一致性保证：有因果关系的操作，顺序不能乱。
我在一个协作编辑系统中用过因果一致性。用户A修改了文档第1行，用户B修改了第2行。这两个操作没有因果关系，所以谁先谁后无所谓。但如果用户B的修改依赖于用户A的修改，那就必须保证顺序。
选择建议：
- 金融交易、库存扣减 → 强一致性
- 用户资料、商品信息 → 最终一致性
- 社交动态、协作编辑 → 因果一致性
知识体系总览
下面这张图，我把本章的核心知识点串起来了。你可以把它当作一个"地图"，后面讲到具体技术时，随时回来对照。
一个小建议：刚开始学一致性时，别急着背概念。先想清楚你的业务场景——用户能等多久？数据错了会怎样？想明白了，选型自然就清晰了。
可可精品资料库