Redis vs Memcached: Architecture, Data Types, and Real-World Use Cases

1. MySQL + Memcached Architecture Issues

Memcached follows a client‑server model with a custom protocol; any language can implement the client library. The server uses a slab‑based memory allocator to reduce fragmentation and allocation overhead. Each slab is divided into pages (default 1 MiB) and further into chunks for storing key‑value pairs. This slab mechanism acts like a memory pool managed by Memcached itself.

When scaling MySQL with Memcached, several problems arise:

Continuous sharding of MySQL tables and corresponding Memcached expansion consumes significant development time.

Data consistency between MySQL and Memcached.

Low cache hit rates or cache node failures cause traffic to fall back to the database, overwhelming MySQL.

Cross‑datacenter cache synchronization.

2. Choosing Between Memcached and Redis

Both are in‑memory key‑value stores, but they differ in features and suitable scenarios.

Performance: Memcached can utilize multiple CPU cores, giving higher throughput for large values (>100 KB). Redis, single‑threaded, excels with small values and offers richer data structures.

Memory Efficiency: Simple key‑value storage favors Memcached; Redis’s hash, list, set, and sorted‑set structures can be more memory‑efficient for complex data.

Persistence: Redis provides snapshotting and AOF logging; Memcached does not.

Data Structures: Redis supports strings, hashes, lists, sets, sorted sets, pub/sub, transactions, etc., reducing the need for client‑side manipulation.

Network I/O Model: Memcached uses a multithreaded model with locks; Redis uses a single‑threaded event‑driven model, offering lower latency for most operations.

Consistency Guarantees: Memcached offers CAS for optimistic concurrency; Redis provides atomic transactions and WATCH for optimistic locking.

3. Redis Common Data Types

Redis stores all keys and values as redisObject structures, which contain a type (identifying the data type) and an encoding (the internal representation).

The most frequently used data types are:

String

Hash

List

Set

Sorted Set

Pub/Sub

Transactions

3.1 String

Simple key‑value pairs; values can be plain strings or integers. Commands: SET , GET , INCR , DECR , MGET etc. Use cases: basic caching, counters, bit‑level operations, range updates. Implementation: stored as a raw string or an integer encoding when the value fits in a 64‑bit signed integer.

3.2 Hash

Maps field‑value pairs under a single key, ideal for representing objects (e.g., user profiles). Commands: HGET , HSET , HGETALL etc. Advantages over storing a serialized object in Memcached: individual fields can be updated without full serialization, reducing overhead and concurrency issues. Implementation: small hashes use a compact ziplist (encoding zipmap ); larger hashes automatically convert to a real hash table (encoding ht ).

3.3 List

Doubly‑linked list supporting push/pop from both ends. Commands: LPUSH , RPUSH , LPOP , RPOP , LRANGE etc. Use cases: timelines, message queues, recent‑items feeds. Implementation: stored as a linked list of nodes, enabling O(1) insertions/removals at ends.

3.4 Set

Unordered collection of unique strings. Commands: SADD , SREM , SMEMBERS , SINTER , SUNION etc. Use cases: deduplication, membership tests, social‑graph relationships. Implementation: a hash table with null values, providing O(1) existence checks.

3.5 Sorted Set

Set of unique members each associated with a floating‑point score, kept ordered via a skip‑list. Commands: ZADD , ZRANGE , ZREVRANGE , ZCARD etc. Use cases: leaderboards, time‑based ranking, priority queues. Implementation: a hash map for member‑to‑score lookup plus a skip‑list for ordered traversal.

3.6 Pub/Sub

Publish/subscribe messaging model. Clients subscribe to channels; publishers send messages that are delivered to all subscribers. Useful for real‑time chat, notifications, and event broadcasting.

3.7 Transactions

Redis supports command batching with MULTI / EXEC . While not fully ACID, it guarantees atomic execution of a sequence of commands unless the server crashes. WATCH provides optimistic locking.

4. Real‑World Redis Use Cases

4.1 Displaying Latest Items

Maintain a list of recent IDs with LPUSH and trim it to a fixed size using LTRIM. Retrieve a range with LRANGE. Fallback to the database only when the requested range exceeds the cached window.

LPUSH latest.comments <ID>
LTRIM latest.comments 0 5000

4.2 Deletion and Filtering

Remove items with LREM or simply skip over deleted entries during read.

4.3 Leaderboards

Use a sorted set where the score is the user’s points. Retrieve top N with ZREVRANGE and a user’s rank with ZRANK.

ZADD leaderboard <score> <username>
ZREVRANGE leaderboard 0 99
ZRANK leaderboard <username>

4.4 Time‑Weighted Ranking (e.g., Reddit/Hacker News)

Periodically recompute a score like score = points / time^α and update a sorted set.

4.5 Expiration Handling

Store items with a Unix timestamp as the score; periodically prune expired entries with ZREMRANGEBYSCORE.

4.6 Counting

Atomic counters via INCR / INCRBY, optionally setting an expiration with EXPIRE.

INCR user:<id>
EXPIRE user:<id> 60

4.7 Unique Visitors per Time Window

Record a user’s visit in a set keyed by day: SADD page:day1:<page_id> <user_id>. Query cardinality with SCARD and membership with SISMEMBER.

4.8 Real‑Time Analytics & Spam Filtering

Combine various Redis primitives (counters, sets, sorted sets) to build lightweight analytics pipelines and anti‑spam mechanisms.

4.9 Pub/Sub Messaging

Simple, fast publish/subscribe with pattern matching for real‑time notifications.

4.10 Queues

Implement reliable queues using list push/pop; block on empty lists with BLPOP / BRPOP for consumer workers.

5. Summary

Redis offers a rich set of data structures, persistence options, and atomic operations that make it suitable for caching, ranking, real‑time analytics, messaging, and more, often providing a more feature‑complete alternative to Memcached. Understanding each data type’s internal representation helps developers choose the most memory‑efficient and performant solution for their specific use case.