Why Redis Beats MySQL for Distributed Caching: Deployment and HA Strategies

Requirements

The storage layer must provide high availability and persistence, support automatic expiration (TTL) for easy cleanup, and expose common data structures such as sets, sorted sets, hashes, and lists. It should also allow atomic multi‑key operations (transactions) and have mature client libraries for Python and Go.

Technology Evaluation

Internal Tair, open‑source Redis, Memcached, LevelDB, and MongoDB were compared against the requirements. Redis 3.2 satisfied all criteria most comprehensively, offering in‑memory speed, rich data types, persistence options, replication, and HA components.

Typical Non‑Persistent Deployment (Cache Cluster)

In a pure‑cache scenario data loss is acceptable. Each Redis instance runs independently; clients perform consistent‑hash distribution of keys across the instance list. The architecture can be simplified by inserting a proxy (e.g., Twemproxy) that performs the hashing, allowing applications to connect to a single endpoint.

Persistence Options

RDB (snapshot) : Periodic full‑dataset dumps. Fast backup and recovery but may lose up to several minutes of writes because snapshots are taken at a low frequency.

AOF (append‑only file) : Logs every write operation. Typically flushed every second, limiting potential data loss to one second.

Both mechanisms can be enabled simultaneously, combining rapid recovery (RDB) with minimal data loss (AOF). The community is also experimenting with hybrid approaches that approach PostgreSQL‑level durability.

Master‑Slave Replication

Redis uses asynchronous 1:N replication. The master streams write commands to slaves, which may lag behind. Administrators can configure a maximum replication delay to meet business‑specific consistency requirements.

High Availability with Sentinel

Sentinel provides two essential services:

Continuous monitoring of master and slave instances; upon master failure, the Sentinel quorum votes to promote a slave to master (automatic failover).

Service discovery: clients query Sentinel to obtain the current master address, eliminating hard‑coded endpoint configurations.

Redis Cluster Deployment

Redis Cluster partitions the keyspace into 16,384 hash slots. The client computes CRC16(key) % 16384 to obtain a slot number, then routes the command to the node that owns that slot. Slot ownership is evenly distributed among cluster nodes.

Key operational considerations:

Adding a new node requires manual re‑allocation of hash slots and data migration (resharding).

Clients must be cluster‑aware; standard Redis clients cannot communicate with a cluster.

Transactions are only possible when all keys involved reside in the same slot (i.e., on the same node).

Multi‑key operations across different slots (e.g., set intersections) are not supported.

Chosen Deployment Architecture

Because a single machine’s capacity met the workload and the transaction/multi‑key limitations of Redis Cluster were undesirable, the following non‑cluster architecture was adopted:

One master Redis instance with two slave replicas for asynchronous replication.

A three‑node Sentinel cluster to provide automatic failover and high availability.

Sentinel processes run on the same three backend machines that host the API services, ensuring that Sentinel reflects the true availability of the API‑to‑Redis path.

Operational scripts configure both Redis servers (enabling RDB and AOF) and Sentinel instances, completing the service setup.