redis持久化 前言RDB持久化RDB持久化工作流程RDB快照实验 AOF持久化AOF持久化工作流程AOF快照实验AOF rewriteAOF文件修复 实验所得
前言
如何去配置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持久化工作流程 redis根据配置自己生成rdb快照文件fork一个子进程出来子进程尝试将数据dump到临时的rdb快照文件中完成rdb快照文件生成后，会替换掉之前旧的快照文件 RDB快照实验 redis-cli进行redis编辑执行 set k1 v1 set k2 v2
查看redis快照生成，可以看到快照里面已经有数据了
我们平时停掉redis一般是redis-cli SHUTDOWN 和 kill -9 进程
第一种是安全退出模式，redis中的数据已经保存下来，第二种是粗暴退出，已经是一种故障模式，是一种数据丢失的情况往redis插入2条数据，直接粗暴停止，可以看到rdb文件中刚插入的两条数据是不存在的
此时，启动redis（粗暴停止的情况下，要下删除/xwdzdj/run下的redis_6379.pid）
此时可以看到刚粗暴停止前插入的k3是可以保存到内存中的如果要保证数据丢失的很少，可以将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会根据自己的策略不定时的将数据写入磁盘，不可控
这些日志就是先写入os cache中，然后1s后才fsync到磁盘中，这样才是一个安全的过程，不然只在os cache中，机器重启，数据就没了我们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 100auto-aof-rewrite-min-size 64mb比如说上一次AOF rewrite后，是128mb
然后会接着128mb继续写日志，如果发现增长的比例，超过之前的的100%，256mb，就可能去触发一次rewrite
但是此时，还要去跟min-size比较一次，256mb > 64mb，就会触发rewrite
如果redis在append数据到AOF文件时，机器宕机，可能导致AOF文件破损，
可以用 redis-check-aof --fix 命令来修复破损的AOF文件
往redis插入2条数据，aof文件中也有2条
此时，删除最后一行数据
修复破损aof文件
可以看到，他把有问题的key value都删除了
然后，重启之后，发现k2是不存在了