Redis的持久化方案.pdf（两种持久化方案：RDB 和 AOF，共15页）
140 浏览量
2024-05-15
11:06:21
上传
评论
收藏 534KB PDF 举报
Redis 数据持久化
总的来说有两种持久化方案：RDB 和 AOF
RDB 方式按照一定的时间间隔对数据集创建基于时间点的快照，是默认的持久化方式。可理解为半持久化模式，即
按照一定的策略周期性的将数据保存到磁盘。
AOF 方式记录 Server 收到的写操作到日志文件，在 Server 重启时通过回放这些写操作来重建数据集。该方式类似于
MySQL 中基于语句格式的 binlog。当日志变大时 Redis 可在后台重写日志。若仅期望数据在 Server 运行期间存在则
可禁用两种持久化方案。在同一 Redis 实例中同时开启 AOF 和 RDB 方式的数据持久化方案也是可以的。该情况下
Redis 重启时 AOF 文件将用于重建原始数据集，因为叫 RDB 方式而言，AOF 方式能最大限度的保证数据完整性。
两钟方案各自的优缺点
RDB
优点
RDB 是 Redis 数据集的基于时间点的紧凑的副本，非常适合于备份场景。比如每个小时对 RDB 文件做一次小的归档，
每天对 RDB 文件做一次大的归档，每月对 RDB 文件做一次更大的归档。这样可以在必要的时刻选择不同的备份版本
进行数据恢复。同时，Redis 的 RDB 文件也是 Redis 主从同步内部实现中的一环。
第一次 Slave 向 Master 同步的实现是：
Slave 向 Master 发出同步请求，Master 先 dump 出 rdb 文件，然后将 rdb 文件全量传输给 slave，然后 Master 把缓
存的命令转发给 Slave，初次同步完成。
第二次以及以后的同步实现是：
Master 将变量的快照直接实时依次发送给各个 Slave。
但不管什么原因导致 Slave 和 Master 断开重连都会重复以上两个步骤的过程。由于是一个紧凑的文件，易于传输到
远程数据中心或 Amazon S3，因此 RDB 非常适合于灾难恢复。RDB 方式的开销较低，在该种方式下 Redis 父进程
所要做的仅是开辟一个子进程来做剩下的事情。与 AOF 相比 RDB 在数据集较大时能够以更快的速度恢复。RDB 的
启动时间会更短，原因有两个：
一是 RDB 文件中每一条数据只有一条记录，不会像 AOF 日志那样可能有一条数据的多次操作记录。所以每条数据只
需要写一次就行了。另一个原因是 RDB 文件的存储格式和 Redis 数据在内存中的编码格式是一致的，不需要再进行
数据编码工作，所以在 CPU 消耗上要远小于 AOF 日志的加载。
RDB
缺点
若需在 Redis 停止工作时（例如意外断电）尽可能保证数据不丢失，那么 RDB 不是最好的方案。例如，通常会每隔
5 分钟或者更长的时间来创建一次快照，如若 Redis 没有被正确的关闭就可能丢失最近几分钟的数据。
RDB 方式需经常调用 fork()函数以开辟子进程来实现持久化。在数据集较大、CPU 性能不够强悍时 fork()调用可能很
耗时从而会导致 Redis 在几毫秒甚至一秒中的时间内不能服务 clients。AOF 也需要调用 fork()但却可以在不影响数据
持久性的条件下调整重写 logs 的频率。
AOF
优点
使用 AOF 方式时 Redis 持久化更可靠：有三种不同的 fsync 策略供选择：no fsync at all、fsync every second、
fsync at every query。默认为 fsync every second 此时的写性能仍然很好，且最坏的情况下可能丢失一秒钟的写操作。
AOF 日志是 append only 方式产生的日志，因此不存在随机访问问题以及意外断电时造成的损毁问题。即使出于某种
原因（如磁盘满）日志以一个写了一半的命令结尾，仍可以使用 redis-check-aof 工具快速进行修复。
当 AOF 日志逐渐变大后，Redis 可在后台自动的重写 AOF 日志。当 Redis 在继续追加旧的 AOF 日志文件时重写日
志是完全安全的。Redis 利用可以重建当前数据集的最少的命令产生一个全新的日志文件，一旦新的日志文件创建完
成 Redis 开始向新的日志文件追加日志。
AOF 日志的格式易于理解易于解析。这在某些场景非常有用。比如，不下心使用 FLUSHALL 命令清空了所有的数据，
剩余14页未读，继续阅读
资源评论
