2025年8月07日·1 分钟
分布式数据库：在一致性与可用性之间权衡
了解为什么分布式数据库在故障时常常放宽一致性以保持可用性，CAP 和仲裁如何工作，以及何时选择不同策略。
了解为什么分布式数据库在故障时常常放宽一致性以保持可用性，CAP 和仲裁如何工作，以及何时选择不同策略。
当数据库分布在多台机器（副本）上时，你获得了更好的速度和弹性——但同时也会出现这些机器暂时无法完全达成一致或无法可靠通信的情况。
一致性的意思是：一次写成功后，所有人的读都返回相同的值。如果你更新了个人资料的邮箱，下一次读取——无论哪个副本响应——都应返回新的邮箱地址。
在实际系统中，优先保证一致性的系统可能会在故障期间延迟或拒绝某些请求，以避免返回冲突答案。
可用性的意思是：系统对每个请求都有响应，即使有些服务器宕机或断开。你可能不会得到最新的数据，但会得到一个回答。
在实践中，优先保证可用性的系统可能会在副本尚未达成一致时继续接受写入和提供读取，然后在以后再进行差异修复。
“权衡”意味着你不能在每种故障场景下同时把两个目标最大化。如果副本无法协调，数据库必须要么：
合适的平衡取决于你能容忍哪种错误：短时间的停机，还是短时间的错误/过期数据。大多数实际系统会在两者之间选一个点，并把权衡明确化。
当数据在多台机器（节点）上存储和服务时，这就是“分布式”数据库。对应用来说，它仍可能看起来像一个数据库——但在底层，请求可能由不同地点的不同节点处理。
大多数分布式数据库会复制数据：同一条记录存放在多台节点上。团队这样做是为了：
复制很强大，但它会立即提出一个问题：如果两台节点都有相同数据的副本，如何保证它们总是保持一致？
在单台服务器上，“宕机”通常很明显：机器要么在，要么不在。在分布式系统里，故障往往是部分的：某个节点可能存活但很慢，网络链路可能丢包，某一整排机架可能失去连通而集群的其他部分仍在运行。
这很关键，因为节点无法瞬间知道另一个节点是真正宕机、暂时不可达，还是仅仅延迟。在它们等待得知情况时，仍必须决定如何处理到达的读和写请求。
在单机上，有一个事实来源：每次读都能看到最新的成功写。
在多节点上，“最新”依赖于协调。如果一次写在节点 A 成功但节点 B 无法联系，数据库应该：
这种张力——由不完美网络现实化——就是分布改变规则的原因。
网络分区是指节点间的通信断裂，这些节点本应作为一个数据库一起工作。节点可能仍然运行且健康，但由于交换机故障、链路过载、错误路由、误配置的防火墙或云网络中的“吵闹邻居”，消息无法可靠交换。
一旦系统分布在多台机器上（通常跨机架、可用区或区域），你便无法控制它们之间的每一跳。网络会丢包、引入延迟，有时会分成“孤岛”。在小规模时这些事件罕见；在大规模时它们日常化。即使短暂中断也会影响，因为数据库需要持续协调来达成对发生事项的共识。
分区期间，双方都在接收请求。如果用户可以在两侧写入，每一侧可能接受对方看不到的更新。
例子：节点 A 将用户地址更新为“新街”。同时节点 B 将其更新为“旧街 2 号”。每一侧都相信自己的写是最新的——因为实时比对的途径被切断。
分区不会以整齐的错误信息呈现；它会表现为令人困惑的行为：
这正是当网络无法保证通信时，分布式数据库必需做出选择的压力点：优先一致性还是优先可用性。
CAP 是描述当数据库分布在多台机器上时会发生什么的简洁方式。
当没有分区时，许多系统看起来既一致又可用。
当发生分区时，必须选择优先级：
balance = 100 写到服务器 A。balance = 80。CAP 并不是叫你“永远只选两个”。它的意思是：在发生分区时，你无法同时保证 一致性 和 可用性。在没有分区时，很多系统在大多数时间里可以接近两者兼顾——直到网络出现异常为止。
选择一致性意味着数据库把“所有人看到同一事实”置于“始终响应”之上。实际上，这通常指向强一致性，常被描述为线性化（linearizable）：一旦写被确认，任何后来的读（无论在哪）都返回该值，就像存在一个单一的、最新的副本一样。
当网络分裂且副本无法可靠通信时，强一致性的系统不能安全地在两侧同时接受独立更新。为了保护正确性，它通常会：
从用户角度看，这可能表现为停机，即便有些机器仍在运行。
主要好处是推理更简单。应用代码可以像在与一台数据库交互一样工作，而不是面对可能不一致的多个副本。这能减少诸如：
此外，对于审计、计费以及任何必须一次性正确的场景，模型会更清晰。
一致性有真实代价：
如果你的产品不能容忍部分宕机期间的请求失败，强一致性即便正确，也可能显得代价昂贵。
选择可用性意味着你把一个简单的承诺放在首位：系统会在大多数故障情况下做出响应。在实践中，“高可用”并不等于“永远无错误”——而是指在节点故障、复制压力或网络断裂时，大部分请求仍能得到响应。
当网络分裂时，副本无法可靠通信。优先可用性的数据库通常会继续从可达的一侧服务流量：
这让应用能继续运行，但也意味着不同副本可能在短期内接受不同的“真相”。
你得到更好的正常运行时间：即便某一区域被隔离，用户仍能浏览、往购物车放商品、发表评论或记录事件。
在高压下，你还会得到更平滑的用户体验：你的应用可以用“你的更新已保存”来替代超时并在后台同步。对于很多消费类和分析类工作负载，这样的权衡是值得的。
代价是数据库可能返回过期读取：用户在一台副本更新资料后，立即在另一台副本读取可能看到旧值。
你也面临写冲突：两个用户（或同一用户在两地）可能在分区两侧更新同一记录。分区恢复后，系统必须调和分叉的历史：视规则而定，可能由某一方“胜出”、按字段合并，或需要应用层逻辑介入。
优先可用的设计就是接受短暂的分歧以保证产品继续响应——然后投资于如何检测并修复这些分歧。
仲裁是许多复制数据库用来平衡一致性与可用性的实用“投票”技术。系统不是信任单个副本，而是询问“足够多”的副本达成一致。
你常会看到用三个数字描述仲裁：
一个常见经验法则是：如果 R + W > N，那么每次读取都会与某次成功写的副本集合至少有交集，从而降低读到过期数据的概率。
如果有 N=3 个副本：
有些系统会把 W=3（所有副本）作为更强的一致性方案，但只要任一副本慢或宕机，就会导致更多写失败。
仲裁并不能消除分区问题——它定义了“谁被允许继续前进”。如果网络分裂成 2–1，拥有 2 个副本的一侧仍能满足 R=2 和 W=2，而孤立的单个副本则不能。这可以减少冲突更新，但也意味着部分客户端会看到错误或超时。
仲裁通常带来更高的延迟（需要联系更多节点）、更高的成本（跨节点流量）和更细化的失败行为（超时看起来像不可用）。好处是一个可调的中间地带：你可以根据重要性把 R 和 W 调整为更偏向读取新鲜或写入成功。
最终一致性意味着允许副本临时不同步，只要它们最终收敛到相同的值。
想象一个连锁咖啡店在更新某个点心的“售罄”标志。一家店标记为售罄，但这个更新需要几分钟才能到达其他门店。在这一窗口期，另一家店可能仍显示“有货”并卖出了最后一份。系统并没有“坏”——更新只是在赶着同步。
当数据尚在传播中，客户端可能观察到令人生疑的行为：
最终一致性系统通常添加后台机制以缩短不一致窗口：
当可用性比绝对及时性更重要时，它适用：活动流、查看计数、推荐、缓存的用户资料、日志/遥测等非关键数据，在这里“过一会儿正确”通常是可接受的。
当数据库在多个副本上接受写入时，可能产生冲突：在临时无法同步期间，不同副本对同一项做了独立更新。
经典例子是用户在一台设备上更新收货地址，同时在另一台设备上改了电话号码。如果两个更新在临时断开时落到不同副本上，系统在副本交换数据后必须决定什么是“真实”记录。
许多系统以最后写胜开始：时间戳最新的更新覆盖其他更新。
它吸引人的地方在于实现简单且计算快速。缺点是它会静默丢失数据：如果“最新”获胜，旧但重要的更改可能被覆盖——即便两个更新修改的是不同字段。
它还假定时钟可信。机器或客户端之间的时钟偏移会导致“错误”更新获胜。
更安全的冲突处理通常需要追踪因果历史。
概念上，版本向量（及其简化变体）会为每条记录附带一小段元数据，概述“哪个副本看到了哪些更新”。当副本交换版本时，数据库能检测到某个版本是否包含另一个（表示无冲突），或它们是否发生分歧（需要解决冲突）。
一些系统使用逻辑时间戳（如 Lamport 时钟）或混合逻辑时钟，以减少对墙钟时间的依赖，同时仍提供排序提示。
一旦检测到冲突，你有多种选择：
最佳方法取决于你的数据对“正确”的定义——有时丢失一次写是可接受的，有时则是严重的业务错误。
选择一致性/可用性的策略不是哲学争论，而是产品决策。先问自己：短暂出错的代价是多少？“请稍后再试”的代价又是多少？
某些领域在写时需要权威答案，因为“差不多正确”仍然是错误的：
如果临时不一致的影响较小或可逆，你通常可以偏向更可用的设计。
许多用户体验可以接受略微过期的读取：
明确“可接受过期”是多少：秒、分钟还是小时？这个时间预算将驱动你的复制和仲裁选择。
当副本无法达成一致时，通常会出现三种 UX 结果之一：
按功能而非全局决定最不令人反感的选项。
当错误结果带来财务/法律风险、或有安全/不可逆动作时，偏向 C（一致性）。
当用户重视响应速度、过期数据可容忍且冲突可安全修复时，偏向 A（可用性）。
若不确定，则拆分系统：关键记录保持强一致性，派生视图（Feeds、缓存、分析）则优化为可用性更高。
你很少需要在整个系统上只选择一种“一致性设置”。许多现代分布式数据库允许你按操作选择一致性——智能的应用会利用这一点，在不掩盖权衡的情况下保持良好用户体验。
把一致性当作一个旋钮，根据用户行为调整：
这样避免为所有操作支付最强一致性的成本，同时保护真正重要的操作。
常见模式是写强、读弱：
有时也会反过来：快速写入（排队/最终一致）加上强读取以确认结果（“我的订单下好了吗？”）。
网络不稳定时，客户端会重试。用幂等键使重试安全，确保“提交订单”被执行两次不会创建两个订单。在遇到相同键时存储并重用第一次的结果。
对于跨服务的多步操作，使用Saga：每一步都有对应的补偿动作（退款、释放预留、取消发货）。这样即便部分流程临时不同步或失败，系统也可恢复。
如果你看不到一致性/可用性的表现，就无法管理它。生产问题常常看起来像“随机失败”，直到你加上合适的测量与测试。
从一小组与用户影响直接相关的指标开始：
如能做到，按 一致性模式（仲裁 vs 本地）和 区域/可用区 打标签，以发现行为分歧的来源。
不要等到真实故障。在预发布环境做混沌实验，模拟：
验证的不仅仅是“系统是否继续运行”，还要看哪些保证得以保持：读是否保持新鲜，写是否被阻塞，客户端是否得到明确错误？
加入以下告警：
最后，把你的保证写清楚：文档说明系统在正常运行与分区期间承诺什么，并教育产品与支持团队用户可能看到的情况以及如何应对。
如果你在新产品中探索这些权衡，尽早验证假设很有帮助——尤其是故障模式、重试行为以及在 UI 上“过期”看起来如何。
一个实用方法是先为工作流做一个小型原型（写路径、读路径、重试/幂等性和调和任务），再决定架构。使用像 Koder.ai 这样的工具，团队可以通过聊天驱动的工作流快速搭建 Web 应用和后端，迭代数据模型和 API，并测试不同一致性策略（例如严格写 + 放松读），而无需传统构建流水线的开销。当原型行为符合预期时，可以导出源码并逐步演进为生产系统。
在复制的数据库中，“相同”的数据存在于多台机器上。这提升了可靠性并能降低延迟，但也带来了协调问题：节点可能变慢、无法到达或被网络分割，因此不能总是即时达成一致，导致一致性与可用性之间的权衡。
一致性意味着：在一次写操作成功之后，任何后续的读都会返回该值——无论由哪个副本提供服务。实际系统通常通过延迟或拒绝读/写请求，直到足够的副本（或领导者）确认更新来实现这一点。
可用性意味着系统在每次请求时都会返回非错误响应，即便部分节点宕机或无法通信。响应可能是过期的、部分的或基于本地状态，但系统在故障期间尽量避免阻塞用户。
网络分区是指原本应协同工作的节点之间出现通信中断。节点本身可能仍然健康，但消息无法可靠地跨越分隔。这迫使数据库在两种取舍中选择：
在分区期间，双方都可能接受它们看不到对方的更新，导致：
这些都是副本临时无法协调时的用户可见表现。
它并不意味着“永远只能选两个”。它的含义是：当发生分区时，你不能同时保证：
在没有分区的情况下，许多系统在大部分时间里看起来既一致又可用——直到网络出现问题为止。
仲裁（quorum）通过让多个副本“投票”来平衡一致性与可用性：
常见指导是 R + W > N，这样每次读至少会与某次成功写的副本集合重叠，从而降低读取过期数据的概率。仲裁并不能消除分区，但它决定了谁可以继续前进（例如拥有多数的一侧）。
最终一致性允许副本在短时间内不同步，只要它们最终收敛即可。常见异常包括：
系统通常用 读修复、提示转发（hinted handoff） 和定期的 反熵（anti-entropy） 校验来缩短不一致窗口。
当不同副本在断开期间接受了对同一项的不同写时，就会发生冲突。常见的解决策略有：
选择策略应基于对“正确”含义的判断：有时丢弃写是可接受的，有时是不可接受的业务错误。
基于业务风险和用户能容忍的失败模式来决定：
实用做法包括按操作设定一致性级别、用幂等键保护重试、以及用补偿事务（sagas）处理跨步工作流的回滚。通常把关键数据设计为强一致，派生视图为高可用更为稳妥。