Data Consistency Models and Trade-offs in Distributed Systems

Problem Description
In distributed systems, data consistency models define the rules and strength of data synchronization among multiple replicas. Different consistency models involve trade-offs between performance, availability, and consistency. Please explain common consistency models (such as strong consistency, eventual consistency, etc.) and discuss their applicable scenarios and implementation costs.

Knowledge Background
Distributed systems use data replication to improve reliability and performance, but synchronizing data among multiple replicas introduces consistency issues. A consistency model is a "contract" between system designers and users, clarifying the possible outcomes observable by read and write operations.

1. Strong Consistency

• Description: Any read operation returns the value of the most recent write, as if all operations were executed sequentially on a single-node system.
• Implementation Principles:
  • Common mechanisms include distributed locks, quorum protocols (such as the NWR model), and consensus algorithms (e.g., Raft/Paxos).
  • For example, requiring that reads and writes must go through a majority of nodes (Write-Quorum + Read-Quorum > N) ensures reading the latest data.
• Cost:
  • High latency: Synchronous blocking until data is replicated to a majority of nodes.
  • Low availability: Read/write operations may fail during network partitions.
• Applicable Scenarios: Financial transactions, critical configuration management, and other scenarios where data inconsistency is intolerable.

2. Eventual Consistency

• Description: If there are no new writes, all replicas will eventually converge to a consistent state after some time, but reads and writes may be temporarily inconsistent.
• Implementation Principles:
  • Employs asynchronous replication; write operations only need to update the primary replica or some replicas, with subsequent synchronization via anti-entropy or Gossip protocols.
  • Examples include the DNS system and Cassandra's weak consistency mode.
• Cost:
  • May read stale data (dirty reads).
  • Requires conflict resolution mechanisms (e.g., last-write-wins, vector clocks).
• Applicable Scenarios: Social network likes, comment systems, and other scenarios tolerant of temporary inconsistency.

3. Session Consistency

• Description: Guarantees read-write consistency within the same session, but different sessions may be inconsistent.
• Implementation Principles:
  • Binds a client session to a specific replica or tracks the version number the client has read (e.g., Dynamo's context vectors).
  • For example, after a user modifies a configuration, they will always see their own modifications within the same session.
• Cost:
  • Inconsistency may occur across sessions, but it offers a better user experience than eventual consistency.
• Applicable Scenarios: Web application sessions, user personalization settings.

4. Causal Consistency

• Description: Ensures that causally related operations are consistently ordered, while concurrent operations may be reordered.
• Implementation Principles:
  • Uses vector clocks or version vectors to track causal relationships between operations.
  • For example, if operation A causally precedes B, then all nodes see A before B.
• Cost:
  • Higher metadata overhead due to maintaining vector clocks.
• Applicable Scenarios: Collaborative editing, chat systems, and other scenarios requiring causal logic preservation.

5. Read-Your-Writes Consistency

• Description: A user always reads their own latest writes, but writes from other users may be visible with a delay.
• Implementation Principles:
  • Routes subsequent read requests to synchronized replicas after a write operation (e.g., via sticky sessions or version checks).
• Cost:
  • Requires tracking the client's write history, increasing system complexity.
• Applicable Scenarios: User profile updates, shopping cart operations.

Trade-off Summary

Design Selection Recommendations

• Choose a model based on business requirements for consistency, avoiding over-engineering (e.g., social media does not require strong consistency).
• Understand in conjunction with the CAP theorem: strong consistency leans toward CP, while eventual consistency leans toward AP.
• Combine multiple models (e.g., use strong consistency for core financial systems and eventual consistency for auxiliary features).