Redis配置那些事儿，聊聊怎么调才能跑得更快更稳点

说到Redis配置,这确实是个技术活，但咱们今天不整那些高大上的术语，就用大白话聊聊怎么通过调整一些“开关”，让Redis这个速度快小子既能撒开腿跑，又不会半路摔跟头，这些内容很多都是社区里老司机们（比如Redis官方文档、一些技术博客像“Redis Labs Blog”、“阿里云开发者社区”等）常年积累的经验之谈。

第一件事：内存是命根子，别让它“撑死”了

Redis最快的地方就是所有数据放内存里,所以内存管理是头等大事，默认配置下，如果内存用完了，Redis会报错，写不进去了，这就像水管堵了，很麻烦，所以你得提前设个上限，maxmemory 这个参数，但光设上限还不够，关键是指定内存快满的时候，怎么办。

这里有个重要的策略配置叫 maxmemory-policy，你不能真等到100%满了再行动，那时候就晚了，常见的策略有：

• allkeys-lru：尝试淘汰掉最近最少使用的键，不管这个键有没有设置过期时间，这是比较通用和推荐的选择，能保证最常用的数据留在内存里。
• volatile-lru：只淘汰那些设置了过期时间的键中，最近最少使用的，如果你的业务里有些关键数据是永久的，可以用这个。
• noeviction：默认策略，就是不淘汰，直接报错，在生产环境这通常不是个好主意，除非你有别的保证内存不溢出的方法。

设置策略就像是给Redis一个“清理内存”的预案，告诉它内存紧张时该扔哪些“包袱”，根据Redis官方和很多实践者的建议，一般会把 maxmemory-policy 设为 allkeys-lru，并且把 maxmemory 设得比物理内存小一点，比如机器有8G内存，给Redis设6G，留点余量给操作系统和其他进程。

第二件事：持久化是“保险单”，配置不好会变“拖油瓶”

Redis虽然快,但数据在内存里，一断电就没了，所以它提供了两种“保险单”：RDB和AOF。

• RDB（快照）：隔一段时间把整个内存数据拍个照存到磁盘上，文件小，恢复快，但可能会丢失最后一次快照到宕机之间的数据，配置主要在 save 参数，save 900 1 表示900秒内至少有1个键被改动就触发快照，别设得太频繁，比如每分钟一次，如果数据量大，频繁写磁盘会严重影响性能，也别设得太稀疏，比如一天一次，那丢数据风险太大，根据你对数据丢失的容忍度来定，save 300 10（5分钟10次改动）或 save 60 10000（1分钟1万次改动）是比较常见的折中。
• AOF（日志）：把你所有的写命令都记下来，这样丢数据少，最多丢一秒的（如果配置为每秒同步），但文件会越来越大，恢复起来慢，AOF有个关键配置 appendfsync：
  • always：每个写命令都立刻刷到磁盘，最安全，但慢得惊人，除非你对数据一致性要求极高，否则不推荐。
  • everysec：每秒刷一次，这是默认值，也是推荐值，在安全性和性能之间取得了很好的平衡，最多丢一秒的数据。
  • no：让操作系统决定什么时候刷，最快，但最不安全。

很多有经验的运维（比如一些云服务商的最佳实践文档）会建议同时开启RDB和AOF，用AOF保证数据安全性，用RDB做冷备份和快速恢复，这样即使AOF文件损坏了，你还有个RDB备份可以兜底。

第三件事：连接数和小数据包，别让小问题拖垮整体

Redis是单线程处理命令的,所以它怕两件事：连接数太多和单个命令太慢。

• 最大连接数（maxclients）：默认是10000，一般够用，但要确保你的系统文件句柄数限制（ulimit）比这个值大，否则设了也白设，如果连接数真的快满了，可能是客户端有连接泄漏，得去查代码，而不是一味调大这个参数。
• 慢查询日志（slowlog-log-slower-than）：这个功能太有用了，单位是微秒，默认10000微秒（10毫秒），对于快的Redis来说，一个命令执行10毫秒已经算“慢”的了，你可以把它设小点，比如5000微秒，然后定期检查慢查询日志，看看是哪些命令慢，常见元凶可能是 keys *（绝对禁止在生产环境用！）、一次性获取大的集合（hgetall big_key）、或者复杂的Lua脚本，找到这些慢命令，优化它（比如用scan替代keys，分批获取数据），性能立马提升。

第四件事：系统层面也得搭把手

光调Redis本身还不够,它跑在操作系统上，系统也得优化。

• 透明大页（Transparent Huge Pages）：这玩意儿Linux内核默认开启，但对Redis这种内存密集型应用不友好，可能导致延迟飙升，老司机们（比如Redis官方文档就明确指出了）一定会建议你把它关掉，命令通常是 echo never > /sys/kernel/mm/transparent_hugepage/enabled。
• overcommit_memory：这个参数关系到Redis后台持久化（bgsave）时会不会失败，建议设置为1：echo 1 > /proc/sys/vm/overcommit_memory，这样可以避免因为内存申请问题导致bgsave子进程被杀掉。

总结一下

调优Redis不是一蹴而就的,没有一个配置能通吃所有场景，你得根据自己的业务特点来：是读多写少还是写多读少？能容忍丢多少数据？硬件配置如何？

核心思路就是：管好内存别溢出，配好持久化当保险，监控慢查询消除瓶颈，最后别忘了系统层面扫清障碍。 最好的办法是，在压力测试环境下，用接近生产的数据量，一边模拟请求，一边调整这些参数，观察变化，找到最适合你自己业务的那个“甜蜜点”，这样调教出来的Redis，才能又快又稳。