Redis Dual-Active Architecture: Hot-Standby, Dual-Write, and Bidirectional Synchronization Comparison

This article provides a comprehensive analysis of Redis dual-active architecture schemes, comparing hot-standby, dual-write, and bidirectional synchronization approaches. The author systematically evaluates each method's advantages and disadvantages, with particular focus on bidirectional synchronization implementation.

The article begins by introducing three Redis dual-active schemes: hot-standby, dual-write, and bidirectional synchronization. Hot-standby is dismissed due to high maintenance costs and poor stability during failover. Dual-write is further divided into four variants: synchronous dual-write, asynchronous dual-write, cluster synchronous dual-write, and cluster asynchronous dual-write.

Synchronous dual-write suffers from high latency (30x increase compared to single write) and complex rollback handling. Asynchronous dual-write reduces latency but introduces data consistency issues. Cluster-level dual-write variants offer lower maintenance costs but inherit the same fundamental problems.

The bidirectional synchronization scheme emerges as the preferred solution, where Redis writes occur only locally while middleware handles cross-region synchronization. The article explains Redis replication mechanisms including offset tracking, backlog buffers, and runid identification. It details the evolution from sync to psync1 to psync2 protocols, addressing issues like breakpoint continuation and master failover.

The data synchronization process is explained through slot allocation logic in Redis Cluster, where keys are distributed across master nodes based on CRC16 modulo 16384. The middleware implementation involves slave node impersonation, where synchronization tasks connect to master nodes using standard replication protocols (AUTH, REPLCONF, PSYNC).

A critical challenge addressed is preventing circular replication in bidirectional setups. The solution employs fixed-prefix keys with hash tags to ensure slot consistency between original commands and anti-loop markers. The complete bidirectional synchronization architecture is illustrated with center-to-unit and unit-to-center replication flows.

The article concludes with practical insights on single-direction synchronization tasks, explaining why target nodes must be Redis clusters rather than individual masters due to slot distribution differences between data centers.