前言
我们都知道，redis是基于内存的K-V数据库。由于内存是断电易失的，所以redis提供了相应的持久化机制。
本篇主要讲解redis提供的RDB和AOF两种持久化方式，以及他们的实现原理。
RDB
RDB（Redis DataBase）是指把某个时刻内存中的数据生成快照（snapshot），以dump.rdb文件的形式存在磁盘上。RDB每次生成的快照（snapshot）都是redis中的全量数据。
生成快照可以由两个命令完成，分别是save和bgsave，先看下这两个命令的描述
127.0.0.1:6379> help save
SAVE -
summary: Synchronously save the dataset to disk
since: 1.0.0
group: server
127.0.0.1:6379> help bgsave
BGSAVE -
summary: Asynchronously save the dataset to disk
since: 1.0.0
group: 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
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中也能看它的实现，有兴趣的同学参考：深度解析CopyOnWriteArrayList，线程安全的ArrayList
配置
前文说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命令描述如下
127.0.0.1:6379> help bgrewriteaof
BGREWRITEAOF -
summary: Asynchronously rewrite the append-only file
since: 1.0.0
group: 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。