二、Redis的持久化

二、Redis的持久化

    持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

    1、方式

        (1)、RDB（Redis DataBase）默认

            ①、RDB的保存有方式分为主动保存与被动保存。

            ②、主动保存可以在 redis-cli 中输入 save 即可，被动保存需要满足配置文件中设定的触发条件，目前官方默认的触发条件可以在 redis.conf 中看到。

        (2)、 AOF（Append Only File）

            ①、AOF持久化方式记录每次对服务器写的操作，读操作不记录，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

            ②、AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

    2、RDB和AOF比较

        (1)、RDB优点

            ①、RDB是一个非常紧凑的文件，它保存了某个时间点的数据集，非常适用于数据集的备份，比如你可以在每个小时保存一下过去24小时内的数据，同时每天保存过去30天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。

            ②、RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复。

            ③、与AOF相比，在恢复大的数据集的时候，RDB 方式会更快一些。

            ④、RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，将数据集写入到一个临时RDB文件中。当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化Redis的性能。

        (2)、AOF优点

            ①、AOF更新频率更高。

            ②、AOF文件有序地保存了对数据库执行的所有写入操作，写入操作均以Redis协议的格式保存，因此AOF文件的内容更容易被人读懂。

            ③、还原数据优先使用AOF。

        (3)、比较

            ①、RDB方式将过去一段时间内的数据保存为一个单一的文件，可以将文件备份到其他服务器，并且在恢复大量数据的时候，RDB方式的速度会比AOF方式的恢复速度要快。

            ②、AOF方式默认每秒钟备份1次，频率很高，它的操作方式是以追加的方式记录日志而不是数据，并且它的重写过程是按顺序进行追加，所以它的文件内容非常容易读懂。可以在某些需要的时候打开AOF文件对其编辑，增加或删除某些记录，最后再执行恢复操作。

            ③、RDB由于备份频率不高，所以在恢复数据的时候有可能丢失一小段时间的数据，而且在数据集比较大的时候有可能对毫秒级的请求产生影响。

            ④、AOF的文件比较大，而且由于保存频率很高，所以整体的速度会比RDB慢一些，但是性能依旧很高。

            ⑤、同时开启两种持久化方式情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

    3、RDB配置

        (1)、RDB保存的文件是dump.rdb

        (2)、redis.conf中关于RDB默认配置

save 900 1 # 900秒内修改了1次key，就会触发rdb操作
save 300 1 # 300秒内修改了3次key，就会触发rdb操作
save 60 10000 # 10000秒内修改了60次key，就会触发rdb操作

            触发机制

            ①、save条件满足的情况下，会自动触发RDB规则。

            ②、执行flushall命令，会触发RDB规则。

            ③、退出Redis也会触发RDB规则。

            每次触发就会备份自动生成一个dump.rdb文件。

            RDB文件恢复

            ①、只需要将rdb文件放在Redis的启动目录，启动的时候就会自动检查加载dump.rdb中的数据。

    4、AOF配置

        (1)、AOF保存的是appendonly.aof文件，redis.conf中关于RDB默认配置

appendonly on # AOF默认不开启为no，需要改为yes开启
appendfilename "appendonly.aof" # 文件名称
# AOF文件重写触发条件
auto-aof-rewrite-percentage 100 # 当前aof文件比上次重写的增长比例大小，如果增长一倍触发重写
auto-aof-rewrite-min-size 64mb # 如果aof文件大于64M，Redis就会fork一个子进程来对文件进行重写
# AOF写入策略
#appendfsync always # 每次修改都会写入，数据完整性更好
appendfsync eversec # 默认值everysec，每秒同步一次，可能会丢失一秒的数据
#appendfsync no # 不执行写入，效率最高

        (2)、性能建议

            ①、因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这一条规则就可以。

            ②、如果开启AOF，好处是最坏也不会丢失超过两秒的数据，但是代价一是带来了持续的IO，二是AOF的文件重写过程不可避免的会对新数据写到新的文件中造成阻塞。只要硬盘允许，应该尽量少的减少重写频率，AOF重写的基础大小默认值64M，可以改为5G以上，默认超过原大小的100%也可以调整到适当的数值。

            ③、如果不开启AOF，仅靠master-slave实现高可用也可以，能省掉一大笔IO，也减少了AOF文件重写时带来的系统波动。到检就是如果master/slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个master/slave中的RDB文件，载入最新的那个，微博就是这种架构。