Optimizing Redis Persistence with Non‑Volatile Memory: Design, Performance, and Recovery

Redis is a simple, high‑performance open‑source key‑value database used for caching and persistent storage, offering configurable trade‑offs between read/write performance, capacity, and reliability.

Redis provides two persistence mechanisms—RDB and AOF—and a hybrid RDB‑AOF mode introduced in version 4.0. AOF has two write policies: Always , which flushes each write to disk for maximum safety but incurs severe performance loss, and Everysec , which buffers writes and flushes periodically, delivering higher throughput at the risk of losing up to one second of data.

Choosing between these modes forces users to balance performance and data safety; failover also introduces cache warm‑up latency. The large performance gap between DRAM and SSD motivates the adoption of emerging Non‑volatile Memory (NVM) technologies.

NVM offers byte‑addressable, persistent storage with much higher density and lower cost than DRAM, and read/write speeds far exceeding traditional SSDs, though it exhibits asymmetric read/write and sequential/random performance characteristics.

Typical NVM application scenarios include persistent memory, in‑memory databases, and system‑log volumes such as checkpointing in high‑performance computing.

To leverage NVM for Redis, the AOF file is placed on a PMEM‑aware filesystem (e.g., EXT4 DAX) and memory‑mapped into user space. Subsequent AOF accesses become lightweight load/store operations, and persistence is achieved simply by flushing the CPU cache, bypassing the conventional block‑device I/O stack.

Space consumption of the ever‑growing AOF file is mitigated by a background thread that replays AOF commands to reconstruct the KV structure on NVM and then deletes the replayed file, eliminating unnecessary storage overhead.

Performance tests on two 96‑core/384 GB servers show that SET operations on string data structures achieve throughput comparable to the Everysec mode while retaining the safety of the Always mode. Restart recovery time drops dramatically: loading a 10 GB RDB snapshot takes about 53 seconds in native Redis, whereas the NVM‑based solution provides read‑only service in under one second and full read‑write service within 35 seconds.

Beyond speed, NVM reduces storage cost, enables dynamic migration of data between DRAM (as a write cache and hot‑data read cache) and NVM (as a persistent, high‑capacity tier), and expands overall storage capacity without harming baseline performance.

In conclusion, the NVM‑enhanced Redis delivers high reliability, high performance, and low cost; however, challenges such as replay throughput for heavy write workloads and write service availability during failover remain and will be addressed in future work.