J2 Redis之 AOF＆RDB

AOF

不阻塞当前的命令，但是会阻塞下一个命令，还没记日志就宕机 存在丢失的可能

三种写回策略

AOF appendfsync的三种策略

• Always，每次写命令执行完，立马写会磁盘（基本不丢数据，影响性能）
• Everysec，每秒写回，先将日志写入AOF文件缓冲区，每隔一秒写入磁盘（可能会缺失一秒的数据）
• No 将写操作执行完，将日志放入缓冲区，由操作系统决定何时写入（性能比较好，丢失数据可能性极大）
  

AOF文件会不断变大，恢复的话也会慢，就需要AOF重写机制（保存键值对最新的数据，不需要保存旧命令）

• AOF重写不会阻塞主线程，由后台线程 bgrewriteaof 来完成。
• 一个拷贝（主线程fork出bgrewriteaof 子进程），两处日志（此时任然可以执行新操作，写入AOF日志和重写日志缓存，不会丢失最新操作）
  

RDB

• 相比AOF恢复的比较快，执行的是全量备份
• 提供两个命令生成RDB，save（主线程执行，会阻塞）和bgsave（子线程写入RDB文件）
• bgsave的时候，通过写时复制技术（copy-on-write）可以执行写操作（bgsave由主线程fork生成，可以共享主线程数据）
  
  频繁执行全量快照会导致：1.磁盘压力大，前面还没执行完 后面又开始做了，2. fork过程会导致阻塞主线程

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法，两次快照之间使用AOF。

• 数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
• 如果允许分钟级别的数据丢失，可以只使用 RDB；
• 如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个
  平衡。