Choosing Between Memcached and Redis: Architecture, Performance, and Real-World Use Cases

1. MySQL + Memcached Architecture Issues

Memcached uses a client‑server model with a custom protocol; any language can implement the client library. The server manages memory with a slab allocator, allocating 1 MiB pages that are divided into chunks of different slab classes for storing key‑value pairs, reducing fragmentation and allocation overhead.

In practice, many companies combine MySQL for massive data storage with Memcached for hot‑data caching. As data volume and traffic grow, several problems arise:

MySQL requires continuous sharding and table splitting, and Memcached must be expanded in lockstep, consuming significant developer time.

Data consistency between MySQL and Memcached.

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

Cross‑datacenter cache synchronization challenges.

Choosing the right NoSQL solution depends on the workload: in‑memory key‑value stores like Redis excel at low‑latency reads, while other NoSQL products address different trade‑offs.

2. Redis Common Data Types

String

Hash

List

Set

Sorted Set

Pub/Sub

Transactions

Redis represents every key/value with a redisObject that stores the type and encoding. For example, a string may be stored as raw bytes or as an integer if it can be parsed as a number.

3. Data‑Type Applications and Implementation

String

Simple key‑value pairs; supports numeric operations (INCR/DECR) and advanced commands such as GETRANGE, APPEND, BITCOUNT, etc. Implementation: Stored as a plain string; when numeric commands are used, the encoding switches to int .

Hash

Ideal for storing objects with multiple fields (e.g., user profile). Allows field‑level updates without serializing the whole object. Implementation: Small hashes use a compact zipmap encoding; larger hashes automatically convert to a real hash table.

List

Implemented as a doubly linked list; useful for timelines, message queues, and range queries. Implementation: Stored as a double‑ended linked list, enabling O(1) push/pop at both ends.

Set

Unordered collection of unique elements; supports membership tests, set operations (union, intersection, difference). Implementation: Internally a hash table with null values, providing O(1) existence checks.

Sorted Set

Set of unique elements ordered by a user‑provided score; used for leaderboards, time‑sorted feeds, and priority queues. Implementation: Combines a hash map (member → score) with a skip‑list for ordered traversal.

Pub/Sub

Publish/subscribe messaging model for real‑time notifications, chat, and event broadcasting.

Transactions

Provides atomic execution of a batch of commands (EXEC) and optimistic locking via WATCH, though not a full ACID guarantee.

4. Practical Redis Application Scenarios

1) Displaying the Latest Items

Use a Redis list to store recent IDs: LPUSH latest.comments <ID> Trim the list to a fixed size: LTRIM latest.comments 0 5000 Retrieve a range of IDs: LRANGE latest.comments start end If the requested range exceeds the trimmed size, fall back to a SQL query.

2) Deletion and Filtering

Remove items with LREM or skip missing entries; maintain separate lists for different filters.

3) Leaderboards

Store scores in a sorted set: ZADD leaderboard <score> <username> Get top 100: ZREVRANGE leaderboard 0 99 Get a user's rank:

ZRANK leaderboard <username>

4) Vote‑Based Ranking (Reddit/Hacker News style)

Score = points / time^α; update scores periodically and store in a sorted set.

5) Expiration of Items

Use timestamps as scores; periodically remove expired members with ZREMRANGEBYSCORE.

6) Counting

Atomic increments with INCRBY and optional expiration:

INCR user:<id> EXPIRE 60

7) Time‑Specific Tracking

Record unique visitors per day using sets: SADD page:day1:<page_id> <user_id> Query count with SCARD and membership with SISMEMBER.

8) Real‑Time Analytics & Spam Prevention

Combine Redis primitives to build fast analytics pipelines and simple spam filters.

9) Pub/Sub

Simple, stable, pattern‑matching publish/subscribe for real‑time messaging.

10) Queues

Lists provide push/pop semantics; blocking variants (e.g., BLPOP ) enable reliable queues.

11) Caching

Redis can replace Memcached, offering richer data structures, persistence, replication, and sharding.

Original source of the caching section: http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

5. Redis Experience from Industry Giants

Various large‑scale systems worldwide have adopted Redis for high‑performance caching, real‑time analytics, and data structures that simplify application logic.