前面简述了一下redis持久化的RDB方式。这种方式会在满足save 配置要求或手动save/bgsave的条件下，在某个时间点生成一个数据快照如下rdb文件。但是它有一个缺点就是很可能会丢失掉最后一次数据保存的内容，对于精度要求不是那么高的业务需求，使用RDB就足够了（在某些情况下，RDB的定时备份适用于灾备，可以指定恢复到哪个备份的数据版本）。但是我们的很多场景对数据敏感度较高，就需要使用另外一种持久化的方式AOF了。AOF的持久化角度和RDB的不同，它是通过追加的方式记录redis的所有的写指令。每当服务器进程重启的时候，会重新执行一次所有的命令。
AOF持久化的开启
# 这个开关开启，就自动使用AOF 缓存功能
appendonly yes
# aof储存的写指令的文件默认是 appendonly.aof
appendfilename "appendonly.aof"
#### appendonly.aof的默认路径还是 dir 配置的路径，与RDB文件一直
dir ./
在Redis中，可以同时使用AOF和RDB的缓存。如果同时使用，会默认优先使用AOF恢复数据。因为在正常情况下，AOF的恢复的数据总是比RDB超前，完整度更高。如果AOF因为某些原因不能恢复，我们还可以采用RDB的方式进行数据恢复，这种快照文件总是可用的，类似于一种双保险。
默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。下面三选一的是AOF写入到硬盘(默认是使用everysec)
# 每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
# appendfsync always
# 每秒钟强制写入磁盘一次，处理速度也快，在性能和持久化方面做了很好的折中，推荐
appendfsync everysec
# 完全依赖os，性能最好,持久化没保证
# appendfsync no
随着时间的推移，AOF的文件大小会持续地增长，文件越大对加载的速率大有影响。因此Redis提供了bgrewriteaof(不能和bgsave同时进行，防止同时对磁盘的大量IO操作)命令去重写这个AOF的文件。整个重写是绝对安全地，它会剔除一些已经超时的数据，去除一些无效命令(del test等)和合并一些可合并的命令（lpush list a | lpush list b 合并为lpush list a b ，或者将10此 incr key 合并为 set key 10）.
重写机制的触发有以下两个配置：
# 表示AOF的文件重写时的最小体积
auto-aof-rewrite-min-size 64mb
# 百分比值：每次rewrite都会记录上一次压缩后的消息，
# 如果超过100% 就会再执行重写逻辑
auto-aof-rewrite-percentage 100
# 当子文件重写AOF文件时，如果启用以下选项，则文件将每生成32MB的数据进行fsync。
# 这对于以增量方式将文件提交到磁盘并避免大的延迟峰值非常有用
aof-rewrite-incremental-fsync yes
重写的过程是是：
- 首先Redis使用fork创建一个子进程
- 主进程依然取响应其他的命令，并将继续响应其他client的命令。这些命令依然会被记录到 AOF 缓冲区，并根据 appendfsync 策略同步到磁盘，保证原有 AOF 机制正确性；
- 子进程复制的是fork命令是的父进程的数据，因此会再使用第二点中的AOF缓冲区的数据追加，防止文件生成期间导致两边数据不一致；
- 子进程根据内容的快照，按照算法规则简化合并生成新的AOF文件。这个过程要注意上面的配置，默认每32mb会进行一次fsync，避免大量数据提交造成峰值过高的硬盘阻塞现象；
- 写入完成之后，子进程再通知父进程更新统计信息；
- 父进程将缓冲区的内容写到这个新的AOF文件中；
- 使用新的AOF文件去替换掉原本的旧的文件。
如果AOF文件中有错误内容导致了AOF数据无法恢复，建议备份后，使用redis-check-aof --fix filtpath 的命令去尝试自动修复它即可
网友评论