Master Redis Persistence, Transactions, and Pipelines: A Practical Guide

Redis Overview

Redis is an in‑memory key‑value store. Because data resides in RAM, persisting it to disk is essential to avoid loss when the server crashes.

1. RDB Persistence

RDB (Redis DataBase) creates point‑in‑time snapshots of the dataset at configured intervals and writes them to disk.

Automatic Trigger

In redis.conf the save <seconds> <changes> directive defines when a snapshot is taken, e.g., save 60 20 triggers a snapshot after 20 changes within 60 seconds.

Manual Trigger

Use save (blocks the server until the snapshot finishes) or bgsave (forks a child process and runs asynchronously). To disable snapshots completely: redis-cli config set save "".

Advantages

Suitable for large‑scale backup and restore.

Can be scheduled.

Works well when strict consistency is not required.

Faster loading than AOF because the file is binary.

Disadvantages

Data may be lost between snapshots if Redis crashes.

Full data copy can generate heavy I/O for large datasets.

Forking a child process may cause temporary latency or high memory usage.

When RDB Is Triggered

Configured save rules in redis.conf.

Manual save or bgsave commands.

Execution of flushall or flushdb (creates an empty RDB file).

Server shutdown without AOF enabled.

Master‑replica synchronization.

2. AOF Persistence

AOF (Append Only File) logs every write command. On restart, Redis replays the log to reconstruct the dataset.

How AOF Works

Commands are buffered in memory.

When the buffer reaches a threshold, the commands are flushed to the AOF file according to the chosen fsync policy.

Periodically Redis rewrites the AOF to compress it.

On restart, Redis reads the AOF and re‑executes each command.

appendfsync Options

always : fsync after every write (maximum durability, lowest performance).

everysec : fsync once per second (loses at most one second of data).

no : let the operating system decide when to flush (best performance, risk of more data loss).

Pros and Cons

Pros : Better data safety, fast recovery, suitable for near‑real‑time persistence.

Cons :

AOF files are larger than RDB files for the same data.

Recovery from AOF is slower than loading an RDB snapshot.

Loading Order When Both Are Enabled

If both AOF and RDB are present, Redis loads the AOF first because it usually contains a more complete history of operations.

3. Redis Transactions

A transaction groups multiple commands to be executed sequentially without interleaving from other clients. Redis transactions cannot be rolled back.

Common Transaction Commands

multi

: Start a transaction block. exec: Execute all queued commands. discard: Cancel the transaction. watch <key>: Monitor a key for changes; abort if modified before exec. unwatch: Cancel all watches.

ACID Properties in Redis

Atomicity : All commands in a transaction are executed as a single unit.

Consistency : The database remains consistent before and after the transaction.

Isolation : Concurrent transactions do not interfere with each other; the result is the same as if they ran sequentially.

Durability : Once a transaction is committed, its effects are persisted to disk according to the configured persistence mode.

4. Redis Pipelines

Pipelining batches multiple commands and sends them to the server without waiting for individual replies, reducing round‑trip latency.

Key Considerations

The pipeline does not guarantee atomicity; errors in one command do not stop subsequent commands.

Sending too many commands at once can cause high memory usage and server blocking.

Practical Example

Create a text file with several Redis commands and feed it to redis-cli using the --pipe option:

cat run.txt | redis-cli -a 111111 --pipe

These sections provide a comprehensive overview of Redis persistence options, transaction semantics, and pipeline performance techniques, enabling developers to choose the right strategy for durability and throughput in real‑world applications.