Redis持久化
Redis是内存数据库，如果不将内存中的数据库保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失，所以 Redis 提供了持久化的功能（RDB 和 AOF）！
RDB（Redis DataBase）
什么是RDB？
在主从复制中，RDB就像是备用到从机上！
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存中。
工作方式：
Redis 会单独创建（fork）一个子进程来进行持久化操作，会先将数据写入到一个临时RDB之中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO的操作。这就确保了极高的性能。
如果需要进行大规模的数据恢复，但对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点就是最后一次持久化后的数据可能丢失。
RDB的触发机制
要点
rdb的配置在
redis.conf配置文件中的快照部分进行配置的！Redis默认的持久化操作就是RDB，一般情况下不需要修改这个配置！
有时候在生成环境中我们会将这个文件进行备份！
rdb保存的文件是dump.rdb，
我们可以自定配置save规则触发保存内存数据到RDB。
三种触发机制
1、save的规则满足的时候，会自动触发rdb进行持久化
2、执行flushall命令，也会触发我们的rdb持久化
3、退出redis进程后，也会产生rdb文件
生成的dump.rdb文件默认存放再/usr/local/bin目录下（存放的目录也可以在配置文件定义），也就是redis服务启动目录下
如何恢复rdb文件
1、查看rdb文件存放的位置
127.0.0.1:6379> config get dir 1) "dir" 2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb 文件，启动就会自动恢复其中的数据
2、如果该目录下存在 dump.rdb文件，redis启动就会自动恢复其中的数据。
几乎就他自己默认的配置就够用了，但是我们还是需要去学习！
优缺点
优点
1、适合大规模的数据恢复！
2、对数据的完整性要求不高！
缺点
1、需要一定的时间间隔才会进行持久化操作！如果redis在最后一次意外宕机，那么最后一次修改的数据也就没有了！
2、fork子进程的时候，会占用一定的内存空间！
AOF（Append Only File）
aof 将我们所有的命令都记录下来，相当于历史记录history，恢复的时候就把这个文件全部在执行一遍！
aop是什么
工作的流程图
父进程会一直处理client请求，并且会fork 子进程同步数据
aof 方式同步的数据，是以日志的形式来记录的，它会将Redis 执行过程的所有指令记录下来（读操作不记录），只允许追加文件但不可以改写文件
redis 启动的时候会读取该文件，重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次，完成数据的恢复工作。
aof的配置
redis.conf 配置文件的位置
默认是不开启的，我们需要手动进行配置！只需要将上面的no 改成yes 就开启了aof！
如果redis是开启状态，需要重启才能生效！
触发机制
1、只有在 redis服务重启后，才会在redis的启动目录下生成appendonly.aof文件
2、如果在redis服务启动后，删除 appendonly.aof文件，那么执行命令的时候不会再生成自动生成该文件。需要注意。
如果文件出错，如何修复aof文件？
如果日志文件文件出错，连接redis服务时，会导致连接不成功
通过
redis-check-aof命令修复，就在启动目录下
1、首先我们开启aof 持久化，重启 redis服务后，会在redis启动目录下生成appendonly.aof文件，该文件一开始是没有记录的。
2、我们保存几条数据，并关闭 redis 服务
[ bin]# redis-cli -p 6379 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> set k3 v3 OK 127.0.0.1:6379> shutdown not connected> quit
3、查看日志文件
[ bin]# cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $2 k1 $2 v1 *3 $3 set $2 k2 $2 v2 *3 $3 set $2 k3 $2 v3
4、在最后一行制造错误，输入乱七八糟的的字符
5、重启 redis服务，并连接
发现连接被拒绝了
6、修复该日志文件 redis-check-aof
可以看到修复的结果，就是将错误的数据删除
[ bin]# redis-check-aof --fix appendonly.aof # 修复文件 0x 6a: Expected \r\n, got: 6466 AOF analyzed: size=123, ok_up_to=81, diff=42 This will shrink the AOF from 123 bytes, with 42 bytes, to 81 bytes Continue? [y/N]: y # 这里输入y确定 Successfully truncated AOF
7、如果文件正常，重启服务，再次连接即可！
日志文件重写规则说明
aof 默认就是文件的无限追加，文件会越来越大！
如果 aof 文件大于64m，就会fork一个新的进程来将我们的文件进行重写！
优缺点
优点
有三个机制
1、每一次修改都可以同步数据，保证了文件的完整性！
2、每一秒修改都会同步一次，但是最后一秒的数据可能会丢失！
3、可以设置从不同步数据，那么效率就会很高！
缺点
1、相对于数据文件来说，aof 文件的容量 远远大于 rdb文件
2、修复速度也比 rdb慢！
3、aof 运行效率也要比 rdb慢
所以redis的默认配置是rdb持久化！
扩展：
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5、性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。