7、持久化--AOF日志

1、rdb存储的弊端和解决思路

• rdb存储的弊端：
• 存储数据量较大，效率较低；基于快照思想，每次读写都是全部数据，当数据量过大时，效率非常低
• 大数据量下的IO性能较低
• 基于fork创建子进程，内存产生额外消耗
• 宕机带来的数据丢失风险
• 解决思路：
• 不写全数据，仅记录部分数据
• 降低区分数据是否改变的难度，改记录数据为记录操作过程
• 对所有操作均进行记录，排除丢失数据的风险

2、AOF概念

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

3、AOF写数据过程

4、AOF写数据三种策略

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

5、AOF功能开启

• 功能开启配置

appendonly yes|no

• 作用：是否开启AOF持久化功能，默认为不开启状态
• 写数据策略配置：

appendfsync always | everysec| no

• 作用：AOF写数据策略

6、AOF相关配置

• appendfilename filename
• 作用：AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
• dir 
• 作用：AOF持久化文件保存路径，与RDB持久化文件保持一致即可。

7、AOF重写

• AOF写数据遇到的问题

• AOF重写
• 随着命令不断写入AOF，文件越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个命令执行结果转化成最终结果数据对应的指令进行记录
• AOF重写作用
• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复用时，提高数据恢复效率

8、AOF重写规则

• 进程内已超时的数据不再写入文件(给数据设置有效期的，已经过了有效期的)
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令；如del key1、hdel key2、srem key3、set key4 111、set key4 222等
• 对同一数据的多条写命令合并为一条命令；如lpush list1 a、lpush list1 b、lpush list1 c可以转化为：lpush list1 a b c。为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素。

9、AOF重写方式

• 手动重写

bgrewriteaof

# 举例
127.0.0.1:6380> lpush list2 a
(integer) 1
127.0.0.1:6380> lpush list2 b
(integer) 2
127.0.0.1:6380> lpush list2 c
(integer) 3
# 手动重写
127.0.0.1:6380> bgrewriteaof
Background append only file rewriting started

• 自动重写触发条件设置

auto-aof-rewrite-min-size size # aof_current_size每次要大于此参数的倍数将会触发重写操作
auto-aof-rewrite-percentage percentage # 重写百分比参数（默认百分之百）

• 自动重写触发比对参数（运行指令info Persistence获取具体信息）

# 在redis内部会自动维护以下几个参数：
aof_current_size # 当前aof文件大小
aof_base_size # 上一次执行完重写操纵时的aof文件大小

• 自动重写触发条件

aof_current_size>auto-aof-rewrite-min-size 时将会触发重写，此后每次大于auto-aof-rewrite-min-size整倍数时就会触发一次重写操作
(aof_current_size-aof_base_size)/aof_base_size大于等于auto-aof-rewrite-percentage时将会触发重写

10、AOF手动重写--bgrewriteaof指令工作原理

11、AOF重写流程

• 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失
• 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据
• 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并
• AOF文件直接采用的文本协议，主要是兼容性好，追加方便。可读性高，可认为修改修复。
• 无论是rdb还是AOF都是先写入一个临时文件，然后通过rename完成文件的替换工作。

11、持久化中恢复数据

• 数据的备份、持久化完了，我们如何从这些持久化文件中恢复数据呢？如果一台服务器上既有rdb文件，又有AOF文件，该加载谁呢？
• 其实想要从这些文件中恢复数据，只需要重新启动redis即可
• 恢复数据流程图：

• 启动时会先检查AOF文件是否存在，如果不存在就尝试加载rdb
• 那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据

12、RDB与AOF区别

13、RDB与AOF的选择之惑

• 对数据非常敏感，建议使用默认的AOF持久化方案
• AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据
• 注意：由于AOF文件存储体积较大，且恢复速度较慢
• 数据呈现阶段有效性，建议使用RDB持久化方案
• 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的)，且恢复速度较快，阶段点数据恢复通常采用RDB方案
• 注意：利用RDB实现紧凑的数据持久化会使redis降的很低，慎重总结
• 综合比对：
• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
• 灾难恢复选用RDB
• 双保险策略，同时开启RDB与AOF，重启后，Redis优先使用AOF来恢复数据，降低丢失数据的量

14、持久化场景应用