Rdb存储的弊端
- 存储数据量较大，效率较低（基于快照思想，每次读写都是全部数据，当数据量巨大，效率非常低）
- 大数据量下的IO性能较低
- 基于fork创建子进程，内存产生额外消耗
- 宕机带来的数据丢失风险
解决思路
- 不写全数据，仅记录部分数据
- 改记录数据未记录操作过程
- 对所有操作均进行记录，排除丢失数据的风险
AOF概念
- AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的，与rdb相比可以简单描述为记录数据为记录数据产生的过程
- AOF的主要作用是解决了数据持久化的实时性，目前已经是redis持久化的主流方式
AOF写数据过程
从aof写命令刷新缓存区多久同步到aof，每次同步多少条
以下有三种策略
aof写数据三种策略（appendfsync）
- Always（每次）
每次写入操作均同步到aof文件中，数据零误差，性能较低，不建议使用
- Everysec（每秒）
每秒将缓冲区中的指令同步到aof文件中，数据准确性较高，性能较高，建议使用，也是默认配制在系统突然宕机的情况下丢失1秒内的数据
在系统突然宕机的情况下丢失1秒内的数据
- No（系统控制）
由操作系统控制每次同步到aof文件的周期，整体过程不可控
AOF功能开启
配置
appendonly yes|no
作用
是否开启aof持久化功能，默认为不开启状态
配置
appendfsync always|everysec|no
作用
aof写数据策略
如下为配置文件示例：
AOF相关配置
配置
appendfilename filename
作用
aof持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
配置
dir
作用
aof持久化文件保存路径，与rdb持久化文件保存一致即可
Aof写数据遇到的问题
如果连续执行如下指令
我们会看到有很多重复且没必要保存的指令，name最后为ww，num最后为3，有很多冗余数据，那么有没有一种方案优化呢？
Aof重写
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，redis引入了aof重写机制压缩文件体积，aof文件重写是将redis进程内的数据转化为写命令同步到新aof文件的过程。简单说就是将对同一个数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录。
AOF重写作用
降低磁盘占用量，提高磁盘利用率
提高持久化效率，降低持久化写时间，提高IO性能
降低数据恢复用时，提高数据恢复效率
AOF重写规则
- 进程内已超时的数据不再写入文件
- 忽略无效指令，重写时使用进程内数据直接生成，这样新的aof文件只保留最终数据的写入命令，如del key1,hdel key2,srem key3,set key4 111,set key5 222等
- 对同一数据的多条写命令合并为一条命令
如lpush list1 a,lpush list1 b,lpush list1 c可以转化为：lpush list1 a b c。
为防止数据量多大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素。
AOF重写方式
- 手动重写
bgrewriteaof
自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
AOF手动重写--bgrewriteaof指令工作原理
AOF自动重写方式
- 自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
自动重写触发比对参数（运行指令info persistence获取具体信息）
aof_current_size
aof_base_size
自动重写触发条件
aof_current_size>auto-aof-rewrite-min-size
aof_current_size-aof_base_size/aof_base_size>=auto-aof-rewrite-percentage
Aof工作流程
将上图进一步深入，内部都干了啥，如下图：
