Redis里AOF持久化那个设置怎么调，感觉有点复杂想理清楚下

AOF是啥？简单理解就是“写命令日记”

想象一下，Redis在运行时，除了在内存里存着所有数据，还会在一个文件里（就是AOF文件）把你所有会改变数据的命令（比如set, hset, lpush等）按顺序记下来，万一Redis服务器重启了，它不需要从RDB那种快照恢复，而是直接把这个“日记”从头到尾重新执行一遍，内存的数据就原样重建了,所以AOF的好处是数据丢失的风险非常低。

核心设置：appendfsync —— 决定“日记”何时写到硬盘上

这是AOF最关键的一个设置，它控制了写日记的“谨慎程度”，你把数据写到Redis，Redis会先把这个命令写到内存中的一个缓冲区里。appendfsync这个参数，就是告诉Redis，这个缓冲区里的内容多久该被真正写到硬盘的AOF文件里，它有三个档位,就像汽车的档位一样：

1. appendfsync everysec（默认档，也是推荐档）：每秒同步一次。

   • 工作方式：Redis会创建一个后台线程,差不多每秒钟就把缓冲区里的命令刷到硬盘上一次。
   • 优点：在性能和安全性之间取得了很好的平衡，即使系统崩溃，你最多也只会丢失最近一秒钟内写的命令,这个风险对绝大多数应用来说都是可以接受的。
   • 缺点：理论上有一秒的数据丢失窗口，如果硬盘负载本身已经很高,这一秒一次的同步操作可能会引起短暂的延迟。
   • 适合谁：绝大多数情况都用这个就行，如果你不确定该怎么选,无脑用这个档位。

2. appendfsync always（最谨慎档）：每执行一个写命令，就同步一次。

   

   • 工作方式：只要你执行一个写命令（比如set name jack），Redis在把这个命令存到缓冲区后，会立刻、马上、无条件地把它写入硬盘文件,写完才返回成功给客户端。
   • 优点：数据安全性最高，除非写硬盘的那一刻硬件坏了,否则理论上不会丢失任何一条已经确认成功的命令。
   • 缺点：性能开销巨大，因为每个命令都要等一次硬盘IO（输入输出操作），硬盘读写速度远比内存慢，这会导致Redis的吞吐量急剧下降，普通硬盘根本扛不住这种写法，即使用固态硬盘（SSD）,也会大大损耗其寿命和性能。
   • 适合谁：对数据一致性有极端要求的场景，比如涉及到金融交易，哪怕丢一条数据都是灾难性的，但这类场景通常会有更高级的架构来保证,单靠Redis这个配置不一定够。

3. appendfsync no（最奔放档）：我不操心，操作系统你看着办。

   • 工作方式：Redis只负责把命令写到内存缓冲区，至于缓冲区什么时候把数据刷到硬盘上，完全交给操作系统自身的调度策略来决定，通常是缓冲区满了,或者操作系统自己定期刷盘。
   • 优点：速度最快，因为Redis不用等待慢速的硬盘IO,写操作可以飞快地返回。
   • 缺点：数据丢失风险最大，如果此时Redis进程突然崩溃（比如服务器断电），那么所有在操作系统缓冲区里、还没来及写入硬盘的命令就全丢了,这个丢失的数据量可能达到几十秒甚至几分钟。
   • 适合谁：纯粹追求极致性能，且可以容忍大量数据丢失的场景，比如用来做高速缓存,数据丢了再从数据库重新加载一遍也没关系。

小结一下appendfsync：日常就用everysec，除非你有非常明确的、不可退让的理由,否则不要轻易动这个设置。

AOF重写 —— “日记”太啰嗦了，需要瘦身

AOF文件会无限增长，因为它记录的是所有操作，比如你对一个计数器num连续执行100次incr num，AOF文件会老老实实记下100行命令，但实际效果等同于一条set num 100，AOF重写就是为了解决这种“日记越来越胖”的问题。

重写的过程是：Redis会创建一个子进程，扫描当前数据库的所有数据，然后为每个键值对生成一条最新的、最简洁的命令，写入一个新的AOF临时文件，重写完成后，再用这个新的、瘦身成功的小文件替换掉旧的、臃肿的大文件。

这里有几个相关设置：

• auto-aof-rewrite-percentage 100：意思是，相比上一次重写后AOF文件的大小，如果当前AOF文件大小增长超过了100%（也就是翻了一倍）,就触发自动重写。
• auto-aof-rewrite-min-size 64mb：意思是，AOF文件至少要达到64MB，才会考虑自动重写，这是为了避免文件还很小（比如才1MB）的时候，稍微涨一点就触发重写,没必要。

你可以根据你的数据量和写入频繁程度来调整这两个值，比如你的AOF文件通常都几个GB，那你可能觉得增长50%（设置50）就重写太频繁了，可以设大一点，或者你觉得64MB的起点太低,可以设成1GB。

一个综合的调整思路

1. 先定基调：把appendfsync设为everysec,这是基础。
2. 观察AOF文件：运行一段时间后，用INFO PERSISTENCE命令看看AOF文件的大小和重写情况。
3. 按需调整重写阈值：如果发现AOF文件增长很快，重写发生得太频繁（频繁重写本身也有性能开销），可以适当调大auto-aof-rewrite-percentage，比如从100调到200，如果AOF文件巨大，但重写迟迟不触发，可以检查一下auto-aof-rewrite-min-size是不是设得太高了。
4. 谨慎对待always和no：除非你真的清楚知道你在做什么，以及带来的后果,否则不要轻易切换到always或no模式。

最后记住，AOF和RDB（快照）并不是二选一，它们可以同时开启，用AOF保证数据少丢失，同时定期用RDB快照做一个冷备份，这是一个非常可靠的策略,希望这个解释能帮你理清楚思路。