Persistence in Redis is achieved either using snapshots or by journaling.
Snapshotting means periodic writes of all objects in memory to disk to files, called RBD files. By default, the periodicity values are one of the following:
- 10,000 changes in 60 seconds
- 10 changes in 5 minutes
- 1 change in 15 minutes
When a write to disk is needed, Redis forks a child process for the save and this process is responsible for serializing all the data in memory, writing the serialized data to a temporary file, and renaming the temporary file to the actual one. While the fork may seem expensive, it's not due to the copy-on-write semantics offered by most operating systems. A page will be duplicated only when there are changes to it either in the parent or child process. When a fork happens, in many OSes, such as Linux, the kernel cannot predict the actual space needed, just the worst case that all pages will be duplicated. Some OSes, such as Linux, will, by default, fail the fork if there is not as much free RAM as all the parent memory pages. In Linux this can be turned off with the overcommit_memory setting, and this is necessary for Redis, which hogs a lot of memory.
The other approach—journaling—works by logging every write operation done by the server. The logins are done by appending to a file—which is very efficient. The log can be replayed at server startup to reconstruct the original dataset. This mode is called the append-only file (AOF) mode.
The AOF mode provides more reliability but at a performance cost, since now all writes must be logged to disk. The default fsync policy is flushed every one second—but this comes with the risk of losing data. If, to avoid this, the setting is changed to fsync at every write, the performance of writes will be significantly slower. Another disadvantage of AOF is that for use cases such as counters, the file can get big very fast with very little value (the old counter values are not needed!).
I generally recommend you don't enable persistence but rather use high-availability solutions (described in the Clustering section). Also, data that is a single source of truth should ideally not be stored in Redis.