redis持久化学习

来自龙果学院，中华石杉老师的教学视频

1、RDB和AOF两种持久化机制的介绍

RDB持久化机制，对redis执行周期性的持久化

AOF机制对每条写入命令记录日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回访AOF日志中的写入指令来重新构建整个数据集

如果只是把redis当做内存缓存使用那么可以禁止RDB和AOF持久化机制

如果同时使用RDB和AOF，那么在redis重新启动的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整

2、

当新的AOF文件超过旧的AOF文件 的 auto-aof-rewrite-percentage 100  超过100%，并且容量大小大于auto-aof-rewrite-min-size 64mb 就会重写aof文件；

3、RDB 和 AOF优劣对比：

       一、  RDB持久化机制的优点：

               1、适合做冷备份，方便备份直接拷贝文件即可，方便恢复到某时刻的数据，因为rdb会生成多个文件，每个文件都代表了某一时刻redis中的数据的完整的快照；

2、RDB对redis提供的对外服务影响很小，只需要fork一个子进程，让子进程执行IO磁盘操作来进行RDB持久化；使用RDB的redis性能会更好些，因为每次写都是直接写内存，只在某些特定时间才会将数据写入磁盘中，但是AOF则每次都会写文件，虽然可以快速的写入os cache中，但还是有一些时间开销，所以相对于RDB，AOF性能更慢些；

3、相对于AOF持久化机制来说，直接根据RDB文件来进行redis恢复和重启，更加快速；因为AOF文件是一份指令日志文件，恢复的时候需要回放和执行所有的指令才能恢复内存中所有的数据，但是RDB就是一份数据文件，恢复的时候直接加载到内存中即可；

二、 RDB持久化机制的缺点：

1、RDB丢失数据可能会更多，因为RDB都是每隔5分钟或者一段时间生成一次，但是如果某个时间redis宕机了，那就会丢失最近5分钟或者一段时间内的数据，这是RDB持久化最大的缺陷，所以RDB不适合做第一恢复方案；

2、当数据量很大的时候生成RDB文件太大可能会导致生成的时候造成对客户端提供的服务暂停几毫秒甚至几秒；所以使用RDB持久化机制的时候最好不要设置太久的间隔；

三、 AOF持久化机制的优点：

1、AOF可以更好的保护数据不丢失；因为AOF策略基本上是每隔1s执行一次fsync函数，将os cache中数据写到磁盘中，如果丢失数据最多也只是丢失最近1s中的数据；

2、AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入效率很高，而且不易损毁，就算结尾损毁，恢复起来也很方便；

3、AOF日志文件如果过大，出现后台的重写操作，也不会影响客户端的读写；因为写rewrite log的时候会先基于当前的redis数据创建出一份需要恢复的数据的最小的新日志，创建新文件的时候老的文件还可以继续写入，当新的merge后的日志文件ready的时候，再交换新老文件即可；

4、AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某君不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令删除，然后再将该AOF文件放回去，就可以通过恢复机智，自动恢复所有数据。

四、AOF持久化机制的缺点：

1、因为AOF记录的是指令的日志，所以对于同一份数据来说，AOF文件会比RDB文件大，占用磁盘空间更多；

2、AOF支持的QPS会比RDB支持的QPS低一些，因为AOF基本每1s执行一次fsync操作，将os cache中的数据写入磁盘，不过1s执行一次fsync操作性能也是很高的，只不过比RDB方式低一些；

3、AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的额方式，更加脆弱一些，容易有bug，不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的日志进行merge的，而是基于当前内存中的数据进行指令的重新构建，这样健壮性会好很多。