REDIS的RDB持久化机制和AOF持久化机制的原理及知识梳理【一篇文章，深入浅出，so easy】

1.为什么redis需要使用持久化机制？

· 这个一句话带过即可，redis做缓存，贼快，基于内存操作，假设现在redis中有1000w条缓存数据，一旦redis出现宕机，那么此时缓存中的数据就会基于内存全部消失，所有的请求直接打入MySQL，此时的MySQL在高并发的情况下，宕机的可能性几乎4个9；

redis持久化机制恢复故障的意义如图：

2.redis中的持久化机制有哪几种？分别有什么好处？这两个持久化机制应该如何选择呢？

· RDB持久化机制

1.RDB本身redis默认就是开启的，可以进入redis.conf目录下，vi进入redis.conf文件输入/save，然后enter查找下，就能看到类似这种(目前没带笔记本，暂时先文字填充，然后后续截图)
例如
这个配置的意思就是：如果你在1000毫秒中也就是1秒钟，向redis写入了60条数据，就会自动的生成一份rdb快照文件，一般使用默认的配置也可以，根据自己项目实际情况而定，例如5分钟，写入XXX条数据就生成一份快照文件，可以配置多个，【RDB的工作流程机制图】

2.RDB机制的优点和缺点，RDB持久化机制的优点：RDB生成的日志文件，就是数据本身，也就是数据文件，所有这个机制非常适合做冷备份，可以写个脚本，分小时级，日级，月级向例如亚马逊，阿里云备份一份，一旦发生宕机，即刻可拉取备份【PS:这里如果不知道如何写脚本和操作的，可以留言，再做多一份专门的专栏，这里专门分享redis中的两种持久化机制】，缺点显而易见：回头想一下，如果正好save的机制没有被触发，此时的redis发生了宕机，那么，是不是这5分钟或者是半个小时的缓存数据全部直接丢失？

· AOF持久化机制

1.AOF机制默认是没有开启的，也是在redis.conf文件下，输入命令/appendonly查看一下将no改为yes就开启了redis中的AOF持久化机制，AOF机制稍微要比RDB的持久化机制稍微复杂一些，但是也并不可怕，大家都用过MySQL数据库，这里解释一下，AOF和RDB不同的点在于，AOF是：insert
into user values(“aaa”，“bbb”)；RDB是：id aaa，name
bbb，意思就是，AOF的appendonly.aof文件中存储的是你写入数据的命令行，而RDB存储的是数据键值对，也就是数据的根本。这里要解释一下的就是：appendonly的一个写入机制，看图【这个图完整说明了AOF的写入机制，redis每秒调用fsync将数据刷入磁盘，这个配置也可以更改，默认一般就ok，铺垫以及AOF如果满载了，rewrite的机制触发】：

【接着上面继续扩容，相信很多朋友和我一样，在学习的时候会对新鲜的东西好奇起来，redis能存无线的数据吗？aof日志文件只有一份，那岂不是超级无敌的庞大？aof的rewrite的操作是什么用？触发条件和机制又是什么？】---->一张图【rewrite操作的图解，redis的伪LRU淘汰算法的铺垫】，解决上面的几个小问题：

那么说过来说过去，重点是否有些偏移？一点都不偏移，真正的学习，就是不断的好奇，继续进入主题，那么说了这么多，AOF究竟有什么优势呢？很简单，AOF对于RDB来说，数据更加的完整，AOF会将所有的写入命令逐条的追加到AOF日志文件中，类似与append().append().这样的API，数据非常的完整，并且不容易出现破损，就算是破损了，也有对应的恢复机制，这个百度百度即可

那还有问题呢？AOF不是达到一定的文件大小就会rewrite？此时写入数据的时候会不会写入不进去？

答：不会，为啥？

因为AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写，因为在rewrite
log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来，再创建新日志文件的时候，老的日志文件还是照常写入，当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

都说了这么多AOF的好处了，那就选AOF好了？
【这不是缺点来了】

1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大;
2.AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的；
3.AOF也发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来，所以说，类似AOF这种较为复杂的基于命令日志/merger/回放的方式，比基于RDB每次持久化一份完整的数据快照文件，会更加脆弱，容易出bug，不过AOF就是为了避免reweite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多
4.做数据恢复的时候会比较慢，做冷备会比较不方便，需要手写一些复杂的脚本。

3.RDB持久化机制和AOF持久化机制到底改怎么选择呢？

答：双开，redis支持两种持久化机制的双开【综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备份，在AOF文件都丢失或者是损坏不可用的时候，还可以使用RDB来进行快速的数据恢复】

4.RDB持久化机制和AOF持久化机制双开后恢复数据的坑点：

但是还是有些踩坑的问题，那就再继续分享分享一张图，解开心中疑惑：

总结总结，因为字体的繁多，我也尽可能的简化了很多语言组织，写的不好的地方还请在评论区指出，多多包含；

声明：转发请备出处！谢谢！所有的原图可以找我申领，redis的生产环境的部署，集群的搭建，哨兵模式，主从分离，redis如何支撑海量数据，几十万的QPS，master node和slave node的主从分离痛点等等，包括小到linux上面的静态IP配置，网段，全部画图笔记，可以无条件分享，谢谢大家。