分布式一致性概述

分布式数据一致性是指在分布式系统中多个副本（replicas）之间保持数据一致。这是分布式系统的核心挑战之一，尤其是在网络不可靠和节点可能发生故障的情况下。

为什么需要副本？

分布式系统维护多个数据副本的原因：

  • 高可用性：当一个节点故障时，其他副本可以继续服务
  • 负载均衡：读/写请求分布在多个节点上
  • 地理分布：将数据放置在不同位置以减少延迟

核心挑战

  1. 网络延迟：即使在数据中心内，也有毫秒级的差异
  2. 并发控制：当两个客户端同时更新不同副本时
  3. 故障处理：网络分区期间，某些节点可能无法接收更新

一致性类型

1. 强一致性（Strong Consistency）

  • 所有读操作都能看到最新写入的数据
  • 典型应用：Google Spanner、Zookeeper
  • 使用场景：金融系统、库存管理

2. 弱一致性（Weak Consistency）

  • 不保证读取到最新数据
  • 典型应用：缓存系统（Redis）

3. 单调读一致性（Monotonic Read Consistency）

  • 确保用户看到新数据后不会再看到旧数据
  • 解决方案：将用户 ID 哈希到特定机器

4. 因果一致性（Causal Consistency）

  • 如果节点 A 在更新数据后通知节点 B，节点 B 会看到更新后的值

5. 最终一致性（Eventual Consistency）

  • “较弱”的一致性模型——所有副本最终会变得一致
  • 分布式系统中最常见的模型
  • 典型应用：Amazon Dynamo、Cassandra、CDN、DNS
  • 以高可用性换取暂时的不一致性

CAP 理论关系

在分布式系统中，只能在以下三者中保证两者：一致性（C）、可用性（A）、分区容错性（P）：

  • CP（强一致性）：Zookeeper、Etcd、Spanner
  • AP（最终一致性）：Cassandra、DynamoDB
  • CA：单节点数据库（无法容忍分区）

一致性算法

  • Paxos：经典算法，理论上完整但复杂
  • Raft：为可理解性设计，用于 Etcd、Consul、TiKV
  • Zab：Zookeeper 的一致性协议

应用场景

  • 分布式锁：强一致性（Zookeeper、Etcd）
  • 配置中心：强一致性
  • 高性能 NoSQL：最终一致性（Cassandra）
  • 微服务注册：可以接受弱一致性
  • 分布式缓存：弱一致性（Redis Cluster）