Redis持久化机制

Redis持久化机制

​ 我们知道redis是一种基于内存的数据库,一旦系统宕机,redis保存在内存中的数据就会全部丢失,。如果仅仅是将reids作为数据库的缓存来使用的情况,我们还可以将数据重新加载到redis, 不会有太大的影响, 对于将redis作为数据库来使用的情况,数据丢失就会引发生产问题。

Redis的两种持久化方式

一、RDB

RDB 即快照方式，它将某个时间点的所有 Redis 数据保存到一个经过压缩的二进制文件中, 是Redis默认采用的持久化机制。

RDB方式的优点

• 恢复大数据集时，RDB 比 AOF 更快, 因为其二进制保存的形式更加紧凑。

缺点

• 如果系统发生故障，将会丢失最后一次创建快照之后的数据。
• 如果数据量很大，保存快照的时间会很长。

触发方式

• save命令
  save本身是单线程串行方式执行，因此当数据量大时，可能会发生Redis Server的长时间卡顿。

• bgsave命令
  bgsave命令在执行时，会fork一个子进程。子进程提交完成后，会立即给客户端返回响应，备份操作在后台异步执行，期间不会影响Redis的正常响应。对于bgsave来说，当父进程Fork完子进程之后，异步任务会将当前的内存状态作为一个版本进行复制 在复制过程中产生的变更，不会反映在这次备份当中。

• 定时任务触发
  Redis 允许用户通过设置服务器配置的 save 选项，让服务器每隔一段时间自动执行保存快照命令。
  Redis的默认配置:
  save 900 1 900秒内,至少对数据库进行了1次修改
  save 300 10 300秒内,至少对数据库进行了10次修改
  save 60 10000 60秒内,至少对数据库进行了10000次修改
  只要满足上面任一个条件,服务器就会执行bgsave命令生成快照

二、AOF(Append Only File)

将所有修改类的命令以文本日志的形式记录到文件中, 以此来记录数据的变化过程。当服务器重启时，重新执行一遍 AOF 文件中的命令，就可以恢复原始的数据。

开启方式: 通过 appendfsync yes配置来开启AOF持久化机制。

Redis并不是每有一条更新类的命令就会将其写入到AOF文件中, 命令会先进入到AOF缓冲区(内存中), Redis每隔一定的时间将其追加到AOF文件中。可以通过appendfsync配置写入文件的时间间隔。

持久化配置:

• appendfsync always 每有一条命令就写入到AOF文件中, 这种方式性能很差,生产环境一般不使用这种方式。
• appendfsync ererysec 每隔1秒钟,Redis将缓冲区中的命令追加到AOF文件中, 也是AOF机制下,Redis的默认方式。生产环境中一般采用这种方式。
• appendfsync no 由操作系统决定不定时地将缓冲区中的内容同步到AOF文件, 不推荐这种方式。

AOF 的优缺点

• 如果系统发生故障，AOF 丢失数据比 RDB 少, 如在默认每1秒同步一次的情况下,最多损失一秒的数据。
• 恢复大数据集时，AOF 比 RDB 慢。

AOF重写

Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时。

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其 原理 就是 开辟一个子进程 对内存进行 遍历 转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的 增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了

备份的载入

当Redis重启时会自动载入备份文件进行数据恢复, 当rdb文件和aof文件同时存在时,会优先使用aof文件进行数据恢复, 因为大多数情况下aof文件的数据要比rdb文件更为完整。

​