Redis Persistence, Transactions, and Distributed Locks

Redis keeps data in memory, which means data is lost on power failure or crashes. To avoid this, Redis provides two permanent storage mechanisms: RDB (snapshot) and AOF (append‑only file).

RDB creates a point‑in‑time snapshot of the dataset. The directory for the snapshot is set by the dir configuration (e.g., /opt/redis-4.0.0/logs). After connecting with redis-cli -p 6380, you can store some keys and trigger a snapshot with the save command. The resulting dump.rdb appears in the configured directory.

Example:

redis-cli -p 6380<br/>set name zhangsan<br/>set age 20<br/>save

Configuration options such as dbfilename, dir, rdbcompression, and rdbchecksum control the snapshot file name, location, compression, and checksum verification.

Because save blocks the server, production environments usually prefer the background version bgsave, which forks a child process to write the RDB file. The save interval can be automated with the save 10 2 directive (snapshot if at least two keys change within ten seconds).

AOF records every write command to an append‑only log. Unlike RDB, AOF logs operations, so on restart Redis replays the log to rebuild the dataset. AOF supports three sync policies:

always – sync after every write (highest durability, lowest performance)

everysec – sync every second (default, good balance)

no – let the OS decide (least durable)

To enable AOF, add to the config: appendonly yes<br/>appendfsync always The resulting appendonly.aof file grows with each write. You can change its name with appendfilename appendonly-6380.aof. When many commands affect the same key, the file can become bloated; the bgrewriteaof command rewrites the log to keep only the final state.

Transactions in Redis are executed atomically using multi / exec. Commands queued between these two are run as a single unit, preventing interleaving from other clients. Errors can abort the transaction with discard.

Example: multi<br/>set name zhangsan<br/>get name<br/>exec Locks can be implemented with watch to monitor a key and abort the transaction if the key changes before exec. For distributed scenarios, setnx creates a simple lock:

setnx lock-key value   # acquire lock<br/>incrby num -1        # modify shared resource<br/>del lock-key         # release lock

If another client already holds the lock, setnx returns 0, indicating the operation should wait or abort.

To avoid deadlocks when a lock is not released (e.g., due to a crash), set an expiration time: expire lock-num 60 After 60 seconds Redis automatically removes the lock, preventing indefinite blocking.