分布式系统中的不一致性解决：版本控制
Source: Dev.to
现代分布式数据库，如 Amazon DynamoDB 和 Apache Cassandra，在多个服务器之间复制数据，以提升 可伸缩性、容错性和可用性。然而，复制会带来一个主要挑战：并发更新期间的数据不一致。为了解决这个问题，分布式系统使用一种称为 版本控制 的技术。
为什么需要版本控制
在一个 最终一致性系统 中，更新由于 网络延迟或分区 而无法同时到达所有副本。
考虑一个拥有三个副本的系统：
N = 3
Replicas: s0, s1, s2两个客户端同时更新同一个键：
Client A → put(key1 = 10)
Client B → put(key1 = 20)由于网络延迟，副本可能暂时存储 不同的值：
s0 = 10
s1 = 20
s2 = 10现在系统中出现了 同一键的冲突值——即 写冲突。
版本控制的作用
版本控制使系统能够跟踪写入的历史。每次更新都会分配一个版本标识符。
(key1, value = 10, version = v1)
(key1, value = 20, version = v2)系统不会立即覆盖数据，而是可能临时存储同一值的多个版本。这有助于系统判断：
- 哪个写入发生得更早
- 两个写入是否并发发生
两种可能的情况
1. 一个版本更新
v1 → value = 10
v2 → value = 20如果系统检测到 v2 在 v1 之后发生，则更新的版本会替换旧的版本：
v2 replaces v1在这种情况下，不会产生冲突，因为系统知道写入的正确顺序。
2. 并发版本
有时系统 无法确定写入的顺序。
v1 → value = 10
v2 → value = 20这些更新被视为 并发。数据库不会自动挑选其中一个，而是可能返回 两个版本：
key1:
value1 = 10
value2 = 20此时 客户端应用必须自行解决冲突。
客户端对账
应用程序决定如何解决冲突的值。常见的策略包括：
1. 最后写入获胜
系统选择 时间戳最新 的值。
Latest timestamp → chosen value2. 合并值
可以 将值合并而不是覆盖。在购物车系统中的示例：
cart1 = {apple}
cart2 = {banana}合并结果：
cart = {apple, banana}这种方法确保 没有数据丢失。
3. 应用逻辑
自定义业务规则可以决定正确的值，例如：
- 基于优先级的更新
- 基于用户的冲突解决
- 特定领域的合并逻辑
使用向量时钟的版本控制
一些分布式数据库使用 vector clocks 来跟踪更新历史。向量时钟存储 表示更新历史的节点计数列表。
示例：
v1 = {s0:1}
v2 = {s1:1}如果两个版本具有 不同的历史，系统会将它们视为 并发更新。向量时钟帮助数据库 自动检测冲突，而不必仅仅依赖时间戳。
关键要点
- Versioning enables detection of conflicting updates。
- It allows temporary storage of multiple versions of data。
- Conflicts are resolved through various reconciliation strategies。
This approach supports eventual consistency while keeping the system highly available and scalable。
最后思考
版本控制是分布式系统中的基本技术。它使现代数据库能够在不阻塞写入的情况下保持一致性，这对大规模运营至关重要。通过跟踪更新历史并在后期进行冲突解决，版本控制确保分布式系统保持可靠、灵活且高性能。