持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第24天，点击查看活动详情
🍊作者简介：少年不想说话，努力长大
🍊往期回顾：从零开始Redis（十三）
🍊近期目标：写完基础源码，点赞👍🏼、收藏⭐、留言📩
上面我们说了持久化的基本概念，今天我们来对比下两种持久化方式的比较，话不多说，开始；
Redis持久化比较
前面我们已经看了持久化的方式和持久化的基本概念了，我们再来看看其他特性； 首先来说文件大小，RDB的文件相对于AOF来说文件比较小，这里我们要注意下，
一个是RDB形式存储的是数据集，数据集就是我们的数据，它只有一个文件，所以它对内存的消耗较小，特别容易恢复，
一个是AOF文件，它是一个只进行追加操作的日志文件，日志文件相较于纯数据文件而言恢复数据肯定慢一点， 由于AOF的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加，AOF文件的体积也会变得越来越大。大了肯定有很多重复的日志，而我们只需要 保留数据，所以我们得对AOF进行重写，我们可以通过BGREWRITEAOF命令进行重写， 该指令运行时会开辟一个子进程对内存进行遍历，将内存中的数据转换为Redis的操作指令，再序列化到日志文件中。最后替换原有的AOF文件，就完成了AOF的重写了； 也可以自动重写，在redis.config中配置重写机制：通过设置
no-appendfsync-on-rewrite为yes，开启重写机制；
auto-aof-rewrite-percentage 50表示比上次重写后的文件大小增长了50%后再次触发重写；
auto-aof-rewrite-min-size 64MB表示当文件最少达到64mb才触发重写机制， 重写机制是很安全的，因为重写新的AOF的过程中，我们继续执行的命令依然会存在旧的AOF中，即使重写又崩了，也不影响（再啰嗦一句，重写是读取内存数据重写的，这里有点啰嗦，甚至和上篇有点重复，因为真的很细节） ，如果AOF文件有问题，我们可以用Redis提供的redis-check-aof来进行修复；
RDB小而快，AOF大而全且慢，RDB在cpu资源紧张时fork的子进程会影响服务的运行造成数据丢失，AOF则不会，AOF数据恢复会出现Bug（基本很少出现），RDB不会，选谁，这个是没有定论的，通常的建议是如果需要持久化就把两个都配置上，不需要就都不配，两者互相协调是目前的最优解吧；好啦🥗🥗🥗；
结束结束，那就🛴🛴🛴
如果对你有所帮助
点个赞呗
