Redis持久化AOF

卑微小吴励志写博客第27天。

RDB的弊端

• 存储数据量大，效率较低。快照思想是全量存储数据，这样效率较低。
• 大数据量下的IO性能较低。
• 基于fork创建子线程，内存产生额外消耗。
• 宕机带来的数据丢失风险。

解决思路：

• 不写全数据，记录部分数据。
• 改记录数据为操作记录，操作过程。
• 对所有的操作进行记录，防止数据丢失的风险。

AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每条写命令，重启的时候再执行命令，达到回复数据的目的。与RDB相比简单来讲就是：改记录数据为记录数据产生的过程。
• AOF主要作用是解决了数据持久化的实时性，目前已经是redis持久化的主流方式。

AOF写数据的过程

三种策略：

• always（每次）
  每次写入操作均同步到AOF文件中，数据零误差，性能较低。不建议使用

• everysec（每秒）
  每秒将缓存区中的指令同步到AOF文件中，数据准确性较高，性能也较高。建议使用，也是默认配置。
  在系统突然宕机的情况下丢失1秒内的数据。

• no（系统控制）
  由操作系统控制每次同步AOF文件的周期，整个过程不可控。

AOF功能开启

• 配置
  appendonly yes|no
• 作用
  是否开启AOF持久化功能，默认为不开启状态。
• 配置
  appendfsync always|everysec|no
• 作用
  AOF写数据策略
• 配置
  appendfilename filename
• 作用
  AOF持久化文件名，默认文件名为appendonly.aof，建议配置为append-端口号.aof
• 配置
  dir
• 作用
  AOF持久化的保存路径

AOF写数据遇到的问题

遇到连续一样的指令，没必要全部都记录，AOF提供上图中优化的策略。

AOF重写

随着命令不断写入，文件大小也不断增大，AOF提供了重写机制压缩文件体积。AOF重写是将Redis进程中的数据转化为写命令同步到新的AOF文件中的过程。简单的说就是将同一条数据的若干条命令执行的结果转化为最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率。
• 提高持久化效率，降低持久化写时间，提高IO性能。
• 降低数据恢复用时，提高数据恢复效率。

AOF重写规则

AOF重写指令

AOF手动重写-bgrewriteaof工作原理

AOF自动重写方式

AOF工作流程

AOF重写流程

RDB与AOF的区别

RDB与AOF选择

持久化的应用场景

redis是否用持久化根据业务来定，自行权衡。一般很重要的可以考虑持久化。

不经一番彻骨寒，怎得梅花扑鼻来。加油，小伙伴们！！！