Redis持久化

一.RDB(Redis Database)

1、基础知识

1.1、基础：

　　默认的持久化机制。
　　可以定时备份内存中的数据集。
　　每个某段时间内，如果发生了超过特定次数的写操作，则进行持久化。
　　生成的持久文件为/opt/apps/redis-2.8.18/bin/dump.rdb。
　　创建rdb文件后，时间计数器和次数计数器清零。
　　通过rdb恢复数据库，只需要将rdb文件拷贝到redis家目录的bin目录下启动服务器即可。

　　注：如果rdb文件出现问题，可以使用bin目录下的redis-check-dump工具修复：执行 “redis-check-dump --fix dump.rdb” 即可。

1.2、RDB持久化的四种形式：

　　a) 满足配置文件中的配置参数，自动进行bgsave（打开子进程，异步）操作。
　　b) 客户端手动执行save（阻塞，其他操作等待）操作。
　　c) flushall。产生的rdb文件是空的，没啥意义。
　　d) shutdown。产生的rdb文件是空的，没啥意义。

1.3、SAVE 和 BGSAVE 命令

　　SAVE：不用创建新的进程，速度略快；适合停机维护，服务低谷时段
　　BGSAVE：需要创建子进程，消耗额外的内存；适合线上执行

1.4、配置文件讲解

more /opt/apps/redis-3.0.0/redis.conf
    37 daemonize no    #####是否在后台运行，安装时应将此处改为“daemonize yes”
    45 port 6379    #####redis默认监听的端口为6379
    140 #   save ""    #####注销142/143/144，打开本行，则等同于关闭rdb持久化
    141 
    142 save 900 1    #####在15分钟内，有1个写操作，则进行持久化
    143 save 300 10    #####在5分钟内，有10个写操作，则进行持久化
    144 save 60 10000    #####在1分钟内，有10000个写操作，则进行持久化
注：
    142/143/144   必须背
    159 stop-writes-on-bgsave-error yes    #####如果生成rdb可能出错，就禁止写入新数据。如果改成no,就可能造成数据的不一致。
    165 rdbcompression yes    #####是否采用压缩。默认采用LZF的压缩格式。
    174 rdbchecksum yes    #####rdb文件生成后，是否检查校验和。大概会消增加10%的性能消耗。
    177 dbfilename dump.rdb    #####生成的rdb文件的名称
    187 dir ./    #####在当前路径生成rdb文件

1.5、通过rdb恢复数据库

   将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。

1.6、禁用rdb持久化策略

方式一：

    将

        #   save ""

        save 900 1

        save 300 10

        save 60 10000

    替换成

           save ""

        #save 900 1

        #save 300 10

        #save 60 10000

方式二：

    redis-cli config set save ""

方式三：

    不设置save指令

2、RDB  bgsave原理

3、RDB优劣与生产环境应用

优点：

    完全备份，不同时间的数据集备份可以做到多版本恢复

    紧凑的单一文件，方便网络传输，适合灾难恢复

    恢复大数据集速度较AOF快

缺点：

    会丢失最近写入、修改的而未能持久化的数据

    fork过程非常耗时，会造成毫秒级不能响应客户端请求

生产环境应用：

    创建一个定时任务crontab job，每小时或者每天将dump.rdb复制到指定目录

    确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照

版本

    定时任务删除过期的备份

    如果有必要，跨物理主机、跨机架、异地备份

二.AOF(Append Only File)

1、基础知识

1.1、基础
   a) Redis 默认不开启。如果启用，则优先使用aof恢复数据库。
   b) 采用日志的形式来记录每个写操作，并追加到文件中。
   c) Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
   d) flushall/flushdb 操作也会写入aof文件中，如果关闭数据库前最后执行了这两个操作，要恢复数据必须在启动前先去aof文尾部删除这两个操作。

1.2、aof机制剖析
　　a)AOF方式不能保证绝对不丢失数据的原因：
　　目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失。

　　b)写入磁盘的策略
　　appendfsync选项，这个选项的值可以是always、everysec或者no。
　　always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
　　everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
　　no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
　　运行速度：always的速度慢，everysec和no都很快

1.3、aof重写机制
a) 原因：

• AOF文件过大

• 合并重复的操作，AOF会使用尽可能少的命令来记录

b) aof重写的两种形式

• a)手动：客户端向服务器发送BGREWRITEAOF命令

• b)自动：配置文件中的选项，自动执行BGREWRITEAOF命令

c)过程

1、执行AOF重写请求
2、父进程执行fork创建子进程，开销等同于bgsave过程
3.1、主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区，并根据    appendfsync策略同步到磁盘，保证原有AOF机制正确性。
3.2、由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4、子进程根据内存快照，按照命令合并规则写入到新AOF文件。每次批量写入硬盘数据量由aof-rewrite-incremental-fsync控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
5.1、新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
5.2、父进程把AOF重写缓冲区数据写入到新的AOF文件。
5.3、使用新AOF文件替换老文件，完成AOF重写。

注：如果写入操作异常或者aof被恶意篡改，可以使用bin目录下的redis-check-aof工具修复：
   执行 “redis-check-aof --fix appendonly.aof” 即可。
   该命令会删除aof文件中不符合redis写操作规范的内容。

1.4、配置文件讲解

more /opt/apps/redis-3.0.0//redis.conf
    501 appendonly no    ####是否开启aof持久化策略
    505 appendfilename "appendonly.aof"    #####aof文件名称
    530 # appendfsync always    #####每次写操作，都将该操作从内存缓冲区写入aof文件
    531 appendfsync everysec    #####每间隔1秒钟将内存缓冲区中的写操作写入aof文件
    532 # appendfsync no    #####有操作系统决定何时将内存缓冲区的写操作写入aof文件
注：
    530/531/532 必背
    553 no-appendfsync-on-rewrite no    #####日志重写时，继续写入日志。改为yes则不继续写入。
            #####如果redis有较大延迟问题，可以将该参数设置为yes。
    572 auto-aof-rewrite-percentage 100    #####在aof文件大小大于auto-aof-rewrite-min-size的情况下，如果超过了上一次重写后aof文件体积的100%，则触发重写。0代表关闭aof重写。
            #####如果服务器刚启动，则以载入的aof文件体积为初始值。
    573 auto-aof-rewrite-min-size 64mb    #####考虑触发aof重写的aof文件最小体积

2、aof重写示意图

4、aof优劣

优点：
   写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
   重写机制，优化AOF文件
   如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态

缺点：
   相同数据集，AOF文件体积较RDB大了很多
   恢复数据库速度比RDB慢（文本，命令重演）

官网建议：

 如果只是用reids做缓存，不需要使用任何持久化方案。

 其他情况建议同时开启aof和rdb两种持久化方案，理由：
       aof中保存的数据集更加的完成，数据库恢复时也优先采用aof恢复。
       但aof也可能出问题，所以需要备份，aof文件动态变化不便于备份，但使用rdb备份留后手。
所以两者建议同时开启。

由于rdb制作后备用途，建议在slave上持久化rdb,且15分钟持久化一次即可，只保留save 900 1这条规则。