Redis vs Memcached vs Tair: Choosing the Right Distributed Cache for Production

Overview

Cache solutions have become mature, and this article selects three representative options—Redis, Memcached, and Alibaba's Tair—to compare them across nine major aspects, guiding practitioners in making better technology choices for production environments.

Comparison of Common Distributed Caches

Redis is widely used because of its rich and easy‑to‑use data structures. The following image summarizes the comparison (original table omitted for brevity):

1. Data Types

Redis supports five data types (String, List, Set, Sorted Set, Hash) built on structures such as compressed strings, dictionaries, and skip‑lists, which offer log₂N lookup speed and easier concurrent updates. Memcached only stores simple key‑value pairs without additional structures.

2. Thread Model

Redis runs a single‑threaded, non‑blocking I/O model (based on libevent/Epoll) that performs well for pure memory operations but can become a bottleneck for long‑running logic; multiple instances per machine are recommended (e.g., eight instances on one server). Memcached uses a multithreaded non‑blocking I/O model, which handles varied workloads without blocking other requests.

3. Persistence

Redis offers two persistence mechanisms: RDB (periodic snapshots) and AOF (append‑only file). Memcached is designed as a pure cache and does not provide built‑in persistence, though third‑party tools like MemcacheDB can add it.

4. Clients

Common Redis Java client Jedis uses blocking I/O with connection pooling and supports consistent hashing sharding; other options include the open‑source Redic. Memcached Java clients (e.g., Memcache Java Client, Spy Client, XMemcache) vary between blocking and non‑blocking I/O.

5. High Availability

Redis supports master‑slave replication, Sentinel, and Cluster (from version 3.0) for high availability. Memcached lacks native HA; third‑party proxies like Megagent can provide failover.

6. Queue Support

Redis natively supports list‑based queues (LPUSH/BRPOP) and publish/subscribe patterns. Memcached does not support queues directly; third‑party MemcachQ can be used.

7. Transactions

Redis provides commands such as MULTI/EXEC, WATCH, and INCR that are atomic per connection, though cross‑client atomicity is not guaranteed. Memcached commands are thread‑safe individually, and it offers INCR and GETS/CAS for simple transactional behavior.

8. Eviction Policies

Redis offers a rich set of eviction policies (e.g., maxmemory‑policy, volatile‑LRU, allkeys‑LRU, noeviction). Memcached relies on an LRU algorithm and can disable it with the “M” parameter when necessary.

9. Memory Allocation

Redis abstracts platform‑specific allocation via zmalloc / zfree (found in zmalloc.h/c), optionally using Google’s TC_MALLOC or the system allocator. Memcached uses a slab allocator that categorizes memory into size classes to reduce fragmentation.

Redis Primer

Redis is an open‑source, ANSI‑C key‑value store that can act as an in‑memory database or a log‑based persistent store, offering APIs for many languages.

1. Use Cases

Commonly used as a non‑persistent cache; storing complex JSON objects as plain strings can cause large network traffic and latency. The recommended approach is to store object fields in a Redis hash.

public class Commodity {
    private long price;
    private String title;
    // ...
}

Hash commands example:

HSET commodity:123 price 100
HSET commodity:124 price 101
HSET commodity:12345 price 101
HSET commodity:123 title banana
HSET commodity:124 title apple
HSET commodity:12345 title orange

Retrieving a single field:

HGET commodity:12345 title

2. High‑Availability with Sentinel

Sentinel monitors nodes, elects a master, and performs automatic failover using a Raft‑style election. A typical deployment uses at least three Sentinel instances (quorum = 2). The diagram below shows a three‑node Sentinel setup.

When the master becomes unreachable, two Sentinels trigger a failover and promote a slave to master. After network recovery, the former master becomes a slave, and any writes performed during isolation are lost because Redis replication is asynchronous.

3. Preventing Data Loss

Configure each Redis instance with:

min-slaves-to-write 1
min-slaves-max-lag 10

These settings make the master reject writes if it cannot confirm that at least one slave has successfully received data, reducing the risk of lost writes during partitions.

4. Redis Cluster

Redis 3.0 introduced clustering to handle large data volumes and improve availability. Data is sharded using CRC16(key) mod 16384, distributing slots across nodes. Example slot allocation:

A node: slots 0‑5500

B node: slots 5500‑11000

C node: slots 11000‑16384

Cluster topology diagram:

Clients can connect to any node; the cluster routes requests to the appropriate node based on the hash slot. Internally, each node stores its slot map, enabling automatic redirection without client‑side logic.