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

  • RDB 是将Redis的内存数据生成一份快照保存在dump.rdb二进制文件中
  • AOF是将每一次执行的修改命令都以追加写入的方式写入appendonly.aof文件中

RDB是redis的默认持久化方式,可以配置持久化策略:save N M,表示N秒内至少M个改动则会触发一次RDB操作,RDB持久化的时候不会阻塞Redis的读写请求,因为Redis从主线程中fock出一个子线程bgsave,可以共享主线程中的数据,当读取redis内存数据时,主线程的读请求不受影响,当写请求时,会借助写时复制技术,将该写请求会操作的数据拷贝一份出来写入dump.rdb,这样主线程可以继续处理写请求

RDB的优缺点:

优点:

dump.rdb是二进制文件,可以很快用于数据恢复

缺点:

  1. 如果redis宕机的话,会丢失上一次RDB同步到宕机之间的数据
  2. RDB 需要将内存的数据都写入到dump.rdb,如果频繁执行的话,开销比较大,影响性能

AOF是同步地将修改写入到appendonly.aof,能最大限度地减少数据丢失的风险,为什么说是最大限度而不是完全避免呢?先看ROF的刷盘策略:

  1. appendfsync always 每次执行命令都刷盘
  2. appendfsync everysec 每秒刷盘一次
  3. appendfsync no 由系统决定什么时候刷盘

当修改命令写入到文件缓存后,需要将缓存刷到磁盘才能真正完成持久化,所以如果刷盘策略不是第一种,则可能丢失短时间内的数据。

AOF重写,因为ROF持久化的是命令而不是具体数据,所以可能有一些命令是重复的,redis有一个机制称为bgrewriteof,用于生成新的aof文件。

比起RDB,ROF还是有一个缺点,就是重放命令来恢复数据效率太低了,Redis 4.0版本为了解决这个问题,提供了混合持久化方案:

在AOF重写时,执行一次RDB,加上增量AOF一起写入到appendonly.aof,这样在恢复数据时,就可以先将RDB恢复,再重放AOF,重启效率提高。

标签: none

添加新评论