线上缓存一抖业务侧就开始报警这种场面做过高并发系统的人都不陌生。前阵子我把一套分布式缓存的核心链路重新梳理了一遍按26个主题拆开逐个推敲重点就盯着一件事怎么把Redis处理性能成倍拉上去。这里说的“成倍”不是换个机器、加个配置就完事而是从请求链路、命令成本、连接模型、部署形态四个层面同时下手把原本被浪费掉的吞吐量抠出来。Redis处理性能的提升本质上是一笔账一次命令从客户端发出到结果返回时间花在哪、哪些开销可以摊销、哪些压力可以分摊。搞不清楚这笔账盲目加机器往往只是把同样的瓶颈复制了一遍。这篇文章适合已经用过Redis、但一到压测和调优就凭感觉的开发者也适合正在设计缓存层、需要判断什么时候该上集群、什么时候该改客户端的同学。下面我按自己实际落地的顺序把方案选型、参数计算、代码改造和踩坑记录完整拆开讲。1. 成倍提升之前先把Redis的性能账本算清楚1.1 单线程事件循环不是瓶颈的全部很多人一提到Redis性能第一反应是“单线程”仿佛单线程就是天花板。这个理解只对了一半。Redis的命令执行确实是单线程的但它的单线程模型恰恰是为了避免锁竞争和上下文切换内存操作本身是纳秒级的单条GET/SET的执行时间通常在微秒量级。真正把吞吐卡住的往往不是命令执行本身而是命令到达之前和返回之后的那些环节客户端序列化、网络往返、内核协议栈拷贝、响应反序列化以及偶尔冒出来的大key和慢命令。我做过一次对比同样的机器、同样的数据量单连接逐条GET的QPS只有几千换成批量Pipeline之后直接冲到几万命令执行逻辑一行没改。原因很简单单连接串行请求时每次都要等一个完整的网络往返Redis再快也得等包回来。单线程事件循环基于epoll能同时处理大量连接但它处理的是“已经到达的命令”命令在路上花的时间它管不了。所以判断瓶颈要先看CPU如果Redis进程单核跑满说明命令处理确实到顶了这时候要考虑分片如果CPU不高但QPS上不去大概率是网络往返或客户端在拖后腿。还有一个容易被忽略的点单线程不代表所有操作都便宜。KEYS *、对大hash执行HGETALL、对大zset执行全范围ZRANGE这些命令的时间复杂度是O(N)N是整个集合的大小执行期间会阻塞其他所有请求。我见过一个线上案例某个运营后台误触发了一次全量key扫描Redis延迟瞬间从1毫秒飙到800毫秒业务侧超时一片。后来把扫描改成SCAN分批并限制在从节点执行问题才消失。所以优化Redis处理性能的第一步不是调参数而是先确认有没有这类“一颗老鼠屎坏一锅汤”的命令。1.2 一次命令从发出到返回时间都花在哪把一次Redis请求拆开大致经过这些环节业务代码组装参数、客户端序列化成RESP协议、写入TCP发送缓冲区、经过内核协议栈、到达服务端网卡、Redis事件循环读取并解析、执行命令、把响应写回缓冲区、网络返回客户端、客户端反序列化、业务代码拿到结果。每一段都有成本只是占比不同。同机房内网RTT通常在0.1到0.5毫秒跨机房可能到1到5毫秒一次简单的GET命令执行可能只要几十微秒但加上往返单连接串行QPS就被限制在几千。这里有个很实用的估算公式单连接串行请求的吞吐上限约等于1除以RTT。假设RTT是0.2毫秒理论上一秒最多5000次往返如果每次往返只带一条命令那单连接QPS就是5000左右。用了Pipeline之后一次往返带N条命令吞吐上限就变成N除以RTT但N不能无限大因为客户端要缓存请求、服务端要缓存响应响应包太大会撑爆缓冲区也会拉长单次延迟。我的经验是把单批响应控制在1MB以内超过就拆批。除了RTT序列化成本也经常被低估。Java原生序列化把一个对象转成字节数组动辄几百字节还带类元信息换成Protobuf或者MessagePack体积能降一半以上。别小看这点体积在QPS几万的场景下网络带宽和客户端CPU都会被它吃掉。我曾经把一个缓存value从Java序列化换成JSON再换成MessagePack同样的压测客户端QPS提升了将近40%Redis服务端CPU反而降了。原因就是客户端序列化耗时下降请求发得更快服务端处理同样数量的命令但等待更少。1.3 三条优化主线摊销RTT、降低单命令成本、分散单实例压力把上面这些账算完优化路径其实就很清楚了我习惯归成三条主线。第一条是摊销网络往返核心手段是Pipeline、批量命令和Lua脚本让一次网络交互携带更多有效工作。第二条是降低单命令成本包括选对数据结构、拆大key、减少value体积、避免慢命令让每条命令执行得更快、占用更少。第三条是分散单实例压力通过读写分离、集群分片、多级缓存把请求导到更多实例上突破单机CPU和网卡上限。这三条主线不是互斥的实际落地往往要组合使用。我通常先做第一条和第二条因为改动集中在客户端和键设计风险可控、见效快等到单实例确实扛不住再考虑第三条。顺序反了会怎样先上集群结果每个分片里还是有大key和慢命令问题只是被分散了没有消失运维复杂度还上去了。我见过一个团队在QPS刚过两万时就急着扩成六主六从结果热key依旧打满某一个分片其他分片却很闲最后还得回头做热key拆分。所以先榨干单实例再谈横向扩展这个顺序更稳。2. 方案选型不同量级该选哪条路2.1 单机、主从、哨兵、集群的边界单机适合数据量不大、QPS在几万以内、对可用性要求不极端的场景部署简单排查方便。主从在单机基础上做数据副本主写从读适合读多写少哨兵在主从之上解决故障自动切换但不解决分片数据量还是受单机内存限制。集群把数据按16384个槽分散到多个主节点每个主节点再挂从节点理论上可以线性扩展但带来了跨槽操作的限制。选型的判断依据其实就两个数据量和写QPS。数据量超过单机内存的70%或者写QPS接近单实例上限就该考虑集群。读QPS高但写不多可以先做主从读写分离成本比集群低得多。这里有个细节集群模式下多key操作必须落在同一个槽MGET跨槽会直接报CROSSSLOTLua脚本和事务也一样。所以上集群之前要先梳理业务里的多key操作用hash tag把相关key绑到同一个槽比如user:{1001}:info和user:{1001}:order大括号里的内容相同就会落到同一个槽。这个改造要提前做别等上了集群再回头改代码。哨兵和集群的高可用机制也不一样。哨兵需要客户端感知主从切换集群自带槽位重定向和故障转移。如果团队运维力量有限、数据量又没到必须分片的程度我倾向于先用主从加哨兵把客户端连接池和超时做好别一上来就追求集群。集群的槽迁移、节点扩缩容、跨槽问题每一样都需要额外的监控和预案小团队很容易被这些复杂度反噬。2.2 Pipeline、批量命令与Lua脚本的取舍这三样东西经常被混着用但语义和适用场景完全不同。Pipeline只是把多条命令打包发送不保证原子性中间可能插入其他客户端的命令它的价值纯粹是减少网络往返。批量命令如MGET、MSET是Redis原生支持的多key操作原子性取决于命令本身但同样受跨槽限制。Lua脚本把一段逻辑放到服务端执行能保证原子性适合“读-判断-写”这种需要一致性的场景但脚本执行期间会阻塞其他命令所以脚本必须短小。我的选择顺序通常是能用单命令批量解决的优先用MGET/MSET不能批量但允许非原子的用Pipeline必须原子且逻辑简单的用Lua。Pipeline的批次大小建议从50到200开始压测观察P99和客户端内存太小摊销效果不明显太大响应包膨胀、失败重试成本高。Lua脚本的执行时间要控制在10毫秒以内绝对不要在脚本里循环遍历大集合也不要执行KEYS。曾经有个团队用Lua做库存扣减脚本里带了一个全量扫描结果大促时整个分片卡死教训很直接。还有一个常见误区是把Pipeline当成事务用。Pipeline中途某条命令失败其他命令照样执行客户端要自己检查每条结果。如果业务要求全部成功或全部失败要么用MULTI/EXEC事务要么用Lua但事务同样受集群同槽限制。我在实际项目里更倾向用Lua处理需要原子的短逻辑用Pipeline处理日志上报、批量查询这类允许部分失败的场景边界划清楚后面排查问题会轻松很多。2.3 客户端连接池与线程模型的选型客户端这一层对性能的影响很多时候比Redis服务端配置还大。传统Jedis是每个操作借还连接池化能复用连接但池大小设置不合理就会出问题。Lettuce基于Netty多个线程共享同一个连接不需要大池适合高并发场景。选哪个要看团队技术栈和运维习惯但不管选哪个连接池的核心参数都要算不能拍脑袋。池大小的估算公式是所需并发数等于峰值QPS乘以平均响应时间秒再乘一个1.2到1.5的冗余系数。举个例子峰值QPS是3万平均响应时间0.8毫秒并发数就是30000乘以0.0008等于24乘1.5后约36池大小设40左右就够了。设太大反而有害连接过多会让Redis频繁做上下文切换内存开销也上去了。同时池大小不要超过Redis的maxclients的70%给其他客户端和运维连接留余量。超时设置也要按分位数来。连接超时可以设1秒读写超时按P99的1.5到2倍设比如P99是5毫秒读写超时设10到20毫秒不要设成几百毫秒甚至不设。超时太长会把故障放大一个慢请求占着连接不放后面请求排队连接池很快耗尽。重试只对幂等命令做最多两次并且要指数退避别搞成固定间隔重试风暴。我踩过一次坑客户端把超时设成3秒又没有重试上限Redis抖动时连接池瞬间打满业务线程全卡在等连接上最后是靠限流和缩短超时才恢复的。2.4 多级缓存与本地缓存的引入时机当Redis本身已经优化到瓶颈但业务对延迟仍然敏感就该考虑多级缓存了。最前面放一层本地缓存比如Caffeine或者Guava Cache存那些访问频率极高、更新不频繁的热keyTTL设短一点比如几百毫秒到几秒。本地缓存命中后直接返回连网络往返都省了对热key的QPS削减非常明显。但本地缓存带来一致性问题多实例之间数据可能不同步所以只适合对最终一致可接受的场景比如商品详情、配置项、榜单快照。引入本地缓存之前先把热key找出来。可以用redis-cli --hotkeys前提是淘汰策略设成LFU也可以用MONITOR短时间采样但MONITOR本身影响性能采样时间要短。找到热key后评估更新频率如果每秒都在变本地缓存意义不大反而增加不一致窗口如果几分钟才变一次就很适合。我一般会把本地缓存的失效做两层短TTL自然过期加上业务侧的消息通知主动失效尽量把不一致窗口压到秒级以内。多级缓存不是越靠前越好本地缓存会占用业务进程的堆内存缓存对象太大或者key太多容易引发GC问题。我的做法是限制本地缓存的条目数和单条大小比如最多一万条、单条不超过10KB超过就走Redis。这样既吃到热key的红利又不至于把业务进程拖垮。3. 把单次请求的成本压到最低核心参数与数据结构3.1 键设计与数据结构选型键设计看起来是小问题但在高QPS下会累积成可观的成本。key太长会占用更多内存网络传输和哈希计算也多一点key太短又不利于排查。我通常用“业务前缀:对象ID:属性”的格式控制在几十字节以内避免在key里放时间戳、随机数这类高基数内容否则内存碎片和过期管理都会变麻烦。还有一个原则是不要把不同生命周期的数据塞进同一个key否则过期时间没法分别设置。数据结构选型要按访问模式来。存对象字段用Hash比String加JSON更省内存也能单独更新某个字段但field数量不要太多超过一千个就考虑拆。存列表用List但只从两端操作需要按范围查询用ZSet去重计数用Set或者HyperLogLog后者有误差但内存极低布尔状态用Bitmap比如签到场景一年365天只需要几十字节。很多性能问题不是Redis慢而是用错了结构比如用String存一个大JSON每次更新都要整体读写QPS和带宽都被放大。这里补一个常被忽略的点Hash的field数量多时HGETALL会阻塞应该用HSCAN分批Set很大时用SSCANZSet范围查询要带LIMIT。删除大集合不要用DEL用UNLINK异步删除避免阻塞主线程。这些操作在低峰期做别在业务高峰期执行。3.2 大key拆分与热key治理大key是Redis性能的隐形杀手。判断标准不绝对我的经验是String超过10KB、Hash/Set/ZSet元素超过5000、List超过5000就该警惕。大key的危害有三层网络传输时间长、删除时阻塞、迁移时卡槽。排查用redis-cli --bigkeys它会扫描并给出每种类型的最大key但要注意这个命令本身有开销放在从节点或者低峰期执行。拆分大key的思路是按维度打散。比如一个用户的全部订单存在一个Hash里可以按订单ID取模拆成多个Hashorder:{userId}:{0..9}每次只查对应分片。或者按时间分片按月存不同key。拆完之后要注意聚合查询的逻辑客户端要能合并结果。删除大key用UNLINK如果版本不支持就先改名为一个临时key再慢慢删。热key的治理思路不一样热key本身可能不大但QPS集中在一个key上会把某个分片的CPU打满。治理手段有三个本地缓存挡住大部分读给key加随机后缀做读分片比如hotkey:{0..9}写入时写十份读取时随机选一个读写分离把读流量导到从节点。加后缀的方案会增加写入成本和一致性复杂度只适合读远多于写、且能容忍短时间不一致的场景。我一般优先用本地缓存实在不行再考虑后缀分片。3.3 序列化、压缩与网络参数序列化方案的选择前面提过核心就是体积小、速度快。JSON可读性好但体积大Protobuf和MessagePack体积小但需要定义schema。如果value超过1KB可以考虑压缩Snappy或者LZ4的压缩比不错CPU开销也能接受但小于1KB的数据压缩反而得不偿失压缩头和解压时间会抵消收益。我的经验阈值是1KB起步压缩后如果体积没降30%以上就放弃压缩。网络参数方面tcp-nodelay yes建议开启禁用Nagle算法减少小包延迟tcp-keepalive设300秒左右及时发现死连接timeout不要设太小设0或者300秒避免空闲连接被误杀导致客户端反复重连。tcp-backlog默认511在高并发下可以调到2048同时把系统somaxconn调大。Redis 6之后支持io-threads把网络读写放到多线程但命令执行还是单线程。这个参数不是越大越好4到8线程通常够了小包场景提升有限反而增加线程切换开销。开启时记得同时设io-threads-do-reads yes。3.4 持久化与内存配置的隐性影响持久化对性能的影响经常被低估。RDB做fork时虽然子进程写时复制但fork本身要复制页表内存越大耗时越长期间主线程会短暂阻塞。AOF的everysec策略每秒刷盘一次性能不错但最多丢一秒数据always每条都刷性能下降明显no交给操作系统不推荐。混合持久化aof-use-rdb-preamble yes兼顾恢复速度和文件体积我一般会开。AOF重写期间CPU和磁盘IO都会上升auto-aof-rewrite-percentage和auto-aof-rewrite-min-size要设合理别让重写太频繁。内存方面maxmemory设成物理内存的70%到80%留出fork和碎片的余量淘汰策略按业务选纯缓存用allkeys-lru有持久数据用volatile-lru。activedefrag yes可以在运行时整理碎片但会消耗CPU碎片率不高时没必要开。系统层面记得关闭透明大页设vm.overcommit_memory1这两个是老生常谈但每次换机器都有人忘。4. 实操全过程从压测基线到翻倍提升4.1 压测环境搭建与基线数据采集动手改之前先建基线否则后面说“提升了一倍”没有依据。压测环境尽量贴近生产同样的机器规格、同样的网络拓扑、同样的value大小。工具可以用redis-benchmark做快速验证命令是redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -P 16 -t set,get -q其中-c是并发连接数-n是总请求数-P是Pipeline批大小。更贴近真实业务的是memtier_benchmark能模拟读写比例和key分布。基线要记录的指标不只QPS还包括P50、P95、P99延迟、Redis进程CPU、网络带宽、连接数、内存使用和碎片率。压测时固定value大小比如1KB固定客户端数量跑三轮取稳定值。同时用redis-cli --latency -h host -p port持续观察延迟用INFO stats看instantaneous_ops_per_sec用INFO commandstats看每类命令的调用次数和耗时。基线数据存下来后面每改一项就对比一次避免多项改动混在一起说不清是谁的功劳。我还会在压测期间盯一下客户端的CPU和GC。很多时候Redis服务端还没到瓶颈压测客户端先撑不住了结果误判成Redis性能不行。压测客户端最好独立机器不要和Redis混部。4.2 Pipeline改造从逐条发到批量发Pipeline改造是最容易见效的一步。以Java Jedis为例逐条GET的写法是循环调用jedis.get(key)改成PipelinePipeline pipeline jedis.pipelined(); for (String key : keys) { pipeline.get(key); } ListObject results pipeline.syncAndReturnAll();注意批次不要一次把所有key都塞进去按200到500一批循环处理每批结束后检查结果。Python的redis-py写法类似pipe client.pipeline(transactionFalse) for key in keys: pipe.get(key) results pipe.execute()transactionFalse表示不开启事务纯粹批量发送性能更好。如果业务需要原子性再考虑transactionTrue或者Lua。改造后要观察响应包大小如果单批返回超过1MB就把批次调小。还要处理部分失败的情况Pipeline不会因为某条命令失败而中断客户端要逐条检查结果记录失败key后续补偿。Lua脚本适合“读不到就写”的原子逻辑比如local value redis.call(GET, KEYS[1]) if value then return value end redis.call(SET, KEYS[1], ARGV[1], EX, ARGV[2]) return ARGV[1]脚本里只做简单判断和写入不要循环大集合。集群模式下要确保KEYS[1]和脚本里用到的其他key在同一个槽否则直接报错。4.3 连接池参数计算与客户端调优连接池参数按前面的公式算。假设压测目标是峰值3万QPS平均响应时间0.8毫秒并发数24冗余系数1.5池大小36到40。Jedis配置里maxTotal40、maxIdle40、minIdle10、maxWaitMillis200。maxWaitMillis不要设太大等200毫秒还拿不到连接说明池不够或者有泄漏快速失败比长时间排队更好。Lettuce不需要这么大的池因为它共享连接重点设命令超时和连接超时。不管用哪个客户端都要监控连接池的活跃数、空闲数和等待数。等待数持续大于0说明池太小或者下游变慢活跃数长期等于最大值也要警惕。连接泄漏的排查方法是看CLIENT LIST里的连接年龄和空闲时间如果大量连接空闲时间很短但又不释放多半是借出没归还。超时和重试要配套。连接超时1秒读写超时按P99的1.5倍设重试只对GET这类幂等命令最多两次间隔带随机抖动。非幂等命令比如INCR不要自动重试否则可能重复扣减。限流和熔断也要有Redis整体不可用时快速失败并降级到本地缓存或者数据库别让请求全堆在连接池上。4.4 读写分离与集群分片落地读多写少的场景先做主从读写分离。从节点设readonly yes客户端把读请求路由到从节点写请求走主节点。要注意复制延迟用INFO replication对比主从的master_repl_offset延迟超过业务容忍度时关键读还是走主。从节点可以承担压测、大key扫描、备份这些重活减轻主节点压力。单实例写QPS到顶再上集群。集群至少三主三从槽位均匀分布。客户端用JedisCluster或者Lettuce的集群模式它们会自动处理MOVED和ASK重定向。上集群前把多key操作改成同槽用hash tag绑定。扩容时用redis-cli --cluster reshard迁移槽迁移期间会有ASK重定向客户端要支持迁移尽量在低峰期做大key提前拆掉否则迁移会卡住。集群的监控要关注槽位分布、节点间网络、故障转移次数。cluster-node-timeout默认15秒根据业务容忍度调整太小容易误判太大故障恢复慢。集群模式下不要用KEYS、FLUSHALL这类全量命令SELECT也不支持数据库只有0号库这些限制要在设计阶段就考虑进去。4.5 系统参数与Redis配置调优系统层面把文件描述符限制调大ulimit -n 65535somaxconn调到65535tcp_max_syn_backlog相应调大。关闭透明大页设vm.overcommit_memory1vm.swappiness1避免内存被换出。这些参数改完要重启或者用sysctl -w生效记得写进开机配置。Redis配置里maxclients按实际连接数设比如10000留出余量tcp-backlog 2048timeout 300慢查询阈值slowlog-log-slower-than 10000也就是10毫秒慢查询日志保留128条latency-monitor-threshold 100超过100毫秒的操作记录下来。io-threads按CPU核数设4到8开启读多线程。AOF用everysec开启混合持久化重写阈值设合理。改配置要一项一项改每改一项压测一轮记录变化。一次性改十几个参数出了问题根本不知道是哪个引起的。我一般的顺序是先客户端Pipeline和连接池再键设计和序列化再系统参数最后持久化和集群。每一步都有回滚方案压测通过再上生产。4.6 验证结果与回归观察改造完成后用同一套压测脚本复测对比基线。我最近一次落地的结果是QPS从4万左右提升到9万P99从8毫秒降到2.3毫秒Redis进程CPU从单核打满变成多核均衡错误率保持在万分之一以下。这个提升不是靠单一手段而是Pipeline摊销往返、value体积压缩、连接池调优、从节点分担读流量几项叠加出来的。上线后要观察至少24小时重点看延迟分位数、慢查询数量、连接数、内存碎片率和主从延迟。压测环境和生产环境有差异压测通过不代表生产一定稳。回归期间保留回滚开关比如Pipeline批次大小、是否走从节点读都可以通过配置中心动态调整。还有一点提升之后客户端CPU可能反而上升因为请求发得更密了要同步观察业务机器的负载别把瓶颈从Redis转移到业务进程。5. 常见问题与排查技巧实录5.1 延迟毛刺与慢查询定位延迟毛刺是最难缠的问题平均延迟看着正常P99突然飙到几百毫秒。排查顺序我一般是先看毛刺发生的时间点再看SLOWLOG GET 10有没有慢命令再看LATENCY HISTORY和LATENCY GRAPH最后看系统监控里的磁盘IO、网络和内存。周期性毛刺比如每小时一次多半和RDB保存、AOF重写或者定时任务有关偶发毛刺要看有没有大key删除、KEYS扫描、集群槽迁移。redis-cli --latency适合长时间观察能看出延迟分布。INFO latencystats可以看每类命令的延迟分位数。如果慢查询里出现HGETALL、ZRANGE、SMEMBERS这类命令基本就是大key问题改成HSCAN、带LIMIT的范围查询或者分批SSCAN。如果慢查询是DEL换成UNLINK。还有一种情况是客户端GC导致的毛刺Redis侧看起来很健康但客户端停顿几百毫秒请求堆积后集中打过来这种要看客户端的GC日志。5.2 内存抖动、碎片与淘汰内存问题通常表现为两种一种是used_memory持续上涨直到触发淘汰另一种是used_memory不高但RSS很高碎片率mem_fragmentation_ratio超过1.5。前者要查是不是有key没设过期时间或者业务写入量突增后者可以考虑开启activedefrag或者在低峰期重启实例。注意activedefrag会消耗CPU碎片不严重时别开。大量key同时过期也会引起抖动因为过期删除是惰性加定期采样集中过期时主线程要处理大量删除。解决办法是给过期时间加随机偏移比如基础TTL加0到300秒的随机值把过期分散开。淘汰策略要和业务匹配纯缓存用allkeys-lru有不能丢的数据用volatile-lru并且确保这类key都设了过期时间否则淘汰不到它们。maxmemory别设成物理内存的100%留出fork和碎片的余量70%到80%比较稳妥。5.3 连接数暴涨与超时风暴连接数突然暴涨先用CLIENT LIST看连接的cmd、age、idle字段。如果大量连接处于空闲但又不释放多半是连接池泄漏或者客户端没有正确关闭连接如果大量连接卡在某个命令上说明下游变慢导致连接堆积。CLIENT LIST TYPE normal可以过滤掉订阅类连接看着更清楚。maxclients打满后新连接会被拒绝报错“max number of clients reached”这时候要先限流保命再排查根因。超时风暴往往和重试策略有关。下游一慢客户端超时然后重试重试又加重下游负担形成正反馈。解决办法是超时时间按分位数设、重试次数限制、加指数退避和随机抖动同时在入口做限流和熔断。Redis前面最好有一层本地缓存兜底Redis不可用时返回旧数据或者默认值别让请求直接打到数据库。我踩过一次坑客户端重试间隔固定100毫秒且不限次数Redis抖动两秒重试请求翻了几倍最后是靠紧急限流才压下去的。5.4 集群槽位、迁移与跨槽问题集群最常见的报错是CROSSSLOT多key操作不在同一个槽。解决就是用hash tag比如把user:1001:info和user:1001:order改成user:{1001}:info和user:{1001}:order。注意hash tag只取大括号里的内容做CRC16大括号里不要放太多变化的内容否则分片不均匀。MOVED和ASK重定向是正常现象客户端要能自动处理并刷新槽缓存如果客户端版本太老不支持就会频繁报错。槽迁移时大key会卡住因为迁移是同步的一个大key可能几十MB迁移期间该槽的请求会阻塞。迁移前用--bigkeys扫一遍把大key拆掉或者提前迁移。迁移用redis-cli --cluster reshard指定源节点、目标节点和槽数量过程中观察cluster nodes的槽状态。故障转移时间由cluster-node-timeout控制设太小容易误判设太大恢复慢15秒左右是常见起点再按业务容忍度调。5.5 常见问题速查表现象可能原因排查命令处理建议P99延迟周期性飙高RDB保存或AOF重写INFO persistence、LATENCY HISTORY调整重写阈值低峰期执行考虑混合持久化慢查询里出现HGETALL/ZRANGE大key或大范围查询SLOWLOG GET 10、--bigkeys改HSCAN、加LIMIT、拆分大key连接数暴涨连接池泄漏或下游变慢CLIENT LIST、池监控修连接归还、缩短超时、加限流内存碎片率高频繁增删、value大小不均INFO memory看碎片率开启activedefrag或低峰重启CROSSSLOT报错多key不在同一槽客户端错误日志用hash tag绑定相关key集群迁移卡住大key同步迁移CLUSTER NODES、--bigkeys迁移前拆大key低峰期迁移大量key同时过期过期时间集中INFO keyspace、业务写入逻辑TTL加随机偏移分散过期客户端超时但Redis正常客户端GC或网络抖动客户端GC日志、--latency优化序列化、调大堆或换客户端这张表我一般贴在排查手册第一页遇到问题先对照一遍能省不少时间。表里的命令都不重生产环境可以直接跑但--bigkeys和MONITOR这类要控制频率别在高峰期反复执行。我现在的习惯是每次上线前先跑一遍基线压测把QPS、P99、CPU、连接数记下来改一项测一项不把多个变量混在一起。踩过的坑告诉我Redis性能提升最忌讳一上来就加机器、堆配置先把网络往返摊销掉、把大key和慢命令清掉、把连接池算清楚往往一台机器就能干原来三台的活。后面如果业务继续涨再按数据量和写QPS的边界去扩主从或者上集群心里也有底。