Data Replication Strategies in Distributed Systems

Problem Description: In distributed systems, data replication is one of the core technologies for ensuring system availability, reliability, and performance. It stores copies of data on multiple nodes to achieve fault tolerance, load balancing, and reduced access latency. Please elaborate in detail on the common data replication strategies in distributed systems, focusing on comparing the principles, workflows, advantages, disadvantages, and typical application scenarios of Master-Slave Replication and Multi-Master Replication.

Solution Process:

The core goal of data replication is to keep data copies distributed across multiple nodes consistent. We will start with the simplest strategy and gradually delve into more complex ones.

Step 1: Understanding the Core Goals and Challenges of Replication

Before diving into strategies, the goals and challenges must be clarified.

• Goals:
  1. High Availability: The system can still provide services even if a node storing data fails.
  2. Low Latency: Users can read data from the nearest replica geographically, reducing network delay.
  3. Scalability (Read): By increasing the number of replicas, a large number of read requests can be shared, improving the system's read throughput.
• Challenges:
  1. Consistency: How to ensure data is the same on all replicas? When new data is written to one replica, when can other replicas reflect this change? This is the core contradiction that replication strategies need to resolve.

Step 2: Master-Slave Replication (Single-Master Replication)

This is the most commonly used and intuitive replication strategy.

1. Role Definition:

   • Master Node: Typically only one. All write requests must be sent to the master node. The master node handles write operations and synchronizes data changes to all slave nodes in the form of logs or events.
   • Slave Nodes: There can be multiple. Slave nodes only receive data synchronization from the master node and handle read requests. Slave nodes are not allowed to directly accept write requests.

2. Workflow:

   • Write Operation:
     1. The client sends a write request to the master node.
     2. The master node executes the write operation locally and updates its data.
     3. The master node sends this data change (e.g., a binary log) to all slave nodes asynchronously or synchronously.
     4. Upon receiving the log, the slave node replays the operation in the same order locally, thereby keeping its data consistent with the master.
   • Read Operation:
     1. The client can send read requests to the master node or any slave node.
     2. Due to synchronization delays, reading from the master node always yields the latest data (strong consistency). Reading from a slave node might yield slightly stale data (eventual consistency).

3. Advantages:

   • Simple and Easy to Understand: Clear logic, easy to implement.
   • Strong Consistency Guarantee: All writes are serialized through the master, avoiding conflicts from concurrent writes across nodes. Reading from the master always provides the latest data.
   • High Read Scalability: Read performance can be scaled by adding numerous slave nodes.

4. Disadvantages:

   • Single Point of Failure Risk: The master node is the sole write point; if it fails, the entire system becomes unwritable. Additional failover mechanisms are required (e.g., electing a new master using algorithms like Raft/Paxos).
   • Write Performance Bottleneck: All write operations are concentrated on one master node; write performance cannot be scaled by adding nodes.
   • Replication Lag: Data synchronization to slaves is asynchronous; at any given moment, a slave's data may lag behind the master's (replication delay).

5. Application Scenarios: Relational databases (e.g., MySQL, PostgreSQL master-slave replication), default replication mode for many NoSQL databases (e.g., MongoDB, HBase).

Step 3: Multi-Master Replication

To address the single-point write bottleneck of master-slave replication, especially in scenarios requiring deployment across multiple data centers, Multi-Master Replication is proposed.

1. Role Definition:

   • Master Nodes: There are multiple master nodes, each capable of independently receiving write requests. Typically, one master node is deployed per data center.
   • Clients can send write requests to any master node.

2. Workflow:

   • Write Operation (Local):
     1. The client sends a write request to the nearest master node (e.g., an Asian user writes to the master node in the Asian data center).
     2. That master node executes the write operation locally.
   • Write Operation (Synchronization):
     3. After processing a local write, each master node asynchronously synchronizes the change to all other master nodes.
     4. Other master nodes apply these changes locally upon receipt.

3. Advantages:

   • Higher Write Availability: Even if one master node fails, others can still handle write requests.
   • Lower Write Latency: Allows users to write to the nearest data center, avoiding cross-region network delays.
   • Enhanced Write Scalability: Theoretically, multiple master nodes can share the write load.

4. Disadvantages:

   • Data Conflicts: This is the most complex issue in multi-master replication. If two clients simultaneously modify the same piece of data on different master nodes, a write conflict occurs. For example, User A sets inventory X to 10 on the Asian master, while User B almost simultaneously sets inventory X to 5 on the American master. These operations need coordination.
   • Complex Conflict Resolution: The system requires additional mechanisms to resolve conflicts. Common methods include:
     • Last Write Wins: Assign a timestamp (e.g., physical or logical clock) to each write and keep only the write with the latest timestamp. This method is simple but may cause data loss.
     • Custom Conflict Resolution Logic: Write code at the application layer to merge conflicts based on business rules (e.g., performing a union operation on shopping cart items).
   • Weaker Consistency: Due to asynchronous synchronization and conflict resolution delays, the system typically only provides eventual consistency.

5. Application Scenarios: Applications requiring cross-region deployment with high demands for write availability and low latency, such as collaborative editing tools (Google Docs) and multi-active data center deployments.

Summary and Comparison

The choice of replication strategy depends on the trade-off your business makes among consistency, availability, latency tolerance, and system complexity.