共计 1587 个字符，预计需要花费 4 分钟才能阅读完成。
本篇内容主要讲解“Redis 中的两种持久化方式是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“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 中的两种持久化方式是什么”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
