Understanding Redis Data Structures, Persistence, Transactions, and Replication

Redis Data Structures

Redis commonly uses five data types:

String

Hash

List

Set

Sorted set

All keys and values are represented internally by a redisObject structure.

String values are stored as raw strings; when arithmetic operations like INCR or DECR are performed, the object’s encoding changes to an integer.

Lists are implemented as doubly linked lists, enabling efficient forward and backward traversal but incurring some memory overhead.

Hashes are backed by a hash map. For small numbers of fields Redis uses a compact zipmap representation (encoding zipmap); when the field count grows it automatically converts to a real hash table (encoding ht).

Redis Persistence

Redis offers two persistence options:

RDB : snapshots the dataset at specified intervals.

AOF : appends every write command to a log, replaying it on restart.

RDB advantages: compact single‑file representation and easy backup.

RDB disadvantages: snapshots are not fully durable (data may be lost on crash) and the fork operation can block the server for seconds on large datasets.

When Redis dumps data to disk it forks a child process that writes the dataset to a temporary RDB file, then replaces the old file.

AOF advantages: append‑only log survives power loss.

AOF disadvantages: larger files than RDB and potentially slower depending on fsync policy.

Redis can sync to disk in three ways:

Sync on every write (very safe but slow).

Sync every second (fast, may lose up to one second of data).

Never sync (fast, unsafe).

During AOF rewrite Redis forks a child that writes a new AOF file while the parent continues to buffer incoming writes; once the child finishes, the parent appends the buffered data and replaces the old file.

Redis Transactions

Redis provides a transaction model that differs from traditional ACID databases. All Redis commands are atomic, but Redis does not support rollback.

Atomicity : every API call is atomic.

Redis sacrifices rollback because failures are limited to syntax errors or type mismatches, which are caught during development.

Consistency : without rollback, Redis cannot guarantee data consistency after a failed transaction.

Isolation : single‑threaded execution ensures that a transaction’s intermediate state is not visible to other clients.

Durability : Redis primarily operates in memory; durability is provided only by RDB or AOF. RDB is asynchronous and does not guarantee transaction durability, while AOF writes each command to disk, impacting performance.

Redis Master‑Slave Replication

Redis supports one‑master‑multiple‑slave or cascaded replication.

Full Synchronization occurs when a slave first connects:

Slave sends SYNC to master.

Master runs BGSAVE to create an RDB snapshot and buffers subsequent writes.

Master sends the snapshot to the slave while continuing to buffer writes.

Slave loads the snapshot, discarding old data.

Master streams the buffered writes to the slave.

Slave applies the buffered writes and resumes normal operation.

Incremental Synchronization replicates each write command from master to slave after the initial sync.

Redis Use Cases

Common NoSQL solutions fall into four categories:

Key‑Value stores (e.g., Redis) for flexible data structures.

Document databases (e.g., MongoDB) to avoid rigid schemas.

Column‑family databases (e.g., HBase) for large‑scale I/O workloads.

Search engines (e.g., Elasticsearch) for full‑text search.

Key caching design considerations:

Cache penetration : queries miss the cache because the underlying data does not exist or cache generation is costly.

Cache avalanche : massive cache expiration leads to sudden load spikes.

Hot key mitigation : replicate cache across multiple nodes to distribute load.

Read‑write separation & multi‑level cache strategy.

Homepage split loading pattern.