Redis AOF fsync(ALWAYS)与LSM树性能差异疑问

Great question—this is a common point of confusion because on the surface, both seem to rely on append-only writes. Let’s break down the key differences that explain the huge performance gap:

• Fsync frequency is night and day
  LSM-tree databases like Cassandra don’t fsync every single write by default. Even their write-ahead logs (WALs) typically batch fsyncs—either waiting for a set number of operations, a fixed time window, or letting the OS handle flushing in the background. Redis’ fsync always mode, however, forces a blocking fsync call after every single command. This means the Redis thread has to wait for the disk to confirm the write is persisted before moving to the next request—and disk IO is orders of magnitude slower than memory operations, so this cripples throughput.

• Write granularity and batching efficiency
  LSM-trees are built around batching writes. Updates first go to an in-memory structure (memtable), and only when that memtable hits a certain size is it flushed to disk as an SSTable (a sorted, immutable file). Even the WAL in LSM systems is written in larger chunks, not per-operation. Redis’ AOF in fsync always mode appends and flushes each command individually—tiny, frequent IO operations are far less efficient than the large, sequential batches that disks are optimized for.

• Threading model differences
  Redis is fundamentally single-threaded for command processing. When you enable fsync always, that blocking fsync happens in the main thread, directly blocking all subsequent commands until the disk operation finishes. Cassandra and other LSM databases use multi-threaded architectures where WAL fsyncs can be offloaded to background threads, so frontend threads don’t get stuck waiting for disk IO. This separation keeps request latency low even when handling persistent writes.

• Redis’ core design tradeoffs
  The official docs’ warning makes perfect sense once you consider Redis’ primary goal: being a low-latency, in-memory-first system. fsync always directly contradicts this optimization by tying every command to slow disk IO. LSM databases, by contrast, are designed from the ground up to handle high-volume write workloads with disk persistence in mind—their entire structure is built to spread the cost of disk IO across hundreds or thousands of operations.

"AOF + fsync always: this is very slow, you should use it only if you know what you are doing."

This line highlights how drastically this mode alters Redis’ performance profile compared to its default behavior, and how different it is from the batched, background-flushed writes used by LSM-tree systems.

内容的提问来源于stack exchange，提问作者bhh1988