5.1 一致性谱系：强、最终、因果
5.1 一致性谱系：强一致、最终一致与因果一致
一致性不是"有或无"，而是一根有多个挡位的刻度尺。本节把强一致、顺序一致、因果一致、最终一致四级摆开，各配一个贴近业务的触发场景，并给出一句终极判断：你的客户到底能容忍"读到旧值"到什么程度。
学习目标
阅读完本节，你应当能够：
- 说出四级一致性各自的"核心承诺"与其语义差别。
- 给每级各配一个恰如其分的业务场景，能说清为什么那档刚好够用。
- 用"读后必须看到刚写的自己/相关事件 ≥ 容忍短暂旧值 > 完全可旧值"的三档问法给业务定档。
先校准：很多争论其实争的是同一块地
做分布式的人最爱吵"到底该强一致还是最终一致"。但吵到后面往往发现，双方其实在讲不同层的东西。因为一致性根本不是"要么强要么弱"两个极端，而是一根连续刻度上可选的多个挡位。把挡位分清楚，架就好吵完了——你要做的只是挑一个"刚好够你的业务用"的档，而不是最好或最便宜的档。
一、四挡刻度，逐个讲透
强一致（线性一致性）：写入一提交，任何后续读取（无论走哪台副本）必须立刻看到新值。它是最"诚实"的承诺，代价是写入必须同步到全部/多数副本才敢返回，延迟高、可用性被牺牲。金融账上的余额、扣库存，这类"错一个就翻天"的一定用它。
顺序一致：所有进程看到的是同一个操作顺序，只是这个顺序不必和墙上真实时间对得上。它比强一致宽容一层——仍要求全局一个"序"，但不苛求即时反映时间。适合"大家必须看到一致排序，但可以接受排出来的序和大时钟有偏差"的场景。
因果一致：只对有因果关系的操作保序——先发生的事（因）必须排在相关事件（果）之前被看到；无因果关系的操作可以任意乱序。它极度贴合人类直觉：你发了一条动态（A），有人评论它（B）。那么看到评论 B 的人，必然也看到过动态 A。但两条无关的动态，谁先谁后不重要。社交内容流大量用这一档。
最终一致：不做任何即时序承诺，只保证"安静之后会收敛"。是最便宜、可用性最高的一档，用户看计数、足迹、推荐位这种"少一个无伤大雅"的数据用它正好。
四挡一致性怎么排、谁更贵
下面这张 SVG 把四挡一致性按"强度"架成一架梯子，越往下越强、也越贵：
一致性四级：强度与代价的阶梯
二、为什么"因果一致"是社交产品的心头好
你可能觉得因果一致是个学术名词，但它几乎决定了现代社交那滋味的来源。想想朋友圈墙：你永远不希望"评论比动态还早出现"，观众会一头雾水。这正是因果一致的承诺——因先于果。可同时，朋友圈里两条互不相关的动态，谁先展示都无所谓。因果一致恰到好处地保住了这个直觉：只强约束有因果的操作，其余放任。它给社交产品带来的好处是：零成本地避免了最尴尬的观感，又不必为不相干操作的排序付钱。
三、用三问给业务定档
别被四档吓到，落到实际给业务定档，我通常只问三个问题，像拧旋钮一样选档：
一问，账/库存这类"错读要命"的必须强一致吗？ 必须，直接选强一致，别省。二问，是不是有"显然的先后关系"（如果你看到它，就该看到过它的前提）？ 是，选因果一致，用它换可观的高可用。三问，是不是纯粹可以容忍旧值的海量计数/足迹？ 是，选最终一致最划算。三问走完，挡位基本自动浮现；剩下万分之一的中间地带，再看延迟与成本倒逼你往上还是往下拧。
四挡速查表
| 挡位 | 核心承诺 | 契合业务 | 典型成本 |
|---|---|---|---|
| 强一致 | 写完自见 | 账务、库存 | 高延迟、低可用 |
| 顺序一致 | 全局同序 | 需一致排序 | 中延迟 |
| 因果一致 | 因果相关保序 | 社交、评论 | 低延迟 |
| 最终一致 | 安静收敛 | 计数、足迹 | 极低延迟 |
四、同一款 App 的四个界面，各是拿一档做的
把四档从抽象拉回日常，最直观的办法是看同一款 App 里不同界面各自用哪档：
余额页：你转账成功后立刻刷新，余额必须马上变——强一致，不然你敢把这 App 当钱包用吗？
消息列表页：A 发了一条动态，后面跟着的评论你随时能看到，但两条无关动态谁先谁后无所谓——因果一致，只保"因先于果"。
好友列表页：只要你不来回切换，偶尔进来看到的列表顺序稳定就行——顺序一致，全局排序一致即可，不强求真实时间。
点赞/浏览量：爆款视频的赞数每次刷新跳一跳，跟真实值差几个也无所谓，反正过一会儿会补齐——最终一致。
| 界面 | 用的一致性 | 逼你的问题 | 一句话理由 |
|---|---|---|---|
| 余额页 | 强一致 | 刚写必见？ | 尾款错一分的代价 |
| 好友列表 | 顺序一致 | 排序一致即可？ | 不追求真实时钟 |
| 消息动态 | 因果一致 | 有先后因果？ | 评论别早于动态 |
| 点赞/浏览 | 最终一致 | 能容忍旧值？ | 晚几秒无伤大雅 |
看到这张表你就会发现，一个成熟的团队从来不是"统一用一种一致性"，而是按界面的业务语义给每处配不同的档。这也正是第 2 章说"混合是常态"的落地版——读起来像在选配置，其实是在给每一个数据面画它的接受度边界。
最后补一个进阶观察：档位之间并不是非此即彼，不少数据库允许你对同一个存储空间按请求设档。比如同一个订单表，核心的下单事务走强一致，而后台的"运营看板"统计可以同一份数据以最终一致来读——因为运营晚看几秒汇总毫无影响。这种"同数异档"的能力，很大程度缓解了"选哪档"的焦虑：你不用在系统层面把整片数据钉死在一档，而是每个访问者按自己的语义取档。理解到这一层，你再看一致性，就不再是"选一个"，而是"按人按场景各取所需"了。
本节要点回顾
- 一致性是刻度不是开关：四挡由强到弱，各有各的代价与收益。
- 因果保"因先于果"：社交体验的心头好，也常是分布式库内置的省心档位。
- 强一致=贵：只留给"错读要命"的关键数据。
- 三问定档：错读要命？有因果关系？纯容忍旧值？顺着答案落到挡位。
一致性怎么"约定"讲完了，可一牵涉"多个节点必须同步改"——真正动手时，绕不开那句"到底听谁的"。下一节 5.2 我们先看最直接也最容易滑倒的方案：两阶段提交（2PC）的投票机制。