Redis中的两种持久化方式，为什么需要两种持久化？

redis中有两种持久化（aof和rdb），下面本篇文章带大家了解一下这两种持久化，看看它们的优缺点，介绍一下为什么redis需要两种持久化，希望对大家有所帮助！

Redis的两种持久化方式

众所周知，Redis中提供了AOF，RDB两种持久化，下面先来简单回顾一下。

RDB持久化

• RDB持久化，就是把当前时间点的数据库的状态保存到磁盘中，又称快照持久化。
• RDB可以手动触发，也可以根据服务器配置定期执行。
• RDB生成的文件，是一个经过压缩的二进制文件，数据库可以通过该文件还原到该时间点的状态。
• Redis提供前台RDB持久化命令SAVE和后台RDB持久化命令BGSAVE，前台执行时，Redis的其他命令会被阻塞，而后台执行时，Redis还可以继续处理客户端的命令请求。
• RDB二进制文件中，保存的是键值对数据，采用经过压缩的自定义编码，带校验。通过od命令可以转化为可读。
• 主从复制时，初始化的全量复制采用RDB文件。

【相关推荐：Redis视频教程】

AOF持久化

• AOF持久化，全称是Appen Only File，意思是追加的持久化方式，其中保存的是写命令，而非数据。
• AOF持久化过程分为命令追加、文件写入、文件同步三个步骤。
• 命令追加：Redis服务端每执行完一个写命令，都会以AOF协议格式将该写命令追加到服务器状态的aof_buf缓冲区末尾。
• 文件写入：Redis中，每结束一个事件循环之前，都会调用flushAppendOnlyFile函数，将aof_buf缓冲区中的内容写入到AOF文件。
• 文件同步：同步sync指的是文件写入到操作系统缓冲区中时，是否直接同步到磁盘中。通过配置，可以选择立即同步、每秒同步、不主动同步而由操作系统控制，这三种同步方式。关于文件I/O缓冲：https://www.litreily.top/2018/10/25/io-cache/
• Redis优先使用AOF文件来恢复数据。
• AOF文件由于存储命令，且没有经过压缩，其体积要大于RDB文件。
• AOF文件可以定期采用BGREWRITEAOF重写，减少重复命令、已失效命令，合并命令等。
• AOF文件支持后台重写，采用fork子进程的形式实现。子进程带有服务器进程的数据副本，再避免使用锁的情况下保证数据安全性。另外也采用AOF重写缓冲区解决了数据不一致。

两种持久化分别的优缺点

RDB的优点

• 文件体积小，适合拷贝做冷备

• 相比AOF，备份恢复速度更快

RDB的缺点

• 丢失数据多

• fork子进程来做BGSAVE，消耗一定的内存资源

AOF的优点

• 丢失数据少

• 增加了写缓冲区，无需寻址，速度快

• append-only，也无需做磁盘寻址，效率高

AOF的缺点

• 文件体积大

• AOF每次都需要做一下写入aof_buf的操作，开启AOF持久化后，QPS会略微降低

Redis为什么需要两种持久化？

经过上面的回顾，我们可以看到，RDB与AOF持久化有明显区别。

• 存储的内容：RDB存储某一时间点的数据；AOF存储执行的写命令。

• 文件大小：RDB文件较小；AOF文件较大。

• 写入方式：RDB可采用前台/后台写入方式；AOF采用每次执行写命令，都将命令存入缓冲区的方式，另外可定期重写。

• 数据丢失：RDB丢失从宕机到上一次RDB同步之间的所有数据；AOF根据I/O缓冲区所配置的刷新方式，不丢失或丢失1s或几秒的数据。

根据这些对比，可以看到RDB持久化更适合保存一个时间点的数据，在主从复制或者数据全量异地灾备时，拷贝到其他地方，而AOF持久化由于丢失数据较少，比较适合作为本地备份，在Reids挂掉重启时作为故障恢复。这就是我理解的为什么Redis需要两种持久化方式。

更多编程相关知识，请访问：编程入门！！

以上就是Redis中的两种持久化方式，为什么需要两种持久化？的详细内容，更多请关注php中文网其它相关文章！