Master‑Slave Read‑Write Splitting: Principles, Challenges, and Implementation Strategies

Read‑write separation principle is to distribute database read and write operations across different nodes.

Basic implementation:

Set up master‑slave cluster.

Master handles writes, slave handles reads.

Master replicates data to slaves, each DB stores all business data.

Application servers send writes to master and reads to slave.

"Master‑Slave" vs "Master‑Backup": In "master‑slave", the slave serves read requests. In "master‑backup", the backup only provides redundancy, not access.

Read‑write separation introduces two problems:

How to handle replication lag?

How to handle routing mechanism?

Replication Lag

Master‑slave replication delay can be hundreds of milliseconds to several seconds, causing issues such as a user registering and immediately logging in but reading stale data from the slave.

Common Solutions

1. Send read after write to master.

For example, after registration, the login read goes to master.

This tightly couples business logic and can easily introduce bugs.

2. If reading from slave fails, retry on master ("second read").

This decouples from business code but increases master load if many second reads occur.

3. Critical read/write operations go to master; non‑critical operations use read‑write splitting.

For instance, user management (registration, login) uses master, while profile reads can tolerate stale data.

Routing Mechanism

Two approaches:

Code encapsulation

Middleware

1. Code Encapsulation

Abstract a data access layer in code to implement read‑write separation and connection management.

Characteristics:

Simple to implement, customizable per business.

Each programming language needs its own implementation; not universal.

On failure, switching master/slave may require config changes and restart.

Open‑source example: Taobao's TDDL (Taobao Distributed Data Layer) built on JDBC datasource, offering master‑backup, read‑write splitting, dynamic DB config.

2. Middleware

Middleware is an independent system providing an SQL‑compatible protocol, so applications access it like a regular DB server.

Characteristics:

Supports multiple languages via standard SQL interface.

Requires full SQL syntax and DB protocol support; complex to implement.

All DB requests pass through middleware, demanding high performance.

Middleware can detect master‑slave status, making failover transparent to applications.

Open‑source middleware examples: MySQL Router (official), Qihoo 360's Atlas (based on MySQL Proxy), MariaDB MaxScale.

Content compiled from "Learning Architecture from Scratch".