Redis 持久化机制（RDB和AOF）

      背景 我们知道Redis是一种NoSql数据库，常用来做缓存数据库，因为运行在内存中，不用每次再到数据库中去查询需要的数据，所以比普通的关系型数据库性能更优越，在内存中操作数据肯定比磁盘上性能是很大的提高。所用很多企业都拿redis来做缓存数据库。在内存中存储数据就会涉及到一个不可避免的问题，如果宕机或者机器受到物理损坏或者关机的时候，内存中的数据就会消失。但是当我们再次开启redis服务的时候，数据还是存在的。既然是数据在内存中存储，我们再次开机时候，内存又加载了我们机器出问题时候的数据。redis具体是怎么做到的，这就是我们今天所要说的redis持久化机制。

 

  原理 redis持久化实现有两个方式RDB(Redis DataBase)和AOF（Append Only File）都是通过来保存文件在磁盘中，在redis服务在启动时，在将数据读取到内存中。所以我们在重启开启服务时候，发现之前的数据还存在。下面来详细分析一下两者的区别和优劣势。

 

 一、RDB（Redis DataBase）

   实现机制 rdb方式是通过在是定时间内将内存中的数据集快照（Snapshot）写入磁盘；在数据恢复时，再将快照中的信息读取到内存中。

    原理 在实现rdb方式时，redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束后，再讲这个临时文件替换上次已经持久化好的文件。整个过程主进程不进行任何IO操作，保证Redis性能的高效性。我们知道IO操作是非常消耗性能的。

    配置文件详解 我们想玩通rdb就应该详细知道配置文件的配置，通过配置文件来操作rdb缓存。下面我将配置文件关于rdb存储方式的配置摘取出来贴出，方面大家掌握。

################################ 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.
#   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   
 //900ms 1次（1分钟1万次）save 300 10   
//300ms 10次（5分钟10万次）save 60 10000  
//60ms 10000次（15分钟1次）
//写入出错就停止，如果配置成no，表示不在乎数据是否一致stop-writes-on-bgsave-error yes  
//是否压缩，存储在磁盘上的快照可以设置，如果不想消耗cup内寸的话，可以关闭rdbcompression yes
//在存储快照后，可以让redis使用CRC64算法进行数据校验，这样做会增加性能的消耗，如果希望redis达到最大性能的提升，可以关闭次功能rdbchecksum yes
# The filename where to dump the DB
//保存在磁盘的快照名称 以.rdb结尾dbfilename dump.rdb
//保存路径,默认启动文件的根路径dir ./

  操作（触发快照）

 

 命令 save 、bgsave 会触发快照，执行flushall命令也会产生.rdb文件但是为空，相当于将之前的操作清空，没有意义。

 save、bgsave区别：

 save： save只管保存，其他不管，全部阻塞；

 bgsave： redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

 数据恢复 将备份好的rdb文件移动到redis安装目录，启动服务即可将.rdb文件中的信息加载到内存。

 获取redis安装目录

   

停止操作

 动态的停止rdb保存规则方式；通过命令 config set save ""

优势&劣势 

  优势：适合大规模的数据恢复，对数据的完整性和一致性要求不高；

  劣势：在一定的时间间隔内做备份，会丢失一部分数据，因为一般会丢失最后一次的保存记录，可以通过lastsave获取最后一次快照的时间查看。

总结  rdb是一个高效的持久化方式，与接下来要说的aof相比，在恢复数据层面，rdb更加高效；但是存在数据丢失的风险；刚才劣势里面也提到了，再者rdb一般的备份形式需要经常fork子进程来保存数据到硬盘上，当数据集比较大的时候，fork会消耗一点的时间，对客户端的响应会有一定的影响。如果是在高频率的请求下，会对性能也会产生很大的影响。

二、AOF(Append Only File)

  实现机制 aof是以日志文件的形式来记录每一个写操作，redis执行的过程中只要是涉及到写的操作指令都会被记录下来，如果是读的话不会被记录。每一步操作只是在原有文件的基础上追加，而不会改写之前的指令记录，我们当重新启动服务时，只是将其存储的指令又重新执行一遍，通过这种方式完成数据的恢复工作。

  原理 原理还是将存储的.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.
默认是关闭状态，yes就是打开aof持久化
appendonly no

# The name of the append only file (default: "appendonly.aof")
存储在磁盘的文件名，可以更改文件名，但是文件格式不能修改
appendfilename "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
 aof有三种不同模式的记录方式，上面的一段红色标注有详细说明；i.默认是everysec，异步操作每秒钟同步一次；ii.no 不调用sync，让操作系统自行决定同步时间；iii.always一直接同步，每一次的变更都会被立即记录在磁盘上
appendfsync everysec
 appendfsync no

# 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.
重写时是否可以运用appendfsync，用默认no即可，保证数据的安全性
no-appendfsync-on-rewrite no

# 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.
设置重写的基准值redis会记录上次重写时的aof大小。假如redis自启动至今还没有进行过重写，那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例，则会触发重写。另外，你还需要设置一个最小大小，是为了防止在aof很小时就触发重写。如果auto-aof-rewrite-percentage 0 设置为0，重写功能则会关闭
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb //最小64m触发重写

# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
redis启动时候加载.aof文件如果末尾文件不完整的话，是否截取掉，如果是yes，自动截取正常启动，如果设置为no则会报错
aof-load-truncated yes

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.
aof-use-rdb-preamble no
默认是关闭状态，yes就是打开aof持久化
appendonly no

# The name of the append only file (default: "appendonly.aof")
存储在磁盘的文件名，可以更改文件名，但是文件格式不能修改
appendfilename "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
 aof有三种不同模式的记录方式，上面的一段红色标注有详细说明；i.默认是everysec，异步操作每秒钟同步一次；ii.no 不调用sync，让操作系统自行决定同步时间；iii.always一直接同步，每一次的变更都会被立即记录在磁盘上
appendfsync everysec
 appendfsync no

# 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.
重写时是否可以运用appendfsync，用默认no即可，保证数据的安全性
no-appendfsync-on-rewrite no

# 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.
设置重写的基准值redis会记录上次重写时的aof大小。假如redis自启动至今还没有进行过重写，那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例，则会触发重写。另外，你还需要设置一个最小大小，是为了防止在aof很小时就触发重写。如果auto-aof-rewrite-percentage 0 设置为0，重写功能则会关闭
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb //最小64m触发重写

# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
redis启动时候加载.aof文件如果末尾文件不完整的话，是否截取掉，如果是yes，自动截取正常启动，如果设置为no则会报错
aof-load-truncated yes

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.
aof-use-rdb-preamble no

 

<span style="color:#4f4f4f">启动/恢复/修复数据</span>

启动，将appendonly no改为yes就开启了aof备份方式，将备份的数据复制到redis的安装目录上面介绍过怎么查看redis的安装目录；

恢复，直接开启redis的服务；

修复，如果文件损坏，使用redis-check-aof --fix <需要修复的文件.aof>;修复完成后再重启。

优势&劣势

 劣势： 对于相同体量的互数据集来说，aof文件的大小要大于rdb文件；aof的fsync的策略根据选择可能慢与RDB;

 优点；aof文件只是一个文件进行追加，而且在文件体积过大时自动触发重写机制；aof文件记录的都是数据库写操作的语句方便人阅读，分析起来也更加容易。

如何选择

   rdb方式可以在指定的时间内对数据进行快照存储；aof方式记录每一次对服务器的写操作，redis还能对aof文件进行后台重写，使得aof文件体积不至于过大，而rdb就没有这种机制；

  当我们同时开启两钟持久化方式，redis重启时候会优先载入aof文件来恢复数据，因为在一般情况写aof存储的文件数据比rdb形式存储的文件更加的完整。

rdb的数据不实时，同时使用两种启动时候也只会照aof文件启动方式，我们在使用时可以将两者同时开启以防万一，玩意aof文件损坏或者丢失，不能修复。这时候可以通过rdb的方式来恢复数据。