How to Achieve Cross‑Data‑Center State Sync with Two‑Site Three‑Center Architecture

This article shares the theory and technology for cross‑data‑center state synchronization using a two‑site three‑center architecture, focusing on database aspects and explaining both the implementation steps and the underlying reasons.

Distributed Protocols/Concepts

Using Alibaba's Double‑11 example of 85,000 transactions per second, the article highlights that only Paxos and Raft provide true distributed consistency, with Raft being easier to implement for state‑synchronization protocols.

Long‑Distance Cross‑Datacenter Sync Issues

Tuniu initially operated from Nanjing but moved services to Beijing to improve user experience, encountering problems such as high latency, difficulty achieving strong consistency and high availability, and risk of data loss during failover.

CAP Choice

For e‑commerce, the article argues that consistency is prioritized over availability and partition tolerance, emphasizing the challenges of satisfying all three CAP properties simultaneously.

Implementation with Open‑Source Databases

Master‑slave replication for high availability.

Prevent data loss.

Accept limited performance loss while waiting for data synchronization.

Due to excessive latency over long distances, the company decided to relocate its Beijing datacenter back to Nanjing, consolidating major systems.

Data Transmission

Data is transmitted via fiber optics; theoretical calculations show that light travels at roughly 200,000 km/s in fiber, resulting in latency of about 0.1 ms per 20 km, with practical throughput between Nanjing and Beijing around 20 TPS under current conditions.

HA Data‑Center System Construction

Earlier member‑system issues were mitigated by adopting asynchronous processing and high‑availability components such as heartbeat and keepalived, while adding a third arbitration node to avoid split‑brain scenarios.

Three‑center HA combines a same‑city center for high throughput, a remote center for arbitration and disaster recovery, and a third distant center to protect against regional failures like earthquakes.

Through techniques like sharding, global transaction IDs, 2‑phase commit, and asynchronous queues, systems can achieve the 85,000 transactions per second peak demonstrated by Alibaba during Double‑11.

In summary, a two‑site three‑center design ensures high throughput and availability, with the third center providing arbitration and safety, while a CP (Consistency & Partition tolerance) approach may not meet performance goals.