QPS是触发架构调整的信号灯而非观测指标；单节点超8万QPS或P99延迟超15ms需主动优化，包括查瓶颈、分级过期、读写分离及结构优化等。
QPS不是拿来“看”的指标，而是触发架构调整的信号灯。当Redis单节点持续超过8万QPS，或P99延迟突破15ms，就该动架构了——不是等它崩，是趁它还稳的时候切。
单节点QPS超限：先查瓶颈再决定要不要分片
单节点QPS长期高于7–8万，不代表必须上Cluster。先确认是不是命令或连接层拖垮的：
- 用
redis-cli --stat或INFO commandstats看cmdstat_get、cmdstat_hget的调用频次和耗时，高频小对象读取（如用户基础字段）优先考虑本地缓存降级，而不是立刻分片 - 检查客户端连接数是否接近
maxclients阈值，若大量TIME_WAIT或连接复用率低，换Lettuce+ 合理minIdle/maxIdle比硬上集群更有效 - 用
SLOWLOG GET 10查是否有keys *、sort或大hgetall（>1KB）在拖慢整体响应
QPS波动剧烈：用分级过期+逻辑过期防雪崩
电商大促或热点事件导致QPS短时翻倍，单纯扩容扛不住——缓存集中过期会引发雪崩式数据库冲击：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 避免统一
EXPIRE key 300，改用EXPIREAT key $((1726192320 + RANDOM%300))（随机偏移±5分钟），把过期时间打散 - 对核心key（如商品详情）采用逻辑过期：缓存value里嵌入
expireTime字段，应用层判断是否过期，过期则异步刷新，而非阻塞重建 - 空值也缓存：对查不到的
user:1001写入""并设TTL=2min，防止缓存穿透放大QPS压力
读写比失衡：按QPS分布做读写分离而非简单主从
读QPS是写QPS的10倍以上时，“一主多从”不等于自动负载均衡——从节点可能因同步延迟或慢查询被拖慢：
- 用
READONLY命令显式标记只读连接，配合Lettuce的ReadFrom.REPLICA_PREFERRED策略，避免读请求打到主节点 - 监控各从节点的
slave_repl_offset和主节点master_repl_offset差值，差值 > 10MB 就说明复制积压，需调大repl-backlog-size - 对实时性要求低的读场景（如历史订单列表），直接路由到延迟容忍更高的从节点，不参与主从健康检查
QPS与内存使用率双高：结构优化比扩容更立竿见影
QPS卡在6万但内存使用率 >85%，大概率是数据结构或序列化方式拖了后腿：
- 字符串类型存对象？立刻换成
HSET user:1001 name "a" age 28，字段名缩写（n,a），减少序列化开销和网络传输量 - 用
MEMORY USAGE key查大key，>10KB 的zset或hash拆成多个子key（如order:1001:items:0~:9），避免单次操作阻塞事件循环 - JSON序列化占内存太大？换
MessagePack或Protobuf，实测压缩率提升30–40%，同样内存可多存30% key
真正难的不是算QPS阈值，而是区分哪些QPS增长是业务自然上涨，哪些是缓存失效策略缺陷或客户端滥用导致的无效流量——后者调架构没用，得回代码里找bug。
