Redis持久化

1,为什么要有持久化

Redis是内存数据库，如果不讲内存中的数据保存到磁盘，那么一旦服务器进程退出，服务区中的数据状态也会消失。所以Redis提供了持久化功能

2,RDB

在主从复制中RDB是用来做备用的

在指定时间间隔内讲内存中的数据写入磁盘，也就是Snapshot快照，他恢复时是将快照文件直接读到内存里，Reid会单独创建（fork）一个子进程进行持久化，会先将数据写入一个临时文件中，待持久化过程结束了，在用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何IO操作，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不那么敏感，那么RDB方式要比AOF更加高效，RDB的缺点也是最后一次持久化的数据可能会全部丢失，redis是默认RDB一般情况下不需要修改这个配置。
RDB保存文件是 dump.rdb文件
这里可以配置RDB文件名

3,触发机制

1，save的规则满足的情况下会自动触发RDB规则
2，执行flushall命令也会触发我们的RDB规则
3，redis关机时也会产生RDB文件
备份就会制动生成一个dump.rdb文件

4,如何恢复RDB文件

1，只需要将rdb文件放在redis启动目录就可以，redis启动时会制动检查dump.rdb恢复其中的数据
2，查看需要存放的位置

几乎自己默认的配置以及够用

5,RDB的优缺点

优点：
1，适合大规模数据恢复！
2，对数据完整性要求不高
缺点：
1，需要一定的时间间隔，
2，如果宕机最后一次的数据就没有了
3，fork进程的时候会占用一定的内存空间

注意：在生成环境中我们会将这个文件进行备份

6,AOF

将所有命令都记录下来，history，恢复的时候将里面的数据在记录一边，以日志的形势来记录每个写操作，将redis执行过的所有命令记录下来（读的操作不记录），只记录追加文件但不可以改写文件，redis启动只初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的不同将写指令重前到后在执行一次以完成数据的恢复工作
AOF保存的是appendonly.aof文件

append

默认是不开启的要手动开启
appendonly yes

AOF规则

默认是不开启的，我们需要手动进行配置！我们只需要将appendonly 改为yes就开启了 aof！
重启redis就可以生效了
如果这个aof文件有错误，这时候redis是启动不起来的，需要修复这个aof文件
redis给我们提供了一个工具 redis-check-aof --fix

提示上面信息aof文件修复成功
如果文件正常重启可以直接恢复了

aof 优点和缺点

优点:
1,每一次修改都同步，文件完整性更加好
2,每秒同步一次，可能会丢失一秒的数据
3,从不同步，效率最高的！
缺点:
1，相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
2，aof运行效率也比rdb慢（aof是读写操作），所以我们redis默认的配置就是rdb持久化

重写规则说明

随着命令不断从AOF缓存中写入到AOF文件中，AOF文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制来压缩AOF文件。

AOF文件的压缩和RDB文件的压缩原理不一样，RDB文件的压缩是使用压缩算法将二进制的RDB文件压缩，而AOF文件的压缩主要是去除AOF文件中的无效命令，比如说：

• 同一个key的多次写入只保留最后一个命令
• 已删除、已过期的key的写命令不再保留

AOF重写的触发机制也分为手动触发和自动触发两种方式。

手动触发
执行bgrewriteaof命令直接触发AOF重写

自动触发
在redis.config配置文件中有两个配置项
auto-aof-rewrite-min-size 64MB
auto-aof-rewrite-min-percenrage 100

上面两个配置表示：

• 当AOF文件小于64MB的时候不进行AOF重写
• 当当前AOF文件比上次AOF重写后的文件大100%的时候进行AOF重写

可以在redis.conf配置文件中添加这两个参数来自动触发AOF重写，执行bgrewriteaof命令

如果aof文件大于64mb这个时候fork一个新的进程来讲我们的文件进行重写

AOF重写流程

执行bgrewriteaof命令的时候，如果当前有进程正在执行AOF重写，那么直接返回；如果有进程正在执行bgsave，那么等待bgsave执行完毕再执行AOF重写。
Redis主进程会fork一个子进程执行AOF重写，开销和RDB重写一样。
AOF重写过程中，不影响Redis原有的AOF过程，包括写消息到AOF缓存以及同步AOF缓存中的数据到硬盘。
AOF重写过程中，主进程收到的写操作还会将命令写到AOF重写缓冲区，注意和AOF缓冲区区分开。
由于AOF重写过程中原AOF文件还在陆续写入数据，所以AOF重写子进程只会拿到fork子进程时的AOF文件进行重写。
子进程拿到原AOF文件中的数据写道一个临时的AOF文件中。
子进程完成AOF重写后会发消息给主进程，主进程会把AOF重写缓冲区中的数据写道AOF缓冲区，并且用新的AOF文件替换旧的AOF文件。
上面讲的是AOF重写的主要流程，下面再讲一些细节上的东西：

• Redis对AOF的重要性看得比RDB重，因为RDB的时候如果有进程正在执行AOF，那么直接返回；而AOF的时候如果有进程正在执行RDB，那么等RDb结束再执行AOF。
• Redis再AOF重写的时候新建一个AOF重写缓冲区的目的是为了保证重写过程中的写命令数据不会丢失。
• 子进程在重写AOF文件的时候，每次写硬盘的数据量由配置决定，不能太大，否则会导致硬盘阻塞（默认32MB）。
• AOF重写的整个过程有三个部分会阻塞进程：
• 主进程fork子进程的时候
• 主进程把AOF重写缓冲区中的数据写到AOF缓冲区的时候
• 使用新的AOF文件替换掉旧的AOF文件的时候

扩展

1，RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2，AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件体积不至于太大

3，只做缓存，如果只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4，同时开启两种持久化方式
(1)在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据要完整
（2）RDB的数据不实时，同时使用两者时服务器也只会找AOF文件，那么还要不要使用AOF，建议不要，因为RDB更适合备份数据库（AOF在不断变化不好备份），快速启动，而且不会有AOF可能潜在的BUG，留着作为一个万一的手段

5，性能建议
（1）因为RDB文件只用作备份用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够，只保留save 900 1 这条规则
（2）如果Enable AOF，好处是在恶劣的情况下也只会丢失不超过两秒的数据，启动脚本较简单值load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的堵塞几乎是不可避免的，只要硬盘许可，应该尽量减少AOF rewrite的评率，AOF重写的基础大小默认是64M太小了，可以设置5G以上，默认超过原大小100%大小重写可以改到适当的值
（3）如果不用Enable AOF 仅靠Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动，代价是如果Maste/Slave同时倒掉，会丢失几十分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构