Redis学习笔记12----持久化(AOF)

RDB存储的弊端

• 存储数据量较大，效率较低；基于快照思想，每次读写都是全部数据，当数据量很大时，效率会很低
• 大数据量下的IO性能很低
• 基于fork创建子进程，产生额外的消耗
• 宕机带来数据丢失风险

解决思路

• 不写全数据，仅记录部分数据
• 改记录数据为记录操作过程
• 对所有操作均进行记录，排除丢失数据的风险

AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每次命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的，与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF主要作用是解决数据持久化的实时性问题，目前已经是Redis持久化的主流方式

AOF写数据过程

将命令同步到AOF文件中的问题：1. 一次写几条；2. 多久写一次

AOF写数据的三种策略

• always：每次写入操作均同步到AOF文件中，数据零误差，性能较低
• everysec（默认）：每秒将缓冲区的指令同步到AOF文件中，数据准确性较高，性能较高 ，在系统突然宕机的情况下会丢失1秒的数据
• no(系统控制)：由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启

• 配置AOF开启

 appendonly yes | no
 # 默认为no

• 配置AOF策略

appendfsync always | everysec | no

• 配置文件名

appendfilename filename
# 默认为appendonly.aof
# 建议配置为appendonly-端口号.aof

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF文件重写机制压缩AOF文件。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单来说就是将对同一个数据操作的若干条命令执行结果转化为最终结果数据对应的指令进行记录。

AOF重写的作用

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

AOF重写规则

• 进程内已经超时的数据不在写入AOF文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样AOF文件只保留最终数据的写入命令
• 对同一数据的多条写命令合并为一条命令。为防止数据量过大，造成客户端缓冲区溢出，对list，hash，set，sorted_set等类型，每条指令最多写入64个