redis持久化方式

RDB

• 快照式持久化。

SAVE

• 阻塞redis主进程，直到RDB创建完成。
• 手动触发。

BGSAVE

• fork子进程。子进程创建RDB文件，主进程继续处理请求。
  • 子进程共享父进程的内存空间，该空间只读。
  • 父进程修改时，对应的内存页copyonwrite，修改复制之后的内存页。
• 只会同时执行一个BGSAVE命令。
• 可手动触发，也可以设置多个save条件，任意满足时执行bgsave持久化。
  • save 900 1： 900s内对数据库进行至少1次修改。

还原

• 从RDB还原时服务器一直阻塞。

AOF

• 追加式持久化,Append Only File。

写入

• 写入时机：
  1. 处理文件事件。追加写请求到aof_buf缓冲。
  2. 处理时间事件。
  3. 判断是否需要从aof缓冲刷到文件。appendfsync。
• appendfsync的值
  • always：每个事件循环中同步写AOF文件。最多丢失一条命令的数据，安全性最高。
  • everysec：子线程每秒写文件。
  • no：操作系统决定写文件时机。单次写入效率最高。

还原

• 在伪客户端中一条条分析并执行AOF文件中的命令。

AOF重写

• 子进程执行，生成新的AOF文件，减少恢复时间和储存空间。
  • 追加式存储压缩硬盘空间的通解
• 无需读写现有的AOF文件。
• 步骤：
  • 类似BGSAVE fork子进程，和父进程共享只读内存空间。
  • 遍历内存空间中所有未过期的key。
  • 根据类型和当前值重写命令，如String->SET
  • 重写过程中的命令双写缓冲：
    
  • 完成重写之后调用信号处理函数，刷新重写缓冲区。
  • 新的AOF改名覆盖原有的AOF文件。

对比

• AOF更新频率高，服务器启动时，优先使用AOF恢复，如AOF关闭才使用RDB。

RDB特点

快照：压缩率高

• 优点：
  • 压缩过的文件，恢复数据较快，适合做备份和灾难恢复。
  • 主进程无影响。可fork子进程持久化。
• 缺点：
  • 安全性不够。需要保存全量数据，频率不高，宕机丢数据较多。
  • 子进程消耗额外的CPU和时间，特别是数据集较大的时候。

AOF特点

追加：安全性高

• 优点：
  • 数据更完整，安全性更高。取决于appendfsync的值。
  • 追加式操作，适合增量的紧急恢复。
• 缺点：
  • 文件体积较大，恢复时间长。

使用方式

• 核心业务不建议使用redis持久化
  • rdb持久化占用实例cpu和内存资源，间接影响主进程，并且持久化进度滞后较多。
  • aof持久化直接延长主进程处理流程，并且没有采用WAL有丢数据风险。
• 探索性业务可考虑使用redis持久化做存储
  • 依赖组件种类少。运维、开发成本低
• 替代方案：redis+持久化存储（mysql、hbase）