Chapter 8: System Design - Distributed Caching & Redis Internals

1. Concept Introduction

The Memory-Storage Latency Gap

DRAM operates at nanosecond speed ($50\text{–}100\text{ ns}$), whereas reading NVMe SSDs requires microseconds ($10,000\text{ ns}$), and querying a relational database across a network requires milliseconds ($10,000,000\text{ ns}$). Distributed Caching offloads read queries to serve state with sub-millisecond response.

+-------------------------------------------------------------------------+
|                  REDIS I/O MULTIPLEXING EVENT LOOP                      |
+-------------------------------------------------------------------------+
| APPLICATION CLIENTS (Thousands of Concurrent Socket Connections)         |
|  [ Client 1 ]       [ Client 2 ]       [ Client 3 ]       [ Client N ]  |
+-------------------------------------------------------------------------+
                                     │
                                     ▼ Non-Blocking Socket Connections
+-------------------------------------------------------------------------+
| OS KERNEL I/O MULTIPLEXER (epoll / kqueue / evport)                     |
+-------------------------------------------------------------------------+
                                     │
                                     ▼ Dispatches Event Batch
+-------------------------------------------------------------------------+
| REDIS AE EVENT LOOP (aeProcessEvents)                                   |
|  1. Read Query Buffer  2. Execute In-Memory Command  3. Append Payload  |
+-------------------------------------------------------------------------+

2. Theory & Low-Level Internals

A. Simple Dynamic Strings (SDS) & Incremental Rehashing

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len;        // Used byte length (O(1) strlen lookup)
    uint8_t alloc;      // Total allocated capacity
    unsigned char flags;// SDS header type
    char buf[];         // Raw byte array (Binary Safe)
};

B. Approximated LRU vs True LRU

Instead of maintaining a 16-byte linked list per entry, Redis uses Approximated LRU. It randomly samples $N$ keys (default: 5) and evicts the candidate with the oldest 24-bit `lru` timestamp.

C. Redis Cluster Hash Slot Sharding

Slot = CRC16(key) % 16384

Node A (Slots 0 - 5460)  |  Node B (Slots 5461 - 10922)  |  Node C (Slots 10923 - 16383)

3. Real Production Architecture Example

Mission-critical financial application handling 500,000 QPS using a two-tier caching topology: L1 Local Caffeine RAM Cache paired with L2 Distributed Redis Cluster.

4. Code Examples

A. Production Pattern: Atomic Distributed Locking with Fencing Tokens

public class ProductionRedisEngine {
    private final Jedis jedis;
    private static final String UNLOCK_LUA_SCRIPT =
        "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

    public String acquireDistributedLock(String lockKey, long ttlMillis) {
        String fencingToken = UUID.randomUUID().toString();
        SetParams params = SetParams.setParams().nx().px(ttlMillis);
        return "OK".equals(jedis.set(lockKey, fencingToken, params)) ? fencingToken : null;
    }

    public boolean releaseDistributedLock(String lockKey, String fencingToken) {
        return Long.valueOf(1).equals(jedis.eval(UNLOCK_LUA_SCRIPT, Collections.singletonList(lockKey), Collections.singletonList(fencingToken)));
    }
}

5. Tiered Interview Questions

6. Production Debugging Scenario