Understanding Redis: Protocol, ACID Myths, Persistence, and Optimization

1. Redis Communication Protocol

Redis uses a simple text protocol called RESP (Redis Serialization Protocol). The server and client communicate via this protocol, which can be accessed with Telnet or any raw text stream.

The client command formats are:

Simple Strings: start with "+"

Errors: start with "-"

Integers: start with ":"

Bulk Strings: start with "$"

Arrays: start with "*" set hello abc A simple text stream can act as a Redis client.

2. Does Redis Have ACID Transactions?

Redis supports transactions, but they do not fully satisfy the traditional ACID properties.

Atomicity: Commands are queued after MULTI and executed atomically with EXEC, but Redis lacks rollback; a failed command within a transaction may have already modified data.

Consistency: Redis ensures consistency for individual operations, but without full ACID guarantees, especially when considering business‑level invariants.

Isolation: Because Redis is single‑threaded, transactions run serially, providing isolation.

Durability: Persistence depends on the chosen mode (RDB, AOF, or hybrid). See redis.io/topics/protocol for details.

3. Redis Optimistic Lock – WATCH

WATCH implements optimistic locking similar to CAS. It monitors one or more keys before a transaction starts; if any watched key changes before EXEC, the transaction is aborted.

Implementation details:

Each watched key is stored in a watched_keys dictionary with a list of client flags.

When a key is modified, all watching clients are marked CLIENT_DIRTY_CAS and the transaction is discarded.

4. Persistence Mechanisms

Redis offers two primary persistence mechanisms:

RDB (snapshot): Generates a point‑in‑time binary dump of the dataset. BGSAVE forks a child process to write the snapshot without blocking the main thread.

AOF (append‑only file): Logs every write command. On recovery, the log is replayed. AOF can grow large; BGREWRITEAOF rewrites it to a compact form.

Since Redis 4.0, a hybrid mode combines RDB snapshots with incremental AOF to reduce recovery time and storage.

5. Memory Efficiency Techniques

Redis uses several data structures to save memory:

Ziplist: A compact sequential list used for small hashes and sorted sets.

Quicklist: Introduced in 3.2, it combines multiple ziplist nodes into a doubly linked list, balancing memory use and operation speed.

Object Sharing: Identical string objects are shared via reference counting, reducing duplicate memory consumption.

6. Replication Architecture

Redis replication uses a master‑slave model. Since version 2.8, the PSYNC command replaces SYNC and supports both full and partial synchronization.

Full sync sends an RDB snapshot followed by a stream of write commands. Partial sync replays only the missing commands recorded in the replication backlog.

7. Expiration Deletion Strategies

Redis does not delete expired keys immediately. It employs three strategies:

Timed deletion: A timer removes the key exactly at expiration (CPU‑intensive).

Lazy deletion: Keys are removed only when accessed.

Periodic deletion: A background process scans and deletes a limited number of expired keys at intervals, balancing CPU load and memory usage.

8. Summary

Redis is a powerful in‑memory data store that prioritizes simplicity and performance. Its text‑based protocol, limited transaction model, optimistic locking, flexible persistence, memory‑saving structures, robust replication, and configurable expiration policies make it suitable for high‑throughput scenarios, though it does not aim to provide full ACID guarantees.