Distributed Consistency Overview

Distributed data consistency refers to maintaining data consistency between multiple replicas in a distributed system. This is one of the core challenges of distributed systems, especially when the network is unreliable and nodes may fail.

Why Do We Need Replicas?

Reasons for distributed systems to maintain multiple data replicas:

  • High Availability: When one node fails, other replicas can continue to serve
  • Load Balancing: Read/write requests distributed across multiple nodes
  • Geographic Distribution: Place data in different locations to reduce latency

Core Challenges

  1. Network Latency: Even within a data center, there are millisecond-level differences
  2. Concurrency Control: When two clients simultaneously update different replicas
  3. Failure Handling: During network partitions, some nodes may not receive updates

Consistency Types

1. Strong Consistency

  • All read operations can see the latest written data
  • Typical applications: Google Spanner, Zookeeper
  • Use cases: Financial systems, inventory management

2. Weak Consistency

  • Does not guarantee reading the latest data
  • Typical applications: Caching systems (Redis)

3. Monotonic Read Consistency

  • Ensures users will not see old data after seeing new data
  • Solution: Hash user ID to specific machine

4. Causal Consistency

  • If node A notifies node B after updating data, node B will see the updated value

5. Eventual Consistency

  • A “weaker” consistency model—all replicas will eventually become consistent
  • Most common model in distributed systems
  • Typical applications: Amazon Dynamo, Cassandra, CDN, DNS
  • Trades high availability for temporary inconsistency

CAP Theorem Relationship

In distributed systems, you can only guarantee two of the following three: Consistency (C), Availability (A), Partition Tolerance (P):

  • CP (Strong Consistency): Zookeeper, Etcd, Spanner
  • AP (Eventual Consistency): Cassandra, DynamoDB
  • CA: Single-node database (cannot tolerate partitions)

Consistency Algorithms

  • Paxos: Classical algorithm, theoretically complete but complex
  • Raft: Designed for understandability, used in Etcd, Consul, TiKV
  • Zab: Zookeeper’s consistency protocol

Application Scenarios

  • Distributed locks: Strong consistency (Zookeeper, Etcd)
  • Configuration center: Strong consistency
  • High-performance NoSQL: Eventual consistency (Cassandra)
  • Microservices registration: Can accept weak consistency
  • Distributed cache: Weak consistency (Redis Cluster)