Redis（三）：Redis的持久化

redis持久化有以下方式：

RDB

​ RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

​ RDB是Redis默认采用的持久化方式。

​ Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。（注：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程））

​ 查看reids配置文件一下部分：

# 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 at all commenting all the "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

​ 可知，在默认配置下，如果在900秒内至少有一个key改变，redis就进行持久化数据；在300秒内至少有10个key改变，就进行持久化数据；在60秒内有10000key改变，就进行持久化数据。当然，这个配置我们也可以根据实际情况去做出改变。

​ 如果我们需要立即保存的话，可以手动保存，只需要使用命令save或bgsave即可。其中的区别为：

​ Save：save时只管保存，其它不管，全部阻塞。

​ bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

​

​ 通过配置文件下面部分

# The filename where to dump the DB
dbfilename dump.rdb

​ 我们可以知道redis进行持久化后将数据储存在dump.rdb中。因某些原因要备份的话只需要将要恢复的dump.rdb放到redis安装目录并启动redis即可。

​ RDB适合大规模的数据恢复，并对数据完整性和一致性要求不高。在备份时因为fork的原因，内存中的数据被克隆了一份，会造成大致2倍的膨胀性。虽然在一定间隔时间做一次备份，但如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。故数据非常重要的话，可以考虑使用AOF方式进行持久化。

AOF

​ 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

appendonly no
# The name of the append only file (default: "appendonly.aof")
# appendfilename appendonly.aof

​ 由redis配置文件可知，AOF默认不开启，可以将no改为yes开启。再开启后，AOF默认将备份保存在appendonly.aof文件中。同样的，只需要将文件放在redis安装目录下重启redis即可恢复。

# appendfsync always
appendfsync everysec
# appendfsync no

​ AOF采用文件追加方式，由配置文件知道，追加方式有3中。其中，always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好。everysec：出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失。no：从不同步。

​ 由于AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。（重写：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。）

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

​ Redis会记录上次重写时的AOF大小，由配置文件知道默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写机制。可以根据需要改这个配置。

继续看配置文件

# 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.

​ 可知，redis在启动时，如果同时有dump.rdb和appendonly.aof，redis优先读取appendonly.aof文件进行数据恢复。那么，在实际中，这两个文件都可能存在损坏情况，在这种情况下，redis就会启动失败。这时候，就需要我们去校验修正文件了，具体命令如下：

redis-check-aof --fix appendonly.aof
redis-check-aof --fix dump.rdb

​ AOF运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同。并且，对于相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。

总结

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。