共计 3411 个字符，预计需要花费 9 分钟才能阅读完成。
自动写代码机器人，免费开通
丸趣 TV 小编给大家分享一下 Redis 持久化方案的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
Redis 支持 RDB 与 AOF 两种持久化机制，持久化可以避免因进程异常退出或 down 机导致的数据丢失问题，在下次重启时能利用之前的持久化文件实现数据恢复。
RDB 持久化
RDB 持久化即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。RDB 持久化是 Redis 默认的持久化方式。RDB 持久化的触发包括手动触发与自动触发两种方式。
手动触发
save，在命令行执行 save 命令，将以同步的方式创建 rdb 文件保存快照，会阻塞服务器的主进程，生产环境中不要用
bgsave, 在命令行执行 bgsave 命令，将通过 fork 一个子进程以异步的方式创建 rdb 文件保存快照，除了 fork 时有阻塞，子进程在创建 rdb 文件时，主进程可继续处理请求
自动触发
在 redis.conf 中配置 save m n 定时触发，如 save 900 1 表示在 900s 内至少存在一次更新就触发
主从复制时，如果从节点执行全量复制操作，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点
执行 debug reload 命令重新加载 Redis 时
执行 shutdown 且没有开启 AOF 持久化
redis.conf 中 RDB 持久化配置
# 只要满足下列条件之一，则会执行 bgsave 命令
save 900 1 # 在 900s 内存在至少一次写操作
save 300 10
save 60 10000
# 禁用 RBD 持久化，可在最后加 save
# 当备份进程出错时主进程是否停止写入操作
stop-writes-on-bgsave-error yes
# 是否压缩 rdb 文件 推荐 no 相对于硬盘成本 cpu 资源更贵
rdbcompression no
AOF 持久化
AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以 append 的形式追加保存到 AOF 文件中。在服务器下次启动时，就可以通过载入和执行 AOF 文件中保存的命令，来还原服务器关闭前的数据库状态。
redis.conf 中 AOF 持久化配置如下
# 默认关闭 AOF，若要开启将 no 改为 yes
appendonly no
# append 文件的名字
appendfilename appendonly.aof
# 每隔一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 当 AOF 文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的 100%）。
auto-aof-rewrite-percentage 100
# 当 AOF 文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb
AOF 持久化的实现包括 3 个步骤:
命令追加：将命令追加到 AOF 缓冲区
文件写入：缓冲区内容写到 AOF 文件
文件保存：AOF 文件保存到磁盘
其中后两步的频率通过 appendfsync 来配置，appendfsync 的选项包括
always，每执行一个命令就保存一次，安全性最高，最多只丢失一个命令的数据，但是性能也最低（频繁的磁盘 IO）
everysec，每一秒保存一次，推荐使用，在安全性与性能之间折中，最多丢失一秒的数据
no，依赖操作系统来执行（一般大概 30s 一次的样子），安全性最低，性能最高，丢失操作系统最后一次对 AOF 文件触发 SAVE 操作之后的数据
AOF 通过保存命令来持久化，随着时间的推移，AOF 文件会越来越大，Redis 通过 AOF 文件重写来解决 AOF 文件不断增大的问题（可以减少文件的磁盘占有量，加快数据恢复的速度），原理如下：
调用 fork，创建一个子进程
子进程读取当前数据库的状态来“重写”一个新的 AOF 文件（这里虽然叫“重写”，但实际并没有对旧文件进行任何读取，而是根据数据库的当前状态来形成指令）
主进程持续将新的变动同时写到 AOF 重写缓冲区与原来的 AOF 缓冲区中
主进程获取到子进程重写 AOF 完成的信号，调用信号处理函数将 AOF 重写缓冲区内容写入新的 AOF 文件中，并对新文件进行重命名，原子地覆盖原有 AOF 文件，完成新旧文件的替换
AOF 的重写也分为手动触发与自动触发
手动触发：直接调用 bgrewriteaof 命令
自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。其中 auto-aof-rewrite-min-size 表示运行 AOF 重写时文件最小体积，默认为 64MB。auto-aof-rewrite-percentage 表示当前 AOF 文件大小（aof_current_size）和上一次重写后 AOF 文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size auto-aof-rewrite-min-size（aof_current_size – aof_base_size）/aof_base_size = auto-aof-rewrite-percentage
RDB vs AOF
RDB 与 AOF 两种方式各有优缺点。
RDB 的优点：与 AOF 相比，RDB 文件相对较小，恢复数据比较快（原因见数据恢复部分）
RDB 的缺点：服务器宕机，RBD 方式会丢失掉上一次 RDB 持久化后的数据；使用 bgsave fork 子进程时会耗费内存。
AOF 的优点：AOF 只是追加文件，对服务器性能影响较小，速度比 RDB 快，消耗内存也少，同时可读性高。
AOF 的缺点：生成的文件相对较大，即使通过 AOF 重写，仍然会比较大；恢复数据的速度比 RDB 慢。
数据库的恢复
服务器启动时，如果没有开启 AOF 持久化功能，则会自动载入 RDB 文件，期间会阻塞主进程。如果开启了 AOF 持久化功能，服务器则会优先使用 AOF 文件来还原数据库状态，因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，保存的数据更完整。
redis 数据库恢复的处理流程如下，
在数据恢复方面，RDB 的启动时间会更短，原因有两个：
RDB 文件中每一条数据只有一条记录，不会像 AOF 日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了，文件相对较小。
RDB 文件的存储格式和 Redis 数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在 CPU 消耗上要远小于 AOF 日志的加载。
但是在进行 RDB 持久化时，fork 出来进行 dump 操作的子进程会占用与父进程一样的内存，采用的 copy-on-write 机制，对性能的影响和内存的消耗都是比较大的。比如 16G 内存，Redis 已经使用了 10G，这时 save 的话会再生成 10G，变成 20G，大于系统的 16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用 redis 的时候一定对系统内存做好容量规划。
RDB、AOF 混合持久化
Redis 从 4.0 版开始支持 RDB 与 AOF 的混合持久化方案。首先由 RDB 定期完成内存快照的备份，然后再由 AOF 完成两次 RDB 之间的数据备份，由这两部分共同构成持久化文件。该方案的优点是充分利用了 RDB 加载快、备份文件小及 AOF 尽可能不丢数据的特性。缺点是兼容性差，一旦开启了混合持久化，在 4.0 之前的版本都不识别该持久化文件，同时由于前部分是 RDB 格式，阅读性较低。
开启混合持久化
aof-use-rdb-preamble yes
数据恢复加载过程就是先按照 RDB 进行加载，然后把 AOF 命令追加写入。
持久化方案的建议
如果 Redis 只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。
如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用 RDB。
通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即 Master 上 RDB、AOF 都不做，保证 Master 的读写性能，而 Slave 上则同时开启 RDB 和 AOF（或 4.0 以上版本的混合持久化方式）来进行持久化，保证数据的安全性。
以上是“Redis 持久化方案的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
向 AI 问一下细节
