Redis（二）

1. Redis 持久化有几种方式？

RDB（Redis DataBase）：能在指定的时间间隔对你的数据进行快照存储（全量备份）
手动触发有save命令和bgsave命令

• save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它
• bgsave命令：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave。
  RDB持久化之bgsave运行流程.png
  优点：1. 压缩后的二进制文件适用于备份、全量复制、用于灾难恢复
  2. 加载RDB恢复数据远快于AOF方式
  缺点：1. 无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
  2. 保存后的二进制文件存在老版本不兼容新版本rdb文件的问题

AOF（Append Only File）：每收到一个写命令都通过write函数追加到文件中

流程：

1. 所有的写入命令(set hset)会append追加到aof_buf缓冲区中。
2. AOF缓冲区向硬盘做sync同步。
3. 随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩。
4. 当redis服务重启，可load加载AOF文件进行恢复。
   AOF持久化流程.png

优点：

1. AOF可以更好的保护数据不丢失
2. AOF日志文件以append-only模式写入，写入性能比较高
3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写
4. 适合做灾难性的误删除紧急恢复

缺点：
1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大，恢复速度慢
2.AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

2. Redis重启时加载AOF与RDB的顺序

1. 当AOF和RDB文件同时存在时，优先加载AOF。
2. 若关闭了AOF，加载RDB文件。
3. 加载AOF/RDB成功，redis重启成功。

4. AOF/RDB存在错误，启动失败打印错误信息。

   
   redis重启时加载AOF与RDB的顺序.png