Redis 持久化

RDB持久化

* RDB 持久化是将内存中的数据以类似数据库数据的格式写入硬盘的一种方式，可以通过手动或被动进
  行触发

* 手动触发是通过 redis-cli 执行 BGSAVE 或 SAVE 命令，redis 收到后会执行响应的操作

* save 和 bgsave 都可以出发 RDB 持久化，区别如下：
    save 会阻塞 redis 服务器，内存较大的 redis 实例会被长时间阻塞
    bgsave 会 fork 一个子进程，持久化由子进程完成，阻塞 redis 实例只发生在 fork 阶段

* 被动触发是 redis 通过检查是否达到配置文件中的持久化要求，达到要求时会由 redis 
  自动执行与 BGSAVE 类似的过程

* 当多次进行 RDB 持久化时，redis 会在原有的 .rdb 文件的基础上进行追加，而不额外产生新的文件

* 恢复数据时，应在数据载入 redis-server 之前使用 redis-check-rdb 进行检查，检查无误后再
  载入 redis-server 中

* RDB 持久化在数据量大的情况下备份或恢复时会占用较多的 CPU 和内存资源，另外，RDB 持久化
  是定期的，不是实时的，宕机存在较大的数据丢失的风险

* 其他
    - 当从节点执行全量复制时，主节点会自动执行 bgsave 生成 rdb 文件
    - 执行 shutdown 命令时，如果没有开启 aof 持久化功能则自动执行 bgsave

* 在持久化的过程中若遇到了磁盘发生故障或写满的情况须立即通过 config set dir {dir} 修改文件
  路径到可用的磁盘路径上

* redis 默认对 rdb 文件使用 lzf 算法进行压缩处理，默认开启，可通过 config set rdbcompression no
  进行关闭

* 为什么要对 rdb 文件进行压缩？
    - 节约空间
    - 节约带宽

* 一种便于理解的触发 BGSAVE 的条件
if TIME(NOW)-LAST(TIME(BGSAVE)) <= 900 and operation(key) > 1
    then BGSAVE
if TIME(NOW)-LAST(TIME(BGSAVE)) <= 300 and operation(key) > 10
    then BGSAVE
if TIME(NOW)-LAST(TIME(BGSAVE)) <= 60 and operation(key) > 10000
    then BGSAVE

* rdb 持久化触发条件是不是越容易越好？
    rdb 会 fork 子进程，虽然相较阻塞 redis 实例来说十分轻量，但其实际上却是一个总量级的操作
    不应频繁的触发

AOF 持久化

* AOF 持久化是将内存中的数据以命令的格式写入磁盘的一种持久化方式，该方式只能通过配置文件自动触发

* AOF 持久化默认不开启可通过 appendonly yes 进行开启
* AOF 文件名通过 appendfilename 进行设置，默认文件名为 appendonly.aof

* AOF 持久化过程：
    - 将命令追加到内存缓冲区中
    - 将缓冲区的命令和磁盘文件文件进行同步
    - 若文件过大进行重写

* AOF 持久化共有三种同步策略，同步策略控制了持久化的频率，可用通过 appendsync 进行设置：
    * NO 由 OS 进行同步
    * ALWAYS 每次写操作调用一次 fsync
    * EVERYSECOND 每秒进行一次 fsync

* 如何选择持久化策略？
    - 当同步频率为 NO 时，AOF 持久化依赖于 OS 的刷写策略，性能最高但风险也高，无法对 RDB 做出
      补充
    - 当同步频率为 ALWAYS 时，redis 会对每一个命令进行持久化，安全性最高但开销也大
    - 当同步频率为 EVERYSECOND 时，redis 每秒进行一次 AOF 持久化，可用满足大多数业务的需要

* 为了避免 AOF 文件过大应使用 auto-aof-rewrite-percentage 100 和 
  auto-aof-rewrite-min-size 64mb 对 AOF 文件进行重写

* 为什么 redis 开启 AOF 持久化后 redis 主目录下没有 appendonly.aof 文件
    重新启动服务器