分布式系统常见的四种数据一致性模型

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

引言

好文分享

本篇翻译自：https://hazelcast.com/blog/navigating-consistency-in-distributed-systems-choosing-the-right-trade-offs/

将介绍四种常见的数据一致性模型：强一致性、顺序一致性、因果一致性、最终一致性。

强一致性

强一致性，也称为线性化，确保所有客户端在写入操作后立即看到最新数据。每个操作在其调用和完成之间的某个时刻瞬时发生，表现得好像数据只有一份副本。这种方法保证了所有节点对数据具有统一、实时的视图，从而更容易在分布式系统中推理正确性。

关键技术

共识协议（例如 RaftPaxos）：领导者通过在节点间达成多数一致来协调写入，确保即使在故障发生时也能保证正确性。
实时顺序（线性化）：操作被序列化，并尊重其实时调用顺序，这意味着在一个节点上完成的写入会立即对所有后续系统中的读取可见。

权衡

• 优点
  通过消除过时读取和防止双重支付等异常来保证正确性。
  通过一致的数据视图简化应用逻辑。
• 缺点
  由于需要基于多数原则的同步操作，导致高延迟。
  在网络分区期间，可用性降低，因为写入操作可能会阻塞，直到达成共识。

使用案例

金融交易和账本：银行和支付应用中，实时正确性和操作严格排序至关重要，以防止双重支付或余额不一致等异常。
分布式协调：像领导者选举和分布式锁这样的系统需要严格同步，以确保任务或资源在节点间一致管理。
配置和元数据管理：分布式系统通常依赖共享配置或元数据（例如系统设置、配额或状态信息）。强一致性确保对这些值的更新立即在所有节点间同步，防止冲突状态。

顺序一致性

顺序一致性确保所有操作按逻辑顺序发生。执行结果就像所有操作都是单独执行的一样，保持了每个客户端发出操作的顺序。与强一致性不同，顺序一致性不强制实时排序，允许在保持可预测行为的同时进行性能优化。

关键技术

全局排序：所有客户端观察到操作按相同顺序进行，确保没有客户端看到顺序错乱的事件。
全局排序：所有客户端观察到操作按相同顺序进行，确保没有客户端看到顺序错乱的事件。

权衡

• 优点
  适用于操作顺序比即时可见性更重要的场景。
  与强一致性相比，由于不需要严格的实时保证，同步开销较低。
• 缺点
  由于全局排序约束，比最终一致性慢。
  缺乏实时保证可能导致时间敏感应用出现异常。

使用案例

游戏系统：确保所有玩家的操作按正确顺序执行，例如回合制游戏中的走动，即使操作未实时同步。
协作编辑：保证在共享工作空间中更新按顺序应用，例如文档编辑平台，确保所有协作者的修改按正确顺序显示。

因果一致性

因果关系一致性确保具有因果关系操作的节点间按正确顺序查看。该模型平衡了一致性和性能，非常适合协作应用或不需要严格实时一致性的系统。

关键技术

依赖跟踪：像向量时钟或版本化时间戳这样的工具捕获并尊重因果关系。
部分排序：因果关系相关的事件按顺序应用，而不强制无关操作的全局排序。

权衡

• 优点
  协作或实时系统中的直观行为。
  一致性和性能之间的平衡权衡。
• 缺点
  比最终一致性更复杂。
  由于依赖跟踪，延迟略高。
  整个系统不强制执行总排序。

使用案例

协作平台：像 Google Docs 或共享工作空间这样的工具，其中因果关系相关的更新（例如编辑文本和应用格式）必须按正确顺序发生。
消息应用：确保消息按发送顺序送达，在对话中保持逻辑连贯性，而无需全局同步。

最终一致性

最终一致性允许节点之间存在暂时的不一致性，并保证所有节点最终会收敛到相同的状态。这种模型通常用于 AP 系统，牺牲即时一致性以确保系统在网络故障或分区期间保持响应。在实践中，最终一致性意味着更新会在副本之间异步传播，导致暂时性的差异。然而，系统保证所有节点最终会同步到相同的状态。

关键技术

异步复制：写入操作在后台传播，允许低延迟更新，但会导致暂时性的不一致。
Gossip 协议：节点以点对点方式通信以共享更新，确保所有节点收敛到相同数据。
纠熵：使用梅克尔树等数据结构来检测和协调副本之间的差异的技巧。
合并冲突解决：使用最后写入者胜出、向量时钟或自定义逻辑等策略来解决冲突写入。

会话保证

会话保证旨在通过确保客户端的操作（写入）即使在系统处于不一致状态时也能始终如一地对用户可见，从而提升用户体验。这些保证包括：

• 读取你的写入（RYW）：一旦客户端执行写入操作，同一会话内的所有后续读取都会反映该写入。这种方法确保用户能看到他们的更新，即使系统在所有节点上不是完全一致的。
• 单调读：一旦客户端看到一个特定值，后续的读操作将永远不会显示更旧值，防止数据出现倒退。
• 写操作跟随读操作：在读取一个值后，所有后续操作都将看到该客户端所做的任何写操作，确保会话内的逻辑一致性。

权衡

• 优点
  即使在分区期间也能保持高可用性和低延迟。
  非常适合高需求、读密集型系统进行扩展。
• 缺点
  临时不一致可能导致陈旧或冲突的读取。
  应用逻辑必须处理潜在的数据冲突。

使用案例

Web 缓存：确保高速数据访问，可容忍临时的不一致性，例如提供过期的会话数据或缓存的网页。
库存数量：跟踪跨分布式仓库或地区的库存，容忍短暂的冲突，同时确保最终收敛到准确的总量。

应该选择哪个模型？

Model	Summary 摘要	Best for… 最适合…	Trade-Offs to Consider 需要考虑的权衡
Strong Consistency (Linearizability) 强一致性（线性化）	Guarantees all clients see the latest data immediately after a write (real-time order). 确保所有客户端在写入后立即看到最新数据（实时排序）。	Critical systems requiring precise ordering and real-time correctness. 需要精确排序和实时正确性的关键系统。	High latency due to quorum-based operations; reduced availability during network partitions. 由于基于多数原则的操作导致的高延迟；网络分区期间可用性降低。
Sequential Consistency 顺序一致性	Ensures all operations are seen in the same order by all clients, but not in real-time. 确保所有操作对所有客户端都以相同顺序可见，但不是实时可见。	Systems prioritizing the order of operations over immediate visibility. 优先考虑操作顺序而非即时可见性的系统。	Slower than eventual consistency; lacks real-time guarantees for time-sensitive applications. 比最终一致性慢；对时间敏感的应用缺乏实时保证。
Causal Consistency 因果关系一致性	Maintains order for operations with cause-and-effect relationships. 维持具有因果关系操作的正确顺序。	Collaborative systems or messaging apps where logical ordering matters but strict synchronization isn’t needed. 在逻辑排序重要但不需要严格同步的协作系统或消息应用中。	More complexity than eventual consistency; slightly higher latency for tracking dependencies; no total ordering across the system​. 比最终一致性更复杂；跟踪依赖性时延迟略高；系统内没有完全排序​。
Eventual Consistency 最终一致性	Allows temporary inconsistencies between nodes, ensuring they converge over time. 允许节点之间存在临时不一致性，确保它们随时间收敛。	High-availability systems, such as web caching, social media, and CDNs, where occasional stale reads are acceptable. 高可用性系统，如网络缓存、社交媒体和 CDN，偶尔的过时读取是可以接受的。	Temporary inconsistencies can lead to stale or conflicting reads; requires conflict resolution. 临时不一致性可能导致过时或冲突的读取；需要冲突解决。