AOF持久化配置
# 是否开启aof
appendonly yes
# 文件名称
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
aof-load-truncated yes # yes表示如果aof尾部文件出问题，写log记录并继续执行。no表示提示写入等待修复后写入
# 文件重写策略
aof-rewrite-incremental-fsync yes
-
appendfsync 同步模式有三种模式，一般情况下都采用 everysec 配置，在数据和安全里面做平衡性选择，最多损失1s的数据
-
always：把每个写命令都立即同步到aof，很慢，但是很安全
-
everysec：每秒同步一次，是折中方案
-
no：redis不处理交给OS来处理，非常快，但是也最不安全
-
-
AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是
appendfsync everysec配置，会有1s损耗），第二步是对aof文件的重写。-
步骤：
-
命令写入=》追加到aof_buf =》通过时间事件调用flushAppendOnlyFile函数同步到aof磁盘
-
-
原因：
-
实时写入磁盘会带来非常高的磁盘IO，影响整体性能
-
-
-
AOF持久化的效率和安全性分析
always：每个时间事件循环都将AOF_BUF缓冲区的所有内容写入到AOF文件，并且同步AOF文件，这是最安全的方式，但磁盘操作和阻塞延迟，是IO开支较大。
everysec：每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
no：redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。处于no模式下的flushAppendOnlyFile调用无须执行同步操作