redis的RDB和AOF持久化具体操作

前言

如何去配置RDB和AOF的持久化？？？

RDB持久化

redis配置文件redis.conf，我的是/etc/redis/6379.conf，去配置持久化

举例：save 60 1000
每个60s，如果有超过1000个key发生变化，就会新生成一个dump.rdb文件，相当于redis内存中完整快照，此操作被称为snapshotting，快照可以手动save或者bgsave，同步或者异步执行rdb快照

save可以设置多个，就是多个snapshotting检查点，每到一个检查点，都会去check一下，是否有指定的key数量发生了变更，如果有，就新生成一个dump.rdb文件

RDB持久化工作流程

1. redis根据配置自己生成rdb快照文件
2. fork一个子进程出来
3. 子进程尝试将数据dump到临时的rdb快照文件中
4. 完成rdb快照文件生成后，会替换掉之前旧的快照文件

RDB快照实验

1. redis-cli进行redis编辑
   
2. 执行 set k1 v1 set k2 v2
   
3. 查看redis快照生成，可以看到快照里面已经有数据了
   
4. 我们平时停掉redis一般是redis-cli SHUTDOWN 和 kill -9 进程
   第一种是安全退出模式，redis中的数据已经保存下来，第二种是粗暴退出，已经是一种故障模式，是一种数据丢失的情况
5. 往redis插入2条数据，直接粗暴停止，可以看到rdb文件中刚插入的两条数据是不存在的
   
6. 此时，启动redis（粗暴停止的情况下，要下删除/var/run下的redis_6379.pid）
   此时可以看到刚粗暴停止前插入的k3是可以保存到内存中的
7. 如果要保证数据丢失的很少，可以将conf文件中的save 检查点设置调小
   如 save 5 1 每5秒，有1条数据发生变化就保存新的rdb文件

AOF持久化

AOF持久化也是配置conf文件，默认是关闭的，RDB默认是打开
appendonly yes是打开AOF持久化

打开AOF持久化后，redis每接收到一条写命令，就会写入到日志文件中，首先是先写入os cache，然后每个一定时间在fsync一下

当同时打开AOF和RDB时，redis重启的时候，也是优先通过AOF进行数据恢复的，因为AOF数据较完整

配置AOF的fsync策略，有三种策略可以选择，一种是每写入一条就fsync一次，一种是每个一秒执行一次，一种是不主动执行
always：每写入一条数据，立即将对应的写命令fsync到磁盘上，性能非常差，吞吐量低，如果说确保一条不丢，就可以采取这样的措施
everysec：每秒将os cache的数据fsync到磁盘，这个是最常用的，也是redis默认的，生产环境一般这样配置，性能很高，QPS也可以达到上万
no：仅仅redis负责将数据写入os cache就不管了，然后os cache会根据自己的策略不定时的将数据写入磁盘，不可控

AOF持久化工作流程

1. redis foek一个子进程
2. 子进程基于内存中的数据，构建日志，开始往新的临时的AOF文件中写入日志
3. redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
4. 子进程写完新的日志文件之后，redis主进程将内存中新日志再次追加到新的AOF文件中
5. 用新的日志文件替换掉旧的日志文件

AOF快照实验

1. 打开AOF开关之后，重启redis，写入数据，发现/var/redis/6379下面多了一个appendonly.aof文件，里面也有我们刚写入数据的内容
   
2. 这些日志就是先写入os cache中，然后1s后才fsync到磁盘中，这样才是一个安全的过程，不然只在os cache中，机器重启，数据就没了
3. 我们kill -9杀掉redis进程后，重启redis，发现数据是恢复回来的，就是从AOF文件中恢复的，redis进程启动后，直接从appendonly.aof文件中加载所有日志
   

AOF rewrite

redis的数据是有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除算法清理掉

redis的数据会不断淘汰旧的，就一部分常用的数据会自动保留到内存中

所以，很多之前已经被清理掉的数据，对应的写日志还停留在AOF文件，AOF文件就一个，会不断变大

所以，AOF文件会自动在后台每隔一定时间做rewrite操作，比如日志存放了100W数据的写日志。redis 的内存只有10W，基于内存中的10W数据构建一套最新的日志到AOF文件中，覆盖之前的旧日志，确保AOF文件不会太大

redis2.4之后，会自动进行rewrite操作

在redis的conf中，可以配置rewrite策略

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

比如说上一次AOF rewrite后，是128mb
然后会接着128mb继续写日志，如果发现增长的比例，超过之前的的100%，256mb，就可能去触发一次rewrite
但是此时，还要去跟min-size比较一次，256mb > 64mb，就会触发rewrite

AOF文件修复

如果redis在append数据到AOF文件时，机器宕机，可能导致AOF文件破损，
可以用 redis-check-aof --fix 命令来修复破损的AOF文件

往redis插入2条数据，aof文件中也有2条

此时，删除最后一行数据

修复破损aof文件

可以看到，他把有问题的key value都删除了

然后，重启之后，发现k2是不存在了

实验所得

1. 在有rdb的dump和aof的appendonly的同时，rdb里有部分数据，aof里有部分数据，这个时候发现，rdb的数据不会恢复到内存中
2. 模拟让aof破损，然后fix，有一条数据会被fix掉，就是删除掉