这是我参与2022首次更文挑战的第26天，活动详情查看：2022首次更文挑战」
前言
上次分享到Redis持久化的一个方法：RDB持久化，说接下来结合实际例子进一步理解一下，参考文章，希望理解可以加深一些~
实例
- 在将内存数据同步到硬盘的过程中，Redis服务在收到数据写操作请求时如何保持数据一致性呢？
RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。
- 在执行快照操作的期间，如果发生服务器崩溃怎么办？ 很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。
- 快照的间隔时间多少好呢？ 对于快照来说，间隔时间很关键。因为即使在某一时刻发生宕机了，上一时刻快照刚执行，那丢失的数据也不会太多。但是也不是间隔时间越小越好，因为如果频繁地执行全量快照，会带来磁盘的开销，同时也可能频繁阻塞主线程。解决方法就是做增量快照，也就是做了一次全量快照后，后续的快照只是对修改的数据进行快照记录。
RDB优缺点
-
优点
- RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；
- Redis加载RDB文件恢复数据要远远快于AOF方式；
-
缺点
- RDB方式实时性不够，无法做到秒级的持久化；
- 每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；
- RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全；
- 版本兼容RDB文件问题；
综述
对于RDB方法的缺点，redis提供了另一种解决方案，下次继续~
