聊聊怎么技术上优化Redis持久化，性能提升其实没那么难也挺关键的

聊到Redis的持久化优化，很多人觉得这是个高深的话题，动不动就扯到底层原理和内核参数，其实没那么玄乎，咱们今天就抛开那些让人头疼的专业术语，用大白话聊聊怎么在实际操作中让Redis的持久化既可靠又不那么影响性能，核心就两点：RDB快照和AOF日志,优化也是围绕着它们俩以及怎么让它们协同工作来展开。

得搞清楚你的业务场景需要什么级别的持久化。

这就像买车，你不能既要求跑车般的速度，又要求卡车的载重能力，还得是自行车的价格，Redis提供了不同的“车型”，你得按需选择，如果你的数据可以容忍丢失几分钟（比如一些实时排行榜，丢了再从源头算一次也行），那RDB模式可能就够用了，如果你的数据至关重要，每一笔都不能丢（比如订单状态），那你就得倚重AOF模式，或者采用混合模式，这个选择是第一步，也是最关键的一步,它决定了你后续优化的方向和底线。

我们分别看看怎么“调教”RDB和AOF。

对于RDB（快照）核心就一句话：减少创建快照的负担和频率，找到平衡点。

默认配置可能每隔一段时间就做个快照，比如5分钟内有100个key变动就触发，但如果你的数据量很大，做一次快照可能会让Redis“卡”一下，因为Redis需要用主进程的子进程来完成这个工作，创建子进程和写入硬盘的瞬间，如果内存占用很高,对CPU和磁盘IO的压力是显而易见的。

那怎么优化呢？

1. 调整触发条件： 在配置文件里，你会看到类似save 900 1这样的配置，意思是900秒内至少有1个key变化就触发，你可以根据业务高峰和低峰期来调整，比如在深夜低峰期，你可以设置得激进一点（比如save 60 10000），在白天高峰期，设置得宽松一点（比如save 300 10）,避免在忙的时候添乱。
2. 给子进程“减负”： 创建RDB快照的子进程需要拷贝父进程的内存页，如果你的Redis实例内存占用非常大，比如几十个GB，这个拷贝过程可能会让系统瞬间内存压力倍增，一个很实用的办法是不要把内存设置得太大，可以考虑用Redis集群的方式把数据分到多个实例上，每个实例的内存控制在10GB以下，这样无论是做快照还是主从同步，压力都会小很多，这招是从很多大型互联网公司的实践经验中学来的，算是“分而治之”的思想。
3. 用好磁盘： 确保Redis的数据目录挂载的是高性能的SSD硬盘，RDB是顺序写，SSD的优势非常明显，千万别用机械硬盘,否则持久化会成为整个系统的瓶颈。

对于AOF（日志）核心是平衡数据安全性和写入性能。

AOF是把每一个写命令都记录下来，可靠性最高，但写操作频繁时,对磁盘IO的压力是持续的。

1. 调整刷盘策略： 这是AOF最重要的调优参数，默认是everysec，每秒刷一次盘，这已经是性能和安全性的一个很好折中了，如果你追求极致性能且能容忍少量数据丢失，可以设置为no，让操作系统自己去决定什么时候刷盘，这样最快，但风险也最大，如果你追求绝对的安全，连一秒的数据都不能丢，那就设为everysec的升级版，但每个命令都刷盘（always），但这会让Redis性能急剧下降，除非有强一致性要求，否则一般不推荐。绝大多数情况下，保持everysec就是个明智的选择。
2. 控制AOF文件的大小： AOF文件会越来越大，重写机制就是为了解决这个问题，它会基于当前内存中的数据，生成一个全新的、更精简的AOF文件，你可以调整触发重写的条件，比如当AOF文件比上次重写后大了100%（一倍）时，就自动触发重写，这个比例（auto-aof-rewrite-percentage）和最小体积（auto-aof-rewrite-min-size）都可以根据你的磁盘空间和写入量来微调,避免重写过于频繁或者长期不重写。

也是现在最推荐的“大招”：RDB-AOF混合持久化。

这是Redis后期版本提供的一个非常好的功能，可以说是取两者之长，简单说，就是在做AOF重写的时候，不再只是生成纯AOF格式的命令集，而是先像RDB一样，把内存数据的快照以二进制格式写入新的AOF文件开头,然后再追加增量期间的AOF命令。

这样做的好处是什么？

• 重启恢复速度快多了： 恢复时，先加载RDB部分，那是一片完整的数据快照，速度极快，然后再重放后面少量的增量AOF命令,整个过程比单纯重放一个巨大的AOF日志文件要快好几个数量级。
• 保持了AOF的高可靠性： 平时依然使用AOF的everysec策略,数据安全性有保障。

开启混合持久化通常只需要在配置文件中设置一个选项（aof-use-rdb-preamble yes），几乎没有什么代价，却能带来巨大的恢复性能提升,很多线上的生产环境都已经把这个作为标准配置了。

除了这些，还有一些通用的“保养”技巧：

• 监控，监控，还是监控： 你要时刻关注INFO PERSISTENCE命令的输出，看看最近一次RDB/AOF重写是否成功，耗时多久，如果发现持久化失败或者耗时异常，那就要立刻排查原因，可能是磁盘满了,也可能是权限问题。
• 别让持久化拖垮磁盘： 确保Redis的持久化文件放在一个独立的、高性能的磁盘分区上，别和其他频繁读写的应用（比如数据库、日志）挤在一起,避免IO竞争。

优化Redis持久化性能，真没那么难，关键就是理解RDB和AOF的脾气秉性，然后根据你自己的业务场景，像调节汽车座椅一样，调整几个关键参数：RDB的快照频率、AOF的刷盘策略，以及果断开启混合持久化，没有放之四海而皆准的最优解，最适合你业务场景的,就是最好的优化。