Understanding Redis: Purpose, Usage, Caching Benefits, Differences with Memcached, and Thread Model

1. What is Redis? Redis is an open‑source, in‑memory data‑structure store that can serve as a database, cache, and message broker. It supports strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatial indexes, and streams, and provides replication, Lua scripting, LRU eviction, transactions, persistence, high availability via Sentinel, and automatic sharding with Redis Cluster.

In practice, Redis is mainly used to cache data, reducing the load on underlying databases and improving concurrency and response speed.

2. How to use Redis in a project? Instead of querying the database for every request, the result of the first query (e.g., order details) is stored in Redis. Subsequent requests retrieve the data directly from the cache, lowering database pressure and shortening response times.

3. Why use a cache? Caching provides (1) high performance – expensive SQL queries are executed once and their results are reused, and (2) high concurrency – during traffic spikes, cached data can be served without overwhelming the database, preventing crashes and supporting many simultaneous users.

4. Common cache problems include cache‑database write inconsistency, cache avalanche, cache penetration, and cache concurrency contention.

5. Differences between Memcached and Redis

Redis supports server‑side data operations and a rich set of data structures, allowing complex manipulations without round‑tripping data to the client. Memcached offers simple key‑value storage with higher memory efficiency for such use cases. Performance varies: Redis excels with small values on a single core, while Memcached can be faster for large values using multiple cores. Redis also provides native clustering, whereas Memcached requires client‑side sharding.

Comparison Point

Memcached

Redis

Server‑side operations

No

Yes

Data structure types

Simple

Complex & diverse

Memory utilization

High for simple key‑value

High with hash structures

Performance

Better for large data

Better for small data

Cluster mode

Not native

Native cluster support

6. Redis thread model

Redis uses a reactor‑based file‑event handler that runs in a single thread. It relies on I/O multiplexing (e.g., epoll) to monitor many sockets simultaneously. When a socket becomes readable or writable, the corresponding AE_READABLE or AE_WRITABLE event is generated and dispatched to the appropriate handler (connection accept, command request, or command reply).

The file‑event handler consists of sockets, the I/O multiplexing program, an event dispatcher, and various handlers (command request, reply, connection acknowledgment, etc.). Events are processed sequentially from a queue, ensuring a simple yet high‑performance networking model.

The client‑server interaction proceeds as follows: during startup, the connection‑accept handler is bound to AE_READABLE. When a client connects, an AE_READABLE event triggers the accept handler, which creates a socket and binds AE_READABLE to the command‑request handler. Subsequent client requests generate AE_READABLE events processed by the request handler, which reads data, executes commands, and prepares responses. When the response is ready, AE_WRITABLE is bound to the reply handler, which writes the data back to the client and then removes the AE_WRITABLE association.

7. Why can single‑threaded Redis handle high concurrency?

Because all operations are in‑memory, it avoids disk I/O; it uses non‑blocking I/O multiplexing to manage many connections efficiently; and a single thread eliminates context‑switch overhead, allowing Redis to serve a large number of concurrent requests with low latency.