Redis 是内存数据库,支持持久化,将内存中的数据些到磁盘中,防止服务器宕机内存数据丢失。一种 RDB 方式、一种 AOF 方式,一般两种结合使用。
1. RDB(Redis DateBase)
1.1. 什么是 RDB
RDB 是 redis 默认的持久化方案。持久化时将内存数据写入磁盘,指定目录下生成 dump.rdb 文件,重启时通过 dump.rdb 把数据加载到内存,一旦 redis 异常退出会丢失最近一次持久化后更改的数据。
1.2. bgsave 触发 RDB 持久化:
- 执行
BGSAVE
命令 - 父进程检测到当前有子进程在执行
bgsave
就返回线程已存在,会忽略掉这个新的请求。 - 不存在,执行
fork
操作创建一个子进程,期间父进程被阻塞。 - 父进程继续处理客户端请求,子进程在磁盘上创建一个新的临时文件保存内存数据。
- 子进程数据写完之后关闭临时文件,替换掉旧的 RDB 文件。
- 替换完成通知父进程,保存完成。
- 替换过程是原子性操作,失败会保留旧文件。
1.3. 触发 RDB 的方式:
- 手动触发:有
SAVE
和BGSAVE
命令。SAVE
执行快照的过程阻塞所有客户端请求,避免使用这种方式。BGSAVE
可以在后台异步进行快照操作,不阻塞客户端请求。手动快照推荐使用BGSAVE
命令。 - 被动触发:
- 在配置文件(
redis.conf
)中设置自动快照,默认 900 秒内有 1 个更改操作,就同步save 900 1
。 - 从节点执行全量复制操作,主节点自动执行
BGSAVE
生成 RDB 文件发送给从节点。 - 默认情况下执行
shutdown
,没有开启 AOF 会自动执行BGSAVE
。
1.4. 优点及缺点
优点:
- Redis 加载 RDB 恢复数据远远快于 AOF 的方式。
- 使用单独子进程来进行持久化,主进程不会进行任何 IO 操作,保证了 Redis 的高性能。
缺点:
- RDB方式数据无法做到实时持久化。因为BGSAVE每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本比较高。
- RDB 文件使用特定二进制格式保存,Redis 版本升级过程中有多个格式的 RDB 版本,存在老版本 Redis 无法兼容新版 RDB 格式的问题。
2. AOF(Append Only File)
以独立日志的方式记录每次写命令,Redis重启时会重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,AOF 是Redis持久化的主流方式。
默认不开启,通过 (redis.conf 配置文件)appendonly
参数启用:appendonly yes
。开启AOF方式持久化后每执行一条写命令,Redis就会将该命令写进aof_buf缓冲区,AOF缓冲区根据对应的策略向硬盘做同步操作。
默认情况下系统每30秒会执行一次同步操作。为了防止缓冲区数据丢失,可以在Redis写入AOF文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过appendfsync参数设置同步的时机。
2.1. AOF 相关参数
appendonly yes:启用 AOF 持久化(默认关闭)。
appendfsync:定义 AOF 文件的同步策略。常见的选项包括:
- always:每次写操作后同步(性能最差但数据安全性最高)。
- everysec:每秒钟同步一次(默认选项,平衡了性能和数据安全性)。
- no:由操作系统决定何时同步(性能最好但数据安全性最低)。
2.2. AOF 执行流程
- 所有的写入命令会追加到 AOF 缓冲区中。
- AOF 缓冲区根据对应的策略向硬盘同步。
- 随着 AOF 文件越来越大,需要定期对 AOF 文件进行重写,达到压缩文件体积的目的。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程
- 当 Redis 服务器重启时,可以加载 AOF 文件进行数据恢复。
2.3. 优缺点
优点:
- AOF可以更好的保护数据不丢失,可以配置 AOF 每秒执行一次fsync操作,如果Redis进程挂掉,最多丢失1秒的数据。
- AOF以追加(append-only)的模式写入,所以没有磁盘寻址的开销,写入性能非常高。
缺点:
- 对于同一份文件AOF文件比RDB数据快照要大。
- 数据恢复比较慢。
3. RDB 和 AOF 如何选择?
应该同时使用两种持久化方案来保证数据安全。
- 数据不敏感,且可以从其他地方重新生成,可以关闭持久化。
- 数据比较重要,能够承受几分钟的数据丢失,比如缓存等,只用RDB即可。
- 用做内存数据,要使用Redis的持久化,建议是RDB和AOF都开启。
- 只用AOF,优先使用everysec的配置选择,因为在可靠性和性能之间取了一个平衡。