Redis 持久化

Redis有两种持久化方式 RDB和AOF

需要注意：数据的恢复是阻塞操作（此间所到来的任何客户端读写请求都失效）

 

一. RDB 快照（默认）

1.优缺点

• 执行机制：快照，直接将database中key-value的二进制形式存储到RDB文件中
• 优点：性能较高（因为是快照，且执行频率比AOF低，而RDB中直接存储的key-value的二进制形式，对于恢复数据也快）
• 缺点：在Save配置条件之前宕机，此间数据会丢失

2. 主要触发方式（三种）：

• Save命令（同步数据到磁盘上）
• BGSave命令（异步保存数据到磁盘上，主从同步使用此种机制）
• 自动生成RDB

通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。

比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动进行数据集保存操作:

二. AOF文件

1. 优缺点

• 执行机制：将对数据的每一条增删改命令追加到AOF文件中
• 优点：数据不容易丢失
• 缺点：性能较低（每一条增删改操作都要追加到AOF文件，执行频率比RDB要高，而且AOF文件中存储的是命令，所以回复慢）

2.AOF持久化的三种策略

可以通过配置文件配置 Redis 多久才将数据 fsync 到磁盘一次。

• always: 每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
• everysec: 
  • 每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
  • 推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
• no: 将数据交给操作系统来处理，由操作系统来决定什么时候同步数据。更快，也更不安全的选择。

 always、everysec、no对比

命令	优点	缺点
always	不丢失数据	IO开销大，一般SATA磁盘只有几百TPS
everysec	每秒进行与fsync，最多丢失1秒数据	可能丢失1秒数据
no	不用管	不可控

 

三、RDB-AOF混合持久化

简介

redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混合持久化方式。前面已经详细介绍了AOF持久化以及RDB持久化，这里介绍的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。

开启混合持久化

4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。

混合持久化过程

了解了AOF持久化过程和RDB持久化过程以后，混合持久化过程就相对简单了。

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：

数据恢复

当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：

• aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
• aof文件开头不是rdb的格式，直接以aof格式加载整个文件。