相关配置

  1. appendonly   yes                                    # 默认是no，即默认是关闭AOF持久化
  3. appendfilename "appendonly.aof"    # 生成的aof文件名称
  5. appendfsync everysec                             # 每隔1秒钟，将redis写命令写入aof文件
  7. # always   每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去。这种方式，性能非常差，
  8.                      吞吐量很低。
  10. # everysec 每秒将os cache中的数据fsync到磁盘，最多丢失1秒内的数据。最常用，生产环境配置，
  11.                      性能高，QPS可以上万
  12. # no       redis只是将数据写入os cache就不管了，后面os会时不时按照自己的策略将数据写入磁盘，
  13.            不可控

redis热修改配置文件

  1. # 获取当前redis的配置项信息
  2. 127.0.0.1> config get *
  4. # 热修改配置项
  5. 127.0.0.1> config set <key> <value>
  7. # 例如，热修改开启 aof持久化
  8. config set appendonly yes

AOF持久化开启流程

(1) 如果redis内存存在数据，且只配置了RDB持久化机制

  1. (1) 首先需要通过热修改配置的方式，将AOF持久化机制打开，让aof文件可以根据现有redis里的数据，
  2. 生成构建指令，备份出完整的aof文件数据。
  4. (2) 然后修改修改6379.conf文件里的配置项 appendonly 为 yes，再重新根据新的配置文件重启redis。
  6. (3) 此时，重启后的redis，可以通过读命令查到原有的数据都通过aof文件恢复过来。
  8. 注意：如果一开始并没有通过热修改配置方式开启aof持久化，即跳过了上面的第一步，只是直接修改了
  9. 6379.conf配置文件的appendonly项，则在重启redis后，redis会新生成一个空数据的appendonly.aof文件，
  10. 并基于这个空的appendonly.aof文件去恢复redis内存数据。
  11. 这就会导致，redis原有的，可以查到的数据就都无法查到。所以，上面的第一步是非常重要的操作。

(2) reids本身同时开启了RDB和AOF持久化机制

  1. redis因为故障进行重启之后，会优先基于appendonly.aof文件进行数据的恢复。

AOF rewrite

原理说明

redis中的数据是有限的，很多数据可能会自动过期，也可能被用户删除，或者会被redis的缓存淘汰策略给清理掉。所以，redis中的数据是会不断淘汰旧的，然后留一部分常用的数据保存在redis内存中。
这就会一种情况，一些被淘汰的redis数据，对应的写日志还存在aof文件中，aof文件只有一个，后续的写命令会导致aof文件不断膨胀。
所以，aof会自动在后台每隔一定时间做rewrite操作，将最新的redis数据进行指令构建，重新存储在新的aof文件当中，在全部写入完毕后，就会覆盖旧的aof文件。 —— 确保aof日志文件不会过大，保持跟redis内存数据量一致。

  1. # 在redis.conf(6379.conf)中，可以配置rewrite策略
  3. auto-aof-rewrite-percentage 100   
  4. # 在aof文件膨胀到aof初始容量大小的一倍后，就会执行rewrite操作
  6. auto-aof-rewrite-min-size 64mb
  7. # 每次rewrite操作会比较当前的aof文件大小是否超过最小值64mb,如果没有超过，则不执行rewrite操作
  8. # 可能aof文件已经达到了初始容量的指定的百分比后，但文件还是很小，没有达到64mb，则不需要执行rewrite操作

rewirte流程

（1）redis fork一个子进程；
（2）子进程基于当前的redis内存的数据，构建写日志，开始往一个新的临时的AOF文件中写入日志；
（3）redis主进程，接收到客户端新的写操作之后，会在内存中写入日志，同时新的日志也会继续写入到旧的aof文件；
（4）子进程在写完新的aof日志文件后，redis主进程就会将内存中的新日志再次追加到新的aof文件中。
（5）最后，用新的AOF日志文件替换旧的AOF日志文件。

AOF破损文件修复

如果遇到redis在append数据到AOF文件时，机器宕机导致AOF文件破损的话，
可以通过 redis-check-aof --fix命令来修复破损的AOF文件。

AOF和RDB同时工作

（1）如果redis在执行RDB的snapshotting操作，那么redis就不会执行 AOF rewrite操作；如果redis在执行AOF rewrite操作，就不会执行RDB的snapshotting操作。
（2）如果redis在执行RDB的snapshotting操作，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会执行AOF rewrite。
（3）同时有 RDB snapshotting文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整。