本文主要是介绍redis持久化方式—RDB，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
RDB快照
与AOF记录写操作命令不同，RDB直接记录内存中的二进制数据，reids恢复数据时，直接将RDB文件加载到内存中就可以了，听起来是不是RDB完虐AOF？那么看完本文，会让你的态度转变，因为RDB的缺点比AOF更糟糕
RDB快照怎么用？
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：
- 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
- 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；
RDB 文件的加载工作是在服务器启动时自动执行的，Redis 并没有提供专门用于加载 RDB 文件的命令。
Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令，默认会提供以下配置：
save 900 1
save 300 10
save 60 10000
别看选项名叫 save，实际上执行的是 bgsave 命令，也就是会创建子进程来生成 RDB 快照文件。
只要满足上面条件的任意一个，就会执行 bgsave，它们的意思分别是：
- 900 秒之内，对数据库进行了至少 1 次修改；
- 300 秒之内，对数据库进行了至少 10 次修改；
- 60 秒之内，对数据库进行了至少 10000 次修改。
看上去RDB 和 AOF 有几点相似之处：
1.都有在主进程、子进程进行持久化的方式
2.主进程中的持久化操作和主进程的其它操作是串行的，有阻塞主进程的风险
3.fork出子进程进程持久化势必会出现持久化过程中主进程添加新数据而造成父子进程数据不一致的问题
注意
前文没有详细说明，RDB快照是全量快照，也就是说每次执行save或bgsave命令会将当前数据库的全部内存数据进行记录
现在，聪明的你，发现RDB的致命缺陷了吗？
RDB的致命缺陷
1.由于RDB是对数据库当前内存数据的全量快照，势必造成前后两次生成的RDB文件有重复部分，并且重复的数量会越来越大
2.全量快照导致了，RDB文件会随数据库的体积增大而增大，在生成较大RDB文件时会对redis造成性能影响，这也是RDB需要使用bgsave在子进程中持久化的原因
3.正是由于生成较大体积的RDB文件的开销较大，因此RDB操作不能像AOF那样频繁，因此RDB有持久化的窗口期，会造成数据丢失的风险，而相比之下，AOF安全的多
说说bgsave的问题
bgsave创建一个子进程，进行RDB持久化操作，与AOF类似，子进程只拥有fork时刻的父进程数据库状态，在子进程持久化过程中新加入到父进程的数据，在子进程中是没有的，这部分数据只能在下一次RDB时进行持久化，如果在下一次RDB前redis宕机，那么这部分数据就会丢失，这部分丢失的数据是比AOF要多的，因为RDB对新数据的持久化频率远低于AOF
终极方案——RDB+AOF混合持久化
我在“AOF持久化”的文章中介绍到，AOF有解决持久化过程中由于新数据的加入，造成父子进程数据不一致而导致的数据丢失方案————持久化过程中，将新数据追加到父进程、子进程，从而实现数据同步
但RDB不同，由于RDB是对数据库的全量快照，没有用到AOF所使用的缓冲区，那么持久化过程中的新数据丢失问题就没办法解决了吗？
解决方案是AOF
如果想要开启混合持久化功能，可以在 Redis 配置文件将下面这个配置项设置成 yes：
aof-use-rdb-preamble yes
混合持久化工作在 AOF 日志重写过程。
开启了混合持久化后，在AOF使用fork创建子进程来进行AOF重写时，不再将数据库中的内存数据转换成命令，而是像RDB一样，直接将内存数据以RDB格式写入到FOD文件中，在这个过程中，父进程新加入的数据也会追加到AOF子进程的aof重写缓冲区内，这部分数据是AOF格式，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。
混合持久化对AOF和RDB的优化：
1.混合持久化优化了AOF重写时，将数据库的内存数据转换成命令的这个过程，实际上将内存数据转换成命令这步操作是冗余的，AOF重写之所以进行这个转换，是为了保证AOF文件格式的一致性，
而混合持久化的AOF文件中有RDB和AOF两种文件格式，避免了将内存数据转换成命令的步骤，提高了持久化效率
2.RDB在bgsave持久化过程中父进程添加的新数据有丢失的风险，且没有手段规避（AOF遇到同样的问题有解决方案），而混合持久化将RDB有丢失风险的这部分数据，采用了AOF的方案：追加命令到子进程的aof重写缓冲区，并以aof格式保存
总结
混合持久化的方案结合了RDB的快速加载、AOF的数据安全（数据丢失少）的优点，一定程度规避了RDB的易丢失数据、AOF加载慢的缺点
重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。
加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失
推荐学习 https://xxetb.xetslk.com/s/p5Ibb
这篇关于redis持久化方式—RDB的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
