66.8-Redis持久化方案

成功者不是从不失败，而是从不放弃！

总结：

Redis持久化方式：RDB（Redis DB）定时保存、AOF（AppendOnlyFile）重演；

分布式文件系统：将文件分散在不同的节点上，不同节点上有多个副本；防止一部分坏了仍然可以使用；

1. Redis持久化

持久化：将数据从掉电易失的内存存放到能够永久存储的设备上

Redis服务是使用内存来存储数据，如果掉电、服务崩溃都会导致Redis中数据丢失，如有必要，可以持久化数据。

Redis持久化方式：RDB（Redis DB）、AOF（AppendOnlyFile）

1. RDB

在默认情况下，Redis 将某时间点的数据库快照保存在名字为 dump.rdb的二进制文件中

策略
自动：按照配置文件中的条件满足就执行BGSAVE(后台自动保存)
手动：客户端发起SAVE、BGSAVE命令

配置

save 900 1 
save 300 10 
save 60 10000 
dbfilename dump.rdb 
dir /var/lib/redis/6379

save 60 1000，Redis要满足在60秒内至少有1000个键被改动，会自动保存一次
只要满足上面3个条件之一，就自动执行快照
执行完后，时间计数器和次数计数器都会归零重新计数。这多个条件不是叠加效果

SAVE命令：阻塞式命令，执行期间不响应客户端的请求
BGSAVE：非阻塞命令，执行期间还可以接收并处理客户端请求，会folk一个子进程创建RDB文件

192.168.142.135:6379> SAVE
192.168.142.135:6379> BGSAVE

优点

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

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

快照文件直接恢复，大数据集速度较AOF快

缺点
会丢失最近写入、修改的而未能持久化的数据
folk过程非常耗时(消耗内存)，会造成毫秒级不能响应客户端请求

RDB备份策略
创建一个定时任务cron job，每小时或者每天将dump.rdb复制到指定目录
确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照版本
定时任务删除过期的备份
如果有必要，跨物理主机、跨机架、异地备份

2. AOF

Append only ﬁle，采用追加的方式保存，默认文件appendonly.aof 。
记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库（重演）

AOF写入机制

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

写入磁盘的策略
appendfsync选项，这个选项的值可以是always、everysec或者no

Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的

运行速度：always的速度慢，everysec和no都很快

AOF重写机制

写操作越来越多的被记录，AOF文件会很大。Redis会合并写操作，以压缩AOF文件。
合并重复的写操作，AOF会使用尽可能少的命令来记录。

重写过程

folk一个子进程负责重写AOF文件

子进程会创建一个临时文件写入AOF信息

父进程会开辟一个内存缓冲区接收新的写命令

子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写操作由子进程写入到临时文件中

新文件替代旧文件

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

原有AOF文件	重写后的AOF文件
SELECT 0	SELECT 0
SADD fruits “apple”	SADD fruits “apple” “banana” “cherry”
SADD fruits “banana”	SET msg “hello world again!”
SADD fruits “cherry”	RPUSH lst 3 5 7
SADD fruits “apple”
INCR counter
INCR counter
DEL counter
SET msg “hello world”
SET msg “hello world again!”
RPUSH lst 1 3 5
RPUSH lst 7
LPOP lst

AOF重写触发

手动：客户端向服务器发送BGREWRITEAOF命令
自动：配置文件中的选项，自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size> ，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写

auto-aof-rewrite-percentage <percent> ，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

重写配置举例

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
当AOF文件大于64MB时候，可以考虑重写AOF文件
只有当AOF文件的增量大于起始size的100%时（就是文件大小翻了一倍），启动重写

appendonly yes
默认关闭，请开启

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

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