How Redis Achieves High Availability: A Story of Replication and Failover

I am Redis , created by a man named Antirez .

In our daily work, the three of us mainly cooperate on data synchronization.

When the master node receives write, delete, or modify commands, it notifies each slave node one by one – this is called command propagation .

Through this method, the master and slave nodes keep their data in sync.

Once I accidentally got disconnected.

We adopted a new data‑sync strategy that greatly improved efficiency, allowing us to quickly recover any missing data even after occasional disconnections.

Later we added more manpower and prepared for a big push.

To promptly obtain and update master‑slave information, Sentinel queries the master with the INFO command every ten seconds; the master replies with its list of slaves.

To detect whether any node is down, Sentinel sends a PING command to each peer every second.

If no reply is received within the configured time, we assume the node has failed and initiate a failover, after confirming with the admin group.

We then started the first election.

After some effort, the failover completed and R2 became the new master.

Shortly after, R1 returned.

Thus, through our teamwork, we built a high‑availability cache service that even MySQL can no longer underestimate.