How Memcached and Redis Work: Architecture, Protocols, and Memory Management

Introduction

Memcached and Redis are two of the most widely used distributed caching systems. Analyzing their source code helps understand C program reading techniques and open‑source software analysis methods.

Analysis Framework

The speaker typically examines such server software in three steps:

Server model

Request protocol

Memory management mechanism

1. Server Model

Both Memcached and Redis adopt an event‑driven model on Linux, wrapping epoll. Memcached uses the libevent library, while Redis implements its own epoll wrapper for performance.

Memcached employs a thread‑pool model: a select thread communicates with worker processes via a pipe. Redis, by contrast, splits its workflow into multiple stages handled asynchronously by a single thread, maximizing CPU utilization.

2. Request Protocol

Both systems implement simple text‑based protocols. Memcached’s request format is:

<command name> <key> <flags> <exptime> <bytes>

Redis supports two text protocols: an inline single‑line format and a multibulk format. A multibulk SET command looks like: *3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n Memcached also offers a binary protocol.

3. Memory Management Mechanism

Memcached uses a slab allocator with pre‑allocation, enabling memory reuse and reducing fragmentation, though it can waste space.

Redis’s memory handling is more complex because it stores data structures (lists, maps, sets, etc.). It typically relies on the standard malloc / free pair, which may cause fragmentation. Many deployments replace the default allocator with jemalloc or tcmalloc to improve fragmentation rates; tests show tcmalloc achieving ~1.01% fragmentation, jemalloc ~1.02%, and the libc allocator ~1.31%.

The above diagram illustrates Memcached’s slab‑based memory management.

Server model diagrams for both Memcached and Redis are shown in the following images.

Practical Considerations

When choosing between Memcached and Redis, many scenarios only need to prevent database overload; Memcached is often sufficient, and client‑side hashing can handle sharding.

Clients such as spymemcached provide connection pooling and serialization, reducing developer effort.

For use cases requiring persistence or complex in‑memory calculations, Redis is preferable, but it introduces HA and sharding concerns. A single Redis instance can comfortably handle tens of thousands of TPS; for higher loads, a master/slave setup with read‑write separation is usually enough, while the official Redis Cluster is not recommended for short‑term projects.

Redis can also be extended for specialized tasks, such as geohash implementations used by companies like Uber or Didi. While MongoDB offers geospatial indexing, its polygon‑based algorithms are more complex and less performant for high‑throughput scenarios.

Custom Redis‑based geohash solutions have demonstrated support for 7‑8k TPS on a single node.

Conclusion

Both Memcached and Redis provide robust caching capabilities, each with distinct architectural choices. Understanding their server models, protocols, and memory management strategies enables informed decisions on deployment, tuning, and when to extend or replace default components.