1. 持久化介绍

  • Redis 的数据存在在内存中，如果没有配置持久化，redis 重启后数据就全丢失了，于是需要开启 redis 的持久化功能，将数据保存到磁盘上，当 redis 重启后，可以从磁盘中恢复数据。

image.png

2. 持久化的方式

  • RDB 持久化：RDB 持久化能够在指定的时间间隔对你的数据进行快照存储。
  • AOF（append only file）持久化：AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

3. RDB 持久化方式

1. 操作方式

  • 客户端直接通过命令 BGSAVE 或者 SAVE 来创建一个内存快照。
    • BGSAVE 调用 fork 来创建一个子线程，子线程负责将快照写入磁盘，而父进程仍然继续处理命令。
    • SAVE 执行 SAVE 命令过程中，不再响应其他命令。

  • 在 redis.conf 中调整 save 配置选项，当在规定的时间内，Redis 发生了写操作的个数满足条件，会触发 BGSAVE 命令。

    1. # 900 秒之内至少一次写操作
    2. save 900 1
    3. # 300 秒之内至少发生 10 次写操作
    4. save 300 10
    5. # 60 秒之内至少发生 10000 次写操作
    6. save 60 10000

  • save 5 2：每 5 秒检查一次，只要在连续的检查中出现2次操作，就可以发出。比如 1 秒的时候，做了一次写操作，第 10 秒的时候又进行了一次写操作，是可以出发 BGSAVE 命令的。

2. 优点和缺点

优点 缺点
对性能影响最小。 同步时丢失数据。
RDB 文件进行数据恢复比使用 AOF 要快很多。 如果数据集非常大且 CPU 不够强（比如单核 CPU），Redis 在 fork 子进程时可能会消耗相对较长的时间，影响 Redis 对外提供服务的能力。

4. AOF 持久化方式

1. 开启 AOF 持久化

appendonly yes
  • 相关的修改还有 appendfilename、appendfsync 。

2. AOF 策略调整

  • 每次有数据修改发生时都会写入 AOF 文件 appendfsync always 。
  • 每秒钟同步一次，该策略为 AOF 的缺省策略 appendfsync everysec 。
  • 从不同步。高效但是数据不会被持久化 appendfsync no 。

3. 优点和缺点

优点 缺点
最安全。 文件体积大。
容灾。 性能消耗比 RDB 高
易读，可修改。 数据恢复速度比 RDB 慢。