Understanding Redis: Use Cases, Data Types, and Comparison with Memcached

Redis is a fast, efficient key‑value store widely used for caching, distributed locks, counters, real‑time message queues, data persistence, publish/subscribe, and geolocation queries.

Problems with MySQL+Memcached architecture : scaling MySQL tables and Memcached instances together, maintaining consistency, low cache hit rates, cross‑datacenter synchronization, and high maintenance overhead.

Choosing the right NoSQL product depends on workload characteristics; Redis excels in in‑memory workloads, offering richer data structures and persistence compared to Memcached.

Memcached vs. Redis comparison :

Performance: both are fast; Memcached can use multiple cores, Redis uses a single core but is faster for small values; for large values Memcached may be faster.

Memory efficiency: Memcached has higher raw key/value memory utilization, while Redis can achieve higher efficiency with hash structures.

Persistence: Redis provides snapshotting and AOF, which Memcached lacks.

Data structures: Redis supports strings, hashes, lists, sets, sorted sets, pub/sub, transactions, etc., whereas Memcached only stores opaque blobs.

Network I/O model: Memcached is multithreaded with locks; Redis uses single‑threaded event‑driven I/O.

Memory management: Memcached pre‑allocates slabs, potentially wasting space; Redis allocates on demand.

Consistency: Memcached offers CAS; Redis offers atomic transactions.

Redis data types :

String – basic key/value, supports numeric operations and bit manipulation.

Hash – field/value map ideal for storing objects without full serialization.

List – doubly linked list useful for queues, timelines, and recent‑item feeds.

Set – unordered collection of unique elements, supports membership tests and set operations.

Sorted Set – ordered set using a score, perfect for leaderboards and time‑based ranking.

Pub/Sub – publish/subscribe messaging for real‑time notifications.

Transactions – atomic execution of multiple commands with optional WATCH for optimistic locking.

Internally Redis represents each key with a redisObject that stores the type and encoding (e.g., raw, int, zipmap, ht, skiplist).

Practical use cases :

Displaying the latest items: use LPUSH to add IDs to a list and LTRIM to keep the list bounded.

Deleting or filtering items: LREM can remove entries.

Leaderboards: ZADD to add scores, ZREVRANGE for top N, ZRANK for a user’s rank.

Time‑based sorting: use timestamps as scores in a sorted set.

Counters: atomic INCR with optional EXPIRE for rate‑limited metrics.

Tracking unique visitors per day: SADD per day key, SCARD to count, SISMEMBER to test.

Real‑time analytics and spam detection by combining commands.

Redis also serves as a reliable message queue (list push/pop with blocking BLPOP ) and a flexible cache that can replace Memcached while offering richer operations.

Overall, Redis’s combination of in‑memory speed, diverse data structures, persistence options, and simple single‑threaded architecture makes it a powerful tool for a wide range of backend scenarios.