前言
我们都知道，redis是基于内存的K-V数据库。由于内存是断电易失的，所以redis提供了相应的持久化机制。
本篇主要讲解redis提供的RDB和AOF两种持久化方式，以及他们的实现原理。
RDB
RDB（Redis DataBase）是指把某个时刻内存中的数据生成快照（snapshot），以dump.rdb文件的形式存在磁盘上。RDB每次生成的快照（snapshot）都是redis中的全量数据。
生成快照可以由两个命令完成，分别是save和bgsave，先看下这两个命令的描述
| help save | |
| SAVE -summary: Synchronously save the dataset to disksince: 1.0.0group: server | |
| help bgsave | |
| BGSAVE -summary: Asynchronously save the dataset to disksince: 1.0.0group: server |
从描述上来看，这两个命令实现的功能一模一样，只是save是以同步的方式写入磁盘，而bgsave是以异步的方式，bg就是Background的意思。
事实上调用save命令后，redis进程会被阻塞，直到快照生成完成，期间redis不能对外提供服务。而bgsave会调用Linux的fork()函数来创建一个子进程，让子进程来生成快照，期间redis依然可以对外提供服务。
了解了RDB的相关命令，再来思考下这个问题：假设redis中有6G数据，要给这6G数据生成一个快照，不可能在一瞬间完成，肯定会持续一段时间。那么从快照开始生成（t1），到快照生成成功（t2）的这段时间内，redis中被修改的数据应该怎么处理？持久化的数据应该是t1时刻的数据，还是t2时刻的数据呢？
对于save的方式来说，生成快照期间，redis不能对外提供服务，所以在t1到t2期间不会有数据被修改。但是对于bgsave方式来说，生成快照期间，redis依然可以对外提供服务，所以极有可能有些数据被修改。这时子进程是根据t1时刻的数据来生成快照的。t1到t2期间被修改的数据只能在下一次生成快照时处理。但是在t1到t2期间被修改的值，对外部调用方来说是可以实时访问的。也就是说redis不仅要存储快照生成点(t1)时刻的所有值，还要存储变量的最新值。这样的话，redis中6G的数据，在生成快照的时候，会瞬间变成12G。
但是事实并非如此，以性能著称的redis肯定不允许这样的事发生。那这个问题是如果解决的呢？这样就不得不说copy on write机制了
copy on write（COW，写时复制）是一种计算机程序设计领域的优化策略。
其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently）。
前文提到调用bgsave时，会调用linux系统的fork()函数来创建子进程，让子进程去生成快照。fork()函数实现了copy on write机制。
如下图所示，redis调用bgsave之后，bgsave调用fork。也就是在t1时刻，内存中的数据并不会为了两个进程而复制成两份，而是两个进程中的指针都指向同一个内存地址。
此时子进程开始生成快照，如果在生成快照期间，redis中的数据被修改了，k3的值由c变成了d。操作系统仅仅会把k3复制一份，而没有变化的k1和k2不会被复制。这就是写时复制（copy on write）机制。可以看到此时子进程取到的数据还是t1时刻的数据，而redis对外提供的服务也能获取最新数据。
此处用copy on write优化的前提是生成快照的过程持续的时间较短，期间只有少量的数据发生了变化。如果期间所有的数据都发生了变化，也就相当于真的把6G数据变成了12G。
写时复制是一种优化思想，在JDK中也能看它的实现
配置
前文说RDB模式生成快照的命令是save和bgsave，但是在实际使用redis的时候，也没见我们定期手动执行这两个命令。所以快照的生成还有一种自动的触发方式，在配置文件中可以找到相关的配置
| ################################ SNAPSHOTTING ################################ | |
| # | |
| # Save the DB on disk: | |
| # | |
| # save <seconds> <changes> | |
| # | |
| # Will save the DB if both the given number of seconds and the given | |
| # number of write operations against the DB occurred. | |
| # | |
| # In the example below the behaviour will be to save: | |
| # after 900 sec (15 min) if at least 1 key changed | |
| # after 300 sec (5 min) if at least 10 keys changed | |
| # after 60 sec if at least 10000 keys changed | |
| # | |
| # Note: you can disable saving completely by commenting out all "save" lines. | |
| # | |
| # It is also possible to remove all the previously configured save | |
| # points by adding a save directive with a single empty string argument | |
| # like in the following example: | |
| # | |
| # save "" | |
| save 900 1 | |
| save 300 10 | |
| save 60 10000 |
save配置表示调用bgsave。save 60 10000表示如果在60秒内，超过10000个key被修改了，就调用一次bgsave。同理save 300 10表示300秒内，超过10个key被修改了，就调用一次bgsave。多个save不是互斥的，如果配置多个save，只要满足其中一个就会执行bgsave，配置多个是为了适应不同的场景。
配置save ""或者注释所有的save表示不开启RDB。
从配置文件配置的save参数来看，如果每60秒执行一次bgsave，而在59秒的时候服务宕机了，这样就丢失了59秒内修改的数据，因为还没来得及生成快照。数据丢失量这么大，肯定是不被允许的。为此，redis还提供了另一种持久化方式，那就是AOF
AOF
AOF（Append Only File）是把对redis的修改命令以特定的格式记录在指定文件中。也就是说RDB记录的是数据快照，而AOF记录的是命令。AOF默认是关闭的。
| ############################## APPEND ONLY MODE ############################### | |
| # By default Redis asynchronously dumps the dataset on disk. This mode is | |
| # good enough in many applications, but an issue with the Redis process or | |
| # a power outage may result into a few minutes of writes lost (depending on | |
| # the configured save points). | |
| # | |
| # The Append Only File is an alternative persistence mode that provides | |
| # much better durability. For instance using the default data fsync policy | |
| # (see later in the config file) Redis can lose just one second of writes in a | |
| # dramatic event like a server power outage, or a single write if something | |
| # wrong with the Redis process itself happens, but the operating system is | |
| # still running correctly. | |
| # | |
| # AOF and RDB persistence can be enabled at the same time without problems. | |
| # If the AOF is enabled on startup Redis will load the AOF, that is the file | |
| # with the better durability guarantees. | |
| # | |
| # Please check http://redis.io/topics/persistence for more information. | |
| appendonly no | |
| # The name of the append only file (default: "appendonly.aof") | |
| appendfilename "appendonly.aof" |
如果开启了AOF，相应的命令会记录在appendonly.aof文件中。
appendonly.aof这个文件的内容本身也需要写到磁盘中，如果appendonly.aof还未来得及写入磁盘，服务就宕机了，也会造成appendonly.aof文件内容丢失，而丢失redis的修改命令，进而丢失redis的修改数据。
为此redis为appendonly.aof的持久化提供了三种配置方式：
| # The fsync() call tells the Operating System to actually write data on disk | |
| # instead of waiting for more data in the output buffer. Some OS will really flush | |
| # data on disk, some other OS will just try to do it ASAP. | |
| # | |
| # Redis supports three different modes: | |
| # | |
| # no: don't fsync, just let the OS flush the data when it wants. Faster. | |
| # always: fsync after every write to the append only log. Slow, Safest. | |
| # everysec: fsync only one time every second. Compromise. | |
| # | |
| # The default is "everysec", as that's usually the right compromise between | |
| # speed and data safety. It's up to you to understand if you can relax this to | |
| # "no" that will let the operating system flush the output buffer when | |
| # it wants, for better performances (but if you can live with the idea of | |
| # some data loss consider the default persistence mode that's snapshotting), | |
| # or on the contrary, use "always" that's very slow but a bit safer than | |
| # everysec. | |
| # | |
| # More details please check the following article: | |
| # http://antirez.com/post/redis-persistence-demystified.html | |
| # | |
| # If unsure, use "everysec". | |
| # appendfsync always | |
| appendfsync everysec | |
| # appendfsync no |
这三种方式都是通过参数appendfsync来指定。
- no：并不是不持久化，只将数据写到OS buffer，由操作系统决定何时将数据写到磁盘，这种方式速度最快
- always：每次在appendonly.aof中追加内容，都调用fsync()将数据写入磁盘，这种方式最慢，但是最安全
- everysec：默认配置，表示每秒调用一次fsync()，将数据写入磁盘，是一种折中的方式
根据配置可以知道，如果每秒将appendonly.aof的内容写到磁盘一次。那么在两次写磁盘的间隔，如果服务宕机了，还是有可能丢失部分命令，从而导致redis的修改数据丢失，不过相比于RDB来说，这种丢失已经非常非常小了。
除此之外，appendonly.aof文件是以追加的方式写入命令，对于长时间运行的服务，必定会导致该文件过大。万一服务宕机需要根据appendonly.aof文件恢复数据，将会消耗相当长的时间来执行appendonly.aof中记录的命令。
为了解决appendonly.aof文件过大的问题redis提供了一种机制，叫bgrewriteaof。
bgrewriteaof
bgrewriteaof命令描述如下
| help bgrewriteaof | |
| BGREWRITEAOF -summary: Asynchronously rewrite the append-only filesince: 1.0.0group: server |
这个命令的作用就是fork()出一个子进程来对appendonly.aof文件进行重写。这个重写操作在redis4.0以前和4.0以后有不同的实现方式。
redis4.0以前的重写主要有两点：删除抵消的命令、合并重复的命令。对于set key1 a和del key1这样相互抵消的命令会被直接删除。对于set key1 a和set key1 b这样重复的命令会进行合并。这样一通操作之后，AOF文件可能会变得很小。
redis4.0之后，开启了RDB和AOF的混合模式。也就是将已有的数据以RDB的方式记录在appendonly.aof文件的头部，对于之后的增量数据以AOF的方式继续追加在appendonly.aof文件中，也就是appendonly.aof文件前半段是快照数据，后半段是redis指令。
这样的混合模式结合了RDB和AOF的优点，既能最大限度的减少数据丢失，又能在Redis重启后迅速恢复数据。
那么在什么情况下会触发bgrewriteaof呢？除了手动触发，配置文件中提供了几个相关参数来实现自动触发
| # Automatic rewrite of the append only file. | |
| # Redis is able to automatically rewrite the log file implicitly calling | |
| # BGREWRITEAOF when the AOF log size grows by the specified percentage. | |
| # | |
| # This is how it works: Redis remembers the size of the AOF file after the | |
| # latest rewrite (if no rewrite has happened since the restart, the size of | |
| # the AOF at startup is used). | |
| # | |
| # This base size is compared to the current size. If the current size is | |
| # bigger than the specified percentage, the rewrite is triggered. Also | |
| # you need to specify a minimal size for the AOF file to be rewritten, this | |
| # is useful to avoid rewriting the AOF file even if the percentage increase | |
| # is reached but it is still pretty small. | |
| # | |
| # Specify a percentage of zero in order to disable the automatic AOF | |
| # rewrite feature. | |
| auto-aof-rewrite-percentage 100 | |
| auto-aof-rewrite-min-size 64mb |
auto-aof-rewrite-min-size参数设置成64mb，意思是redis尚未执行过bgrewriteaof（从启动开始算），AOF文件需要达到64mb才会第一次执行bgrewriteaof（此后不会再使用auto-aof-rewrite-min-size参数），redis会记录每次执行bgrewriteaof之后，AOF文件的大小。
auto-aof-rewrite-percentage设置成100，表示当前的AOF文件大小超过上一次bgrewriteaof后AOF文件的百分比后触发bgrewriteaof。如果上次bgrewriteaof后，AOF为200mb，现在需要AOF文件达到400mb才会执行bgrewriteaof。
auto-aof-rewrite-percentage设置成0，表示禁用bgrewriteaof。auto-aof-rewrite-min-size参数的作用就是在AOF文件比较小的时候，防止因为增长过快而频繁调用bgrewriteaof。
no-appendfsync-on-rewrite
redis主进程在写AOF文件采用always或者everysec配置，和子进程在重写AOF文件的时候，都会产生大量的I/O操作。可能会使fsync阻塞很长时间，为了缓解这个问题，redis提供了no-appendfsync-on-rewrite这个参数
| # When the AOF fsync policy is set to always or everysec, and a background | |
| # saving process (a background save or AOF log background rewriting) is | |
| # performing a lot of I/O against the disk, in some Linux configurations | |
| # Redis may block too long on the fsync() call. Note that there is no fix for | |
| # this currently, as even performing fsync in a different thread will block | |
| # our synchronous write(2) call. | |
| # | |
| # In order to mitigate this problem it's possible to use the following option | |
| # that will prevent fsync() from being called in the main process while a | |
| # BGSAVE or BGREWRITEAOF is in progress. | |
| # | |
| # This means that while another child is saving, the durability of Redis is | |
| # the same as "appendfsync none". In practical terms, this means that it is | |
| # possible to lose up to 30 seconds of log in the worst scenario (with the | |
| # default Linux settings). | |
| # | |
| # If you have latency problems turn this to "yes". Otherwise leave it as | |
| # "no" that is the safest pick from the point of view of durability. | |
| no-appendfsync-on-rewrite no |
如果开启该参数，表示在bgsave和bgrewriteaof的过程中，主线程写入AOF不会调用fsync()，相当于配置appendfsync no。这样有可能会导致redis的修改命令丢失，Linux默认配置下，最多丢失30秒的数据。
如果关闭该参数，表示在bgsave和bgrewriteaof的过程中，主线程写入AOF会调用fsync()，并且被阻塞，这样是最安全的，不会丢失数据。
总结
本文主要讲解redis两种持久化方式RDB和AOF，以及他们的实现原理。此外，还讲解了AOF文件过大怎么处理。了解这些内容，可以帮助我们更好的使用redis。
作者：Sicimike
原文链接：
https://blog.csdn.net/Baisitao_/article/details/105461153