Multi-Active Deployment Modes, Routing Rules, and Unitization in Data Center Architecture

Basic Concepts

Central data center: the single‑site data center used for all services that are not dual‑active. Unit data center: a newly built data center that provides the second active site for dual‑active traffic.

Routing

The sharding_id (also called route_code ) is converted by the dual‑active routing engine into a four‑wheel (四轮) regional code. Each route_code maps to either the central or the unit data center, and components such as gateway, SOA, Redis, and DB route requests based on this code.

Several Dual‑Active Modes

Same‑city dual‑active: two IDC locations within the same city.

Cross‑city dual‑active: two IDC locations in different cities.

Cross‑city multi‑active: multiple IDC locations spread across several cities.

Advantages and Disadvantages

Same‑city dual‑active – advantage: short physical distance, low data‑sync and RPC latency; disadvantage: insufficient disaster‑recovery when the whole city loses power.

Cross‑city dual‑active – advantage: better disaster‑recovery for city‑level failures; disadvantage: longer distance leads to higher data‑sync latency and RPC delay.

Cross‑city multi‑active – advantage: further improved disaster‑recovery; disadvantage: more complex data‑sync, consistency checks, and increased link latency.

Unitization

When a business reaches tens or hundreds of thousands of TPS, the bottleneck shifts to data‑center capacity. Unitization treats each IDC as an independent unit, allowing theoretically unlimited horizontal scaling. Traffic is split at the entry point to different IDC clusters, and no cross‑IDC calls occur.

Unitization succeeds when traffic can form a closed loop: e.g., a Shanghai IDC (A) and a far‑away overseas IDC (B) operate independently without affecting each other.

Traffic Routing Rules

1. Random routing – traffic is distributed proportionally to each IDC without any rule; useful for failover.

2. User‑ID routing – each user’s requests are consistently routed to a specific IDC; failover can switch the whole IDC’s traffic by user.

3. Region routing – traffic is routed based on the user’s city; failover can switch an IDC’s traffic by region.

Case Study: Haro Four‑Wheeled Ride

After discussion, Haro chose region routing. Random routing was rejected because it cannot achieve unitization. User‑ID routing would cause many cross‑IDC calls for driver‑passenger interactions, while region routing limits cross‑IDC traffic due to low probability of inter‑city rides. The drawback is traffic volatility during holidays or weather events, which may cause uneven load across IDC.

Dual‑Active Solution Overview

The middleware provides four main capabilities: storage, messaging, SOA, and Snowflake ID generation.

Storage

Provides bidirectional data synchronization, cross‑IDC Redis read/write and locking, temporary Redis double‑write, DB bias routing, and write‑protection for non‑local orders.

Messaging

Supports replication from unit to central and vice versa. Consumption can be limited to the local IDC, both IDC, or none, depending on the business need.

SOA

RPC requests are routed based on conditions defined by the service provider or consumer.

Snowflake Algorithm

Because Zookeeper clusters span two data centers, the Snowflake ID generator embeds a data‑center identifier to guarantee global uniqueness.

Business Refactoring

Most refactoring follows the middleware solution. Specific efforts include:

Unitization transformation for services that previously could not be unitized.

DB cache consistency via binlog messages to keep order data synchronized across IDC.

Data‑center filtering to handle or block non‑local logic when unitization is not yet possible.

Order‑number transformation to embed routing rules into the order ID, ensuring subsequent operations follow the correct IDC.

These measures collectively enable a scalable, highly available architecture that can grow horizontally across multiple data centers.