redis专题十：redis持久化（下）

上一篇主要描述了RDB。这一篇将描述AOF。

简单回顾一下RDB存储的弊端：

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

解决思路：

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

这就是AOF。

一、AOF基本概念

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

二、AOF写数据的过程

2.1 AOF原理

当有操作指令过来的时候，redis将命令放在命令刷新缓存区，达到一定量的时候，再将命令写入到.aof的文件中去。

2.2 AOF读写数据的策略

 问题：那么缓存区达到什么程度，会触发写文件呢？一次写多少呢？

 解答：AOF写数据的三种策略

• always （每次）   --> 每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用
• everysec （每秒）--> 每秒将缓存区中的指令同步到AOF文件中，数据准确性较高，性能较高；在系统宕机的情况下丢失一秒的数据
• no （系统控制）   --> 由操作系统控制每次同步到AOF文件的周期，整体过程不可控。

2.2.1 AOF功能开启

• 配置：appendonly yes/no
• 作用：是否开启AOF持久化的功能，默认不开启
• 配置：appendfsync always/everysec/no

2.3 AOF重写策略

2.3.1 基本介绍

比方说连续执行如下指令：在恢复的时候，还要执行这样的6条指令，显得没有任何意义。因为像前面三条set，只有最后一个有意义，那么就需要将指令进行合并。

 也就是说，随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。

 AOF重写是将redis进程内的数据转换为写命令同步到新AOF文件的过程，也就是将同一个数据的若干条命令执行结果转换为最终结果数据对应指令进行记录的过程。

 2.3.2 AOF重写的作用

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

2.3.3 AOF重写规则

• 进程内超时的数据不再写入文件
• 忽略无效指令（比方说get，获取数据不对数据产生影响），重写时使用进程中的数据直接生成，这样新的AOF文件只保留最终数据的写入命令
• 对同一数据的多条写指令合并为一条指令，同时为了防止数据量过大造成的缓冲区溢出，对list, set , hash, zset等类型，每条指令最多写入64个元素

2.3.4 AOF重写方式

2.3.4.1 手动重写 

指令：bgrewriteaof

原理：类似bgsave来看。

2.3.4.2 自动重写   

自动重写触发条件设置

• auto-aof-rewrite-min-size size       自动重写AOF的最小尺寸，参考比对值：aof_current_size
• auto-aof-rewrite-percentage percentage  自动重写的百分比：参考比对值：aof_base_size

自动触发的条件：

这两个参考比对值我们可以通过info命令查看。

2.3.5 AOF重写过程

相对于前面我们说的bgrewriteaof，在重写的时候会有一个重写缓存区，重写后的文件会替换掉原来的老的aof文件。

 三、RDB和AOF对比

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会数据丢失	依据策略而定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

四、RDB和AOF的选择

• 对数据非常敏感，建议使用默认的AOF方案
• 数据呈现阶段性有效性，建议使用RDB
• 灾难恢复选择RDB
• 双保险策略，同时开启，重启后，redis优先使用AOF恢复数据，降低丢失数据的数量

这一篇就到这里，下一篇写redis的事务。