Redis中AOF操作

概念

• AOF=Append Only File,把所有操作都记录下来，恢复的时候，全部操作再执行一遍。
  有点像MySQL的binlog，实时性更好，丢失的数据更少

具体原理

以日志形式记录每个操作，将Redis所有执行过的命令记录下来（读操作不记录），只许追加文件不可以改写文件，redis启动之初会读取该文件重新构建数据。

AOF配置详解

在配置文件redis.conf全局搜索APPEND ONLY MODE
1.是否开启AOF（默认关闭）（一般使用的时候只需要改为yes，其他配置不需要理会）
2.指定本地数据库文件名，一般采用默认的 appendonly.aof

3.fsync持久化策略

appendfsync always 每次都修改
appendfsync everysec 每秒钟修改
appendfsync no 不修改

• always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

4.在重写 AOF 文件的过程中，是否禁止 fsync。（默认不开启）

5.指定 Redis 重写 AOF 文件的条件，默认为 100，它会对比上次生成的 AOF 文件大小。如果当前 AOF 文件的增长量大于上次 AOF 文件的 100%，就会触发重写操作；如果将该选项设置为 0，则不会触发重写操作。
指定触发重写操作的 AOF 文件的大小，默认为 64MB。如果当前 AOF 文件的大小低于该值，此时就算当前文件的增量比例达到了 auto-aof-rewrite-percentage 选项所设置的条件，也不会触发重写操作。
换句话说，只有同时满足以上这两个选项所设置的条件，才会触发重写操作。

6.当 AOF 文件结尾遭到损坏时，Redis 在启动时是否仍加载 AOF 文件。

7.RDB,AOF混合使用

测试AOF机制：

1.开启AOF

2.重启redis

发现生成了aof文件

3.登录客户端进行操作

4.查看aof文件，发现做了记录

5.额外测试，破坏aof文件

5.1停止redis

5.2手动修改aof文件（故意破坏文件）

5.3启动redis，发现被拒绝连接

5.4如果aof被破坏，是启动不了redis的，但是我们可以进行修复

./bin/redis-check-aof --fix appendonly.aof 

发现我恶意修改文件被修复了，但是k2没了，然后可以重启redis

总结：

优点：
1、每一次修改都同步，文件的完整性更好
2、每秒同步一次，可能会丢失一秒的数据
3、从不同步，效率最高
缺点：
1、相对数据文件来说，aof远远大于rdb，修复速度比rdb慢
2、aof运行效率比rdb慢，所以默认是rdb持久化