09-Redis持久化

一、Redis持久化

Redis 提供了不同级别的持久化方式:

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
• 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整，AOF是每秒追加一次，RDB保存需要满座条件比较高
• Redis默认使用的RDB，而且AOF默认是不开启的，需要我们手动开启。
• RDB和AOF同时开启redis会优先默认读取AOF文件数据，因为理论上数据不会丢失，丢失页就丢失1秒中的数据，隐影响不大。

二、RDB持久化

2.1、RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份，比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

2.2、RDB的缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

2.3、RDB是什么

根据官网的介绍我们可以得知，RDB持计化方式，是在指定的时间间隔内，将我们内存的数据集快照写入磁盘，进行快照存储，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

2.4、Fork进程

RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能，我们的父进程继续完成我们数据库操作，备份数据交给Fork出的进程，这个进程只是备份了这个进程之前的数据，这个进程之后的数据并没有备份，有可能导致数据的丢失。

 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

2.5、RDB持久化的流程示意图

2.6、dump.rdb文件

2.6.1、rdb持计化文件

RDB持计化，fork出的子进程会把内存中的数据保存到我们的rdb文件中，而这个RDB文件就是我们的redis.config配置文件中的dump.rdb，这个文件会在我们的redis启动目录下生成。

在redis.conf中配置文件名称，默认为dump.rdb

2.6.2、rdb文件持计化保存的位置

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下
dir ./ 表示在当前目录下生成，但是我们可以指定生成的位置，
eg:“dir /myredis/rdb/”

2.7、触发RDB快照保存：保持策略

2.7.1、配置文件默认触发条件

格式：save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。
禁用RDB
不设置save指令，或者给save传入空字符串

2.7.2、手动执行命令save 和bgsave

• save ：save时只管保存，其它不管，全部阻塞，手动保存，不建议。
• bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求，可以通过lastsave 命令获取最后一次成功执行快照的时间。

2.7.3、flushall 清空库key指令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

2.8、stop-writes-on-bgsave-error

当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes，也就是出现写错误时一种解决方案

2.9、rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

2.10、rdbchecksum 检查rdb文件完整性

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes.
就是检查我们存储的rdb文件是否存在错误，比如，我们多一个字母，或者我们手动删除了一个key，导致不完整，就会检查出来，提示我们是否进行修复。
原理是和我们之前的保存的文件进行对比，得出我么想要的数据。

2.11、rdb备份

redis启动时，会自动查看我们的启动目录是否存在dump.rdb文件，如果存在的话，就会加载rdb中的数据，备份也是基于这个原理。

先通过config get dir 查询rdb文件的目录
将.rdb的文件拷贝到别的地方*
rdb的恢复

• 关闭Redis
• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动Redis, 备份数据会直接加载

2.12、停止RDB

修改redis配置文件，不设置save指令，或者给save传入空字符串，
动态停止RDB：redis-cli config set save “”#save后给空值，表示禁用保存策略

三、AOF持久化

3.1、AOF是什么

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，AOF命令以redis协议追加保存每次写的操作到文件末尾.注意是只保存写操作的指令。

3.2、AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

3.3、AOF开启、恢复、修复

3.3.1、开启

redis默认不开启我们的AOF，需要我们在配置文件中手动设置为开启，修改默认的appendonly no，改为yes，可以在redis.conf中配置文件名称，默认为 appendonly.aof，AOF文件的保存路径，同RDB的路径一致。

3.3.2、恢复（备份）

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

• 修改默认的appendonly no，改为yes
• 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir）
• 恢复：重启redis然后重新加载

3.3.3、异常修复恢复

• 修改默认的appendonly no，改为yes
• 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
• 备份被写坏的AOF文件
• 恢复：重启redis，然后重新加载

3.4、AOF同步频率设置

redis配置文件中设置

• appendfsync always
  始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
• appendfsync everysec
  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
• appendfsync no
  redis不主动进行同步，把同步时机交给操作系统。

3.5、Rewrite压缩 （重写AOF文件）

3.5.1、是什么

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

3.5.2、重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
no-appendfsync-on-rewrite：
如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）
触发机制，何时重写
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。
例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3.5.3、重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。
（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

3.6、优势

 备份机制更稳健，丢失数据概率更低。
 可读的日志文本，通过操作AOF稳健，可以处理误操作。

3.7、劣势

 比起RDB占用更多的磁盘空间。
 恢复备份速度要慢，要重新执行所有写的指令。
 每次读写都同步的话，有一定的性能压力。
 存在个别Bug，造成恢复不能。

四、AOF和RDB使用建议

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。