数据结构与 Key 设计优化

1. 规避大 Key / 大 Value
   • 问题：单个 value 几十 MB、上万元素 list/hash，阻塞主线程、网络 IO、分片内存倾斜、删除阻塞。
   • 优化：
     • 列表拆分：长 list 分多段 hash；大批量结果分页存储；
     • 统一阈值：value 上限控制 100KB 以内；
     • 删除用 unlink 异步释放，禁止批量 del；
     • 热大数据不进缓存，走对象存储 + 分页查询。
2. Key 规范压缩，减少内存占用
   • 缩短前缀，统一命名规范，避免超长字符串 key；
   • 数字 ID 直接存数值，不用字符串拼接冗余前缀；
   • 重复固定前缀用 hash 结构代替大量独立 key。
3. 选对数据结构
   • 少数据量和简单结构 K-V：String；
   • 对象多字段：Hash（hget 单字段，不用 get 全量）；
   • 有序排行榜：ZSet；
   • 去重集合：Set；
   • 队列任务：List / Stream； 禁止用 String 存完整 JSON 对象，频繁更新单字段会全量读写。

读写请求优化（降低缓存 CPU / 网络开销）

1. 批量操作代替循环单条命令
   • Redis：mget/mset/hmset，Pipeline 管道打包多条指令，减少网络往返 RTT；
   • 禁止 for 循环逐条 get/set，高并发下网络放大几十倍耗时。
2. 控制冷热分离，少读冷数据
   • 热点永久缓存（逻辑过期），冷数据短过期；
   • LFU 淘汰策略优先保留高频访问 key，减少缓存失效重建。
3. 减少重复缓存重建（防击穿）
   • 热点 key 加互斥锁、逻辑永不过期、过期时间随机打散；
   • 后台异步定时刷新热点缓存，流量高峰不触发 DB 查询。
4. 读写分离
   • 查询走从节点，写命令走主节点；
   • 实时一致性要求高的场景才读主，纯查询分摊主库压力。
5. 避免频繁 TTL 刷新 高频访问 key 不要每次 get 都 expire，集中定时刷新过期时间。

缓存性能评估指标

吞吐量指标

• QPS：每秒缓存读写请求数；
• 峰值 QPS、平均 QPS、99 分位 QPS；
• 命中率 Hit Ratio（核心指标） 命中率 = 缓存命中次数 / 总查询请求 标准：
  • 业务正常：≥90%
  • 优质缓存设计：≥95%
  • 低于 80% 说明缓存策略完全失效，大量流量打 DB

2. 延迟指标（RT 响应耗时）

• 平均 RT、P50/P95/P99/P999 分位耗时；
• 跨机房 Redis P99 超过 2ms 属于异常；本地缓存 P99 应小于 0.1ms；
• 读写延迟拆分：读延迟、写延迟单独统计。

3. 内存指标

• Redis 总内存占用、内存增长率；
• 大 Key 数量（>100KB）、热 key 清单；
• 内存碎片率（fragmentation ratio），超过 1.5 需优化；
• 淘汰 key 次数 evicted_keys：持续大量淘汰代表缓存容量不足或冷热策略差。

4. 集群 / 网络指标

• TCP 连接数、连接池等待队列长度；
• 网络出入带宽、包量；
• 主从同步延迟、全量同步次数；
• 槽位内存分布差值（分片倾斜度）。

5. 异常指标

• 缓存穿透次数（布隆过滤器拦截量）；
• 缓存击穿：同一 key 并发等待锁次数；
• 缓存雪崩：批量 key 同时过期触发的主存储请求尖峰；
• 超时请求数、Redis 报错（连接失败、OOM、命令阻塞）。