1. 从一次线上告警说起为什么Redis配置不能照搬默认值凌晨两点手机突然开始疯狂震动。监控平台推来一条告警核心业务接口的P99响应时间从80毫秒飙升到2.3秒同时Redis实例的内存使用率在十分钟内从62%冲到了94%。爬起来连上服务器一看INFO memory显示used_memory已经逼近maxmemory而evicted_keys这个指标居然是0——也就是说内存快满了但Redis一个key都没淘汰新写入的请求全部在报OOM command not allowed when used memory maxmemory。问题出在哪半年前上线时运维同学为了“省事”直接用了默认配置文件只改了个bind和requirepass就上线了。maxmemory没设maxmemory-policy是默认的noeviction持久化用的是默认的RDB快照save策略是900 1 300 10 60 10000。平时流量小的时候一切正常等到业务量涨上来缓存数据越积越多内存自然就爆了。这件事让我意识到Redis的配置与优化不是“装完能用就行”的事情。它更像给一辆车做调校——发动机内存管理、变速箱持久化策略、刹车淘汰策略都得根据实际路况来调否则平时开着没事一上高速就可能出问题。这篇文章就是把我这些年踩过的坑、调过的参数、验证过的方案整理出来。不管你是刚接触Redis的新手还是已经用过一段时间但总觉得“性能还能再压榨一下”的开发者都能从中找到可以直接抄作业的配置方案和优化思路。我会从配置项的含义讲起说清楚每个参数背后的逻辑再给出不同业务场景下的推荐值和实操步骤最后把常见问题的排查方法整理成速查表。2. Redis核心配置项拆解每个参数都在解决什么问题2.1 内存管理三件套maxmemory、淘汰策略与内存碎片Redis是内存数据库内存就是它的命根子。和内存相关的配置项里最核心的是这三个maxmemory、maxmemory-policy、activedefrag。maxmemory决定了Redis实例最多能用多少内存。这个值不设或者设成0在64位系统上默认是“不限制”听起来很美好实际上很危险——Redis会一直吃内存直到把系统内存耗尽然后被操作系统OOM Killer干掉或者自己触发OOM错误。我的经验是单实例的maxmemory不要超过物理内存的70%剩下的30%留给系统、持久化时的fork操作、以及内存碎片。比如一台32GB的机器maxmemory设在20GB到22GB之间比较稳妥。maxmemory-policy是内存达到上限后的行为策略一共八种常用的就四种策略行为适用场景noeviction不淘汰任何key写入报错数据绝对不能丢且能接受写入失败allkeys-lru从所有key中淘汰最近最少使用的纯缓存场景最常用volatile-lru只从设置了过期时间的key中淘汰缓存和持久数据混布allkeys-lfu从所有key中淘汰访问频率最低的热点数据明显的缓存场景选哪个策略取决于你的数据是“缓存”还是“存储”。如果Redis里的数据丢了可以从数据库重建那就用allkeys-lru或allkeys-lfu如果有些key是持久化的重要数据那就用volatile-lru并且确保重要数据不设过期时间。activedefrag是内存碎片整理开关。Redis频繁增删key之后内存碎片率mem_fragmentation_ratio可能会超过1.5这时候开启主动碎片整理能回收一部分内存。但这个操作会消耗CPU建议在业务低峰期通过CONFIG SET activedefrag yes临时开启整理完再关掉。注意maxmemory的设置要留出持久化时fork子进程所需的内存。RDB持久化时fork会复制页表虽然Linux的COW机制让实际内存复制量不大但页表本身可能占用几十MB到上百MB。如果maxmemory设得太满fork可能失败。2.2 持久化选型RDB、AOF还是混合持久化持久化是Redis配置里最容易让人纠结的部分。RDB是快照AOF是日志4.0之后还有混合持久化。三者的区别用一句话概括RDB恢复快但可能丢数据AOF丢数据少但恢复慢混合持久化兼顾两者。RDB的配置主要是save指令。默认的save 900 1 300 10 60 10000意思是900秒内至少1个key变化、300秒内至少10个key变化、60秒内至少10000个key变化满足任一条件就触发快照。这个默认值在低峰期没问题但在写入频繁的场景下60秒10000次变化很容易触发导致频繁fork影响性能。我的建议是根据业务容忍度调整比如save 3600 1 300 100把触发门槛提高。AOF的配置核心是appendfsync有三个值always每条写命令都fsync最安全但性能最差QPS会掉到几千everysec每秒fsync一次最多丢1秒数据性能和安全平衡得最好no由操作系统决定何时fsync性能最好但可能丢几十秒数据生产环境我一般用everysec这是绝大多数场景的最优解。如果业务对数据一致性要求极高比如金融交易那就用always但要做好性能下降的心理准备。混合持久化通过aof-use-rdb-preamble yes开启。开启后AOF重写时会把当前数据以RDB格式写入AOF文件开头后续的增量命令以AOF格式追加。这样恢复时先加载RDB部分快再重放AOF部分少兼顾了恢复速度和数据安全性。4.0以上版本我强烈建议开启这个选项。2.3 连接与网络timeout、tcp-keepalive与maxclients连接相关的配置经常被忽略但配置不当会导致连接泄漏或客户端超时。timeout是客户端空闲连接的超时时间默认0表示不超时。这个值设太大空闲连接会一直占着资源设太小正常的长连接可能被误杀。建议设在300秒左右让空闲连接自动释放。tcp-keepalive是TCP层的保活探测默认300秒。这个值能及时发现死连接并释放建议保持默认或设为60秒。maxclients是最大客户端连接数默认10000。这个值要根据业务并发量和服务器文件描述符限制来调。如果设得比系统ulimit -n还大Redis启动时会自动调低并打日志。我一般会把它设为ulimit -n减去32留一些给Redis内部使用。实操心得修改maxclients之前先用ulimit -n确认系统限制。如果系统限制是1024那maxclients设成10000也没用Redis会自动降到992。要改系统限制需要修改/etc/security/limits.conf并重启会话。2.4 慢查询与延迟监控slowlog和latency-monitorRedis是单线程处理命令的一条慢命令会阻塞后面所有请求。slowlog能记录执行时间超过阈值的命令是排查性能问题的第一手资料。配置项有两个slowlog-log-slower-than阈值单位微秒默认10000即10毫秒和slowlog-max-len保留条数默认128。生产环境建议把阈值调到5000微秒5毫秒保留条数调到1024。超过5毫秒的命令就值得关注了可能是KEYS *、HGETALL大hash、SORT大列表这类操作。latency-monitor-threshold是延迟监控阈值单位毫秒默认0表示关闭。开启后比如设为100Redis会记录导致延迟超过100毫秒的事件通过LATENCY HISTORY命令查看。这个功能对排查偶发卡顿很有帮助。3. 不同业务场景下的配置方案与实操步骤3.1 纯缓存场景追求极致吞吐纯缓存场景的特点是数据可丢、可重建读多写少对吞吐量要求高。这种场景下我的配置思路是“内存优先、持久化从简、淘汰激进”。具体配置如下# 内存管理 maxmemory 20gb maxmemory-policy allkeys-lru activedefrag yes # 持久化只开RDB降低触发频率 save 3600 1 300 100 stop-writes-on-bgsave-error no rdbcompression yes rdbchecksum yes # 关闭AOF appendonly no # 连接 timeout 300 tcp-keepalive 60 maxclients 10000 # 慢查询 slowlog-log-slower-than 5000 slowlog-max-len 1024这里有几个关键决策需要解释。maxmemory-policy选allkeys-lru是因为缓存数据都可以丢LRU能保证热点数据留在内存里。stop-writes-on-bgsave-error no是因为缓存场景下RDB失败不应该阻塞写入否则缓存雪崩时Redis反而成了瓶颈。关闭AOF是因为缓存数据丢了可以从数据库重建没必要为了AOF牺牲性能。实操步骤上我一般会先用redis-cli --intrinsic-latency 100测一下基线延迟然后通过redis-benchmark做压测观察不同配置下的QPS和P99延迟。压测命令示例redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -t set,get -q这个命令会发起10万次请求50个并发连接测试SET和GET的QPS。压测时要注意如果Redis和压测工具在同一台机器上结果会受CPU竞争影响最好分开部署。3.2 缓存持久化混布兼顾性能与数据安全有些业务既用Redis做缓存又用它存一些不能丢的数据比如会话信息、分布式锁、排行榜。这种混布场景下配置要更谨慎。# 内存管理 maxmemory 16gb maxmemory-policy volatile-lru activedefrag yes # 持久化RDB AOF混合 save 900 1 300 10 appendonly yes appendfsync everysec aof-use-rdb-preamble yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 连接 timeout 300 tcp-keepalive 60 maxclients 8000 # 慢查询 slowlog-log-slower-than 5000 slowlog-max-len 1024关键变化在maxmemory-policy改成了volatile-lru只淘汰设了过期时间的key。这样持久化的数据不设过期时间不会被淘汰缓存数据设过期时间在内存不足时被清理。AOF开启并设为everysec最多丢1秒数据对大多数业务可接受。aof-use-rdb-preamble yes开启混合持久化加快恢复速度。这里有个容易踩的坑如果所有key都没设过期时间volatile-lru就退化成noeviction内存满了会报错。所以混布场景下一定要确保缓存类key都设了TTL。我一般会在代码层面强制要求缓存写入必须带过期时间否则打日志告警。3.3 高可用与集群主从、哨兵与Cluster的配置差异单机Redis再优化也有上限高可用和水平扩展是绕不开的。主从复制、哨兵、Cluster三种模式的配置重点不同。主从复制模式下从节点的配置要注意replica-read-only yes从节点只读和repl-backlog-size复制积压缓冲区大小默认1MB高写入场景建议调到64MB。repl-backlog-size太小会导致从节点短暂断连后需要全量同步全量同步会触发fork和RDB传输对主节点压力很大。哨兵模式是在主从基础上加了故障自动切换。哨兵的配置重点是down-after-milliseconds判定主观下线的毫秒数默认30000和failover-timeout故障转移超时默认180000。down-after-milliseconds设太小会误判设太大切换慢我一般设10000到15000。Cluster模式的配置重点是cluster-node-timeout节点超时默认15000和cluster-require-full-coverage是否要求所有槽都有节点才提供服务默认yes。cluster-require-full-coverage建议设为no这样部分槽不可用时其他槽仍能提供服务避免小故障导致整个集群不可用。注意Cluster模式下maxmemory的设置要更保守因为每个节点都要留内存给集群总线通信和故障转移。建议单节点maxmemory不超过物理内存的60%。4. 性能优化实战从参数调优到命令规范4.1 内存优化从数据结构到编码方式Redis的内存优化一半靠配置一半靠数据结构选型和编码方式。同样的数据用不同的结构存内存占用可能差几倍。举个例子存一个用户信息用String存JSON字符串和用Hash存字段内存占用完全不同。String存JSON每个用户一个keykey本身有开销JSON字符串也有冗余。Hash存字段Redis会对小Hash用ziplist编码内存紧凑得多。Redis的编码方式由几个阈值参数控制hash-max-ziplist-entries 128 hash-max-ziplist-value 64 list-max-ziplist-size -2 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64这些参数的意思是Hash的字段数不超过128且每个字段值不超过64字节时用ziplist编码List的元素个数和单个元素大小满足条件时用ziplistSet的元素都是整数且不超过512个时用intsetZSet类似Hash。调大这些阈值能让更多数据用紧凑编码节省内存但会增加操作时的CPU开销ziplist是线性结构增删改查是O(n)。我的经验是对于读多写少的场景可以适当调大阈值对于写频繁的场景保持默认或调小。还有一个容易被忽略的点key的命名也会影响内存。user:1001:profile比u:1001:p多占十几个字节乘以百万级key就是十几MB。当然可读性也很重要我一般建议在可读性和长度之间取平衡比如用u:1001:prof这种缩写。4.2 命令规范避免阻塞单线程的慢操作Redis单线程模型意味着一条慢命令会阻塞所有后续请求。有些命令在生产环境应该被禁用或替换。KEYS *是头号杀手它会遍历所有key百万级key的实例上执行一次可能阻塞几秒。替代方案是用SCAN游标分批遍历。SCAN不是一次性返回所有key而是每次返回一批和一个游标对CPU和内存友好得多。HGETALL、LRANGE、SMEMBERS、ZRANGE这些命令如果操作的是大key也会阻塞。替代方案是用HSCAN、SSCAN、ZSCAN分批获取或者用HGET、LINDEX按需获取单个元素。DEL大key也会阻塞因为删除操作是同步的。4.0之后可以用UNLINK异步删除把删除操作放到后台线程。对于大key我一般用UNLINK替代DEL。FLUSHALL和FLUSHDB更是危险操作生产环境应该通过rename-command重命名或禁用rename-command FLUSHALL rename-command FLUSHDB rename-command KEYS 这样即使有人误操作也执行不了这些命令。4.3 客户端优化连接池、Pipeline与Lua脚本客户端侧的优化对整体性能影响很大。连接池能复用连接避免频繁建连的开销。连接池大小要根据并发量调太小会导致请求排队太大浪费资源。我一般设成并发线程数的2到3倍。Pipeline能把多条命令打包发送减少网络往返次数。比如要执行100次SET不用Pipeline是100次RTT用Pipeline可能只要1次RTT。但Pipeline不是越大越好一次打包太多命令会占用大量内存建议每批100到1000条。Lua脚本能把多条命令在服务端原子执行减少网络往返还能保证原子性。比如“检查库存-扣减库存-记录日志”这个操作用Lua脚本一次搞定避免并发问题。但Lua脚本里不要写太复杂的逻辑否则会阻塞Redis。-- 示例原子扣减库存 local stock redis.call(GET, KEYS[1]) if tonumber(stock) tonumber(ARGV[1]) then redis.call(DECRBY, KEYS[1], ARGV[1]) return 1 else return 0 end这个脚本先检查库存是否充足充足则扣减并返回1否则返回0。整个操作在Redis服务端原子执行不会有并发问题。5. 常见问题排查与避坑指南5.1 内存相关问题速查现象可能原因排查命令解决方案内存持续增长不释放内存碎片率高INFO memory看mem_fragmentation_ratio开启activedefrag或重启实例写入报OOM错误maxmemory满了且策略是noevictionINFO memory看used_memory和maxmemory调整淘汰策略或扩容内存突然下降触发了淘汰或过期INFO stats看evicted_keys和expired_keys检查TTL设置和淘汰策略主从内存不一致从节点有额外内存开销对比主从INFO memory从节点maxmemory设大一些内存碎片率超过1.5就值得关注了。1.5意味着实际用了10GB但操作系统分配了15GB。碎片整理能回收一部分但如果碎片率超过2.0整理效果有限可能需要重启实例。5.2 延迟与阻塞问题排查Redis延迟高排查思路是“先看慢查询再看大key最后看系统因素”。第一步SLOWLOG GET 10看最近的慢查询。如果有KEYS、HGETALL这类命令基本就是元凶。第二步redis-cli --bigkeys扫描大key。这个命令会遍历所有key统计每种类型最大的key。注意这个命令本身也会阻塞建议在从节点或低峰期执行。第三步如果慢查询和大key都没问题就要看系统因素了。INFO commandstats看各命令的调用次数和耗时INFO latencystats看延迟分布。系统层面检查CPU使用率、内存交换vmstat看si/so、网络延迟。实操心得有一次遇到Redis偶发卡顿慢查询和大key都正常最后发现是服务器开启了透明大页THP导致fork时延迟飙升。关闭THP后问题消失。检查THP的命令是cat /sys/kernel/mm/transparent_hugepage/enabled如果显示[always]就建议关闭。5.3 持久化相关故障处理RDB持久化失败最常见的原因是磁盘空间不足或fork失败。INFO persistence里的rdb_last_bgsave_status如果是err就要检查磁盘空间和系统日志。fork失败通常是内存不足maxmemory设得太满fork时没有足够内存复制页表。AOF持久化的问题主要是文件损坏或重写失败。AOF文件损坏可以用redis-check-aof --fix修复。重写失败通常是磁盘空间不足或AOF文件太大可以调大auto-aof-rewrite-percentage和auto-aof-rewrite-min-size降低重写频率。主从同步失败时先看INFO replication里的master_link_status。如果是down检查网络连通性和repl-backlog-size。如果从节点频繁全量同步说明repl-backlog-size太小调大即可。5.4 配置修改的正确姿势Redis的配置修改有两种方式改配置文件重启或CONFIG SET动态修改。CONFIG SET修改的参数在重启后会丢失所以修改后要记得CONFIG REWRITE写回配置文件。不是所有参数都支持动态修改。maxmemory、maxmemory-policy、slowlog-log-slower-than这些支持动态改appendonly、save、maxclients这些不支持必须改配置文件重启。注意CONFIG REWRITE会重写整个配置文件如果配置文件里有注释可能会丢失。建议修改前先备份配置文件。6. 我个人的调优体会与几个实用技巧调Redis配置这件事我最大的体会是没有万能配置只有适合当前业务的配置。同一个参数在A业务是优化在B业务可能就是坑。比如appendfsync always在金融场景是必须的在缓存场景就是性能杀手。第二个体会是监控比调优更重要。配置调得再好没有监控就不知道效果。我一般会重点监控这几个指标used_memory、evicted_keys、expired_keys、keyspace_hits、keyspace_misses、instantaneous_ops_per_sec、latency_percentiles_usec。命中率低于90%就要考虑扩容或优化缓存策略了。第三个体会是变更要灰度。改配置不要一次性全量推先在一台从节点上改观察一段时间没问题再推主节点。我见过太多因为改配置导致全站故障的案例。最后分享几个实用技巧。redis-cli --latency能实时看延迟redis-cli --stat能看实时统计redis-cli --scan --pattern user:*能安全遍历key。还有一个我常用的命令redis-cli INFO everything | grep -E used_memory|evicted|hit|miss一条命令看关键指标。配置优化是个持续的过程业务在变数据量在变最优配置也在变。定期review配置结合监控数据调整才能让Redis始终保持最佳状态。