Common Redis Questions and Solutions: Usage, Performance, Data Types, Expiration, Consistency, and Concurrency

Many developers only use Redis for simple set and get operations, lacking a broader understanding of its capabilities; this article summarizes common Redis questions to fill those knowledge gaps.

Redis is primarily chosen for its performance and concurrency benefits, while features like distributed locks can be replaced by other middleware when not needed.

By caching the results of slow, infrequently changing SQL queries, applications can dramatically improve response times.

Redis achieves high speed despite being single‑threaded through three factors: pure in‑memory operations, avoidance of context switches, and a non‑blocking I/O multiplexing mechanism (select/epoll/kqueue).

The main data types are:

String : basic set/get, often used for simple counters.

Hash : stores structured objects, useful for session‑like data.

List : enables simple message queues and efficient pagination.

Set : stores unique values, useful for global de‑duplication and set operations.

Sorted Set : adds a score for ordering, ideal for leaderboards, delayed tasks, and range queries.

Redis handles key expiration with a combination of periodic and lazy deletion. Periodic deletion runs every 100 ms on a random subset of keys, while lazy deletion removes a key when it is accessed after its TTL has expired.

When memory is exhausted, Redis applies an eviction policy. Common policies include # maxmemory-policy volatile-lru, allkeys-lru, allkeys-random, volatile-lru, volatile-random, and volatile-ttl. The noeviction policy simply rejects new writes.

Cache‑database consistency can only guarantee eventual consistency; the recommended approach is to update the database first, then delete the cache, optionally using a message queue for compensation if cache deletion fails.

Cache penetration (requests for non‑existent keys) can be mitigated with mutex locks, asynchronous updates, or Bloom filters. Cache avalanche (massive simultaneous expiration) can be addressed by adding random jitter to TTLs, using mutex locks, or employing a double‑cache strategy.

Concurrent key competition is often solved with distributed locks when order is not required, or with timestamp‑based ordering when strict sequencing is needed. Redis transactions are generally unsuitable for clustered environments because keys may reside on different shards.

In summary, the article consolidates practical Redis knowledge—from basic usage to advanced topics like eviction policies, consistency, and concurrency—providing actionable guidance for developers.