华为云 DCS Redis 缓存实践：选型、Key 设计与常见踩坑

前言

上个月把一个后台管理系统的查询接口从"直连数据库"改造成"先查缓存"之后，接口 P95 延迟从 800ms 左右降到了 50ms 以内。这里记录一下我在华为云 DCS（分布式缓存服务，Redis 版）上踩过的几个坑，希望对同样要上缓存的同学有帮助。

一、规格选型：先估算内存，别按拍脑袋买

Redis 是内存型服务，规格选小了扩容麻烦，选大了白花钱。我的估算方法是：

1. 算热数据量：列出要缓存的 key 类型，估算每个 key 的 value 大小（序列化后）乘以数量。比如 5 万个商品详情，每个 2KB，就是 100MB 起步；
2. 留 30%~50% 余量：给过期碎片、临时 key、业务增长留空间；
3. 带宽和连接数别忽略：高频小请求场景，网络吞吐和最大连接数可能比内存先到瓶颈。

最终我选了 2G 主备版，实际峰值内存使用不到 40%，足够支撑当前业务，后续有控制台一键升配。

二、key 设计：规范比技巧更重要

缓存出问题，十有八九出在 key 设计上。我给自己定了三条规矩：

• 命名分层：业务:实体:ID，例如 cms:article:10086，方便排查和批量管理；
• value 尽量小：只缓存页面真正用到的字段，不要整个对象一把塞进去；
• 过期时间加随机抖动：固定 3600s 会导致同一批 key 同时过期，瞬间打穿到数据库。加个 3600 + random(0, 300) 就稳很多。

另外一定要处理大 key：单 value 超过 10KB 的要重点审视，列表类数据用 hash 或分页存储，避免慢命令阻塞整个实例。

三、缓存穿透、击穿、雪崩的朴素解法

这三个词大家都不陌生，我在生产里的做法其实很朴素：

• 穿透（查不存在的数据）：查库为空也缓存一个空对象，过期时间设短一点（比如 60s）；
• 击穿（热点 key 过期瞬间大量请求打库）：先查缓存，未命中就加分布式锁（SET key value NX EX 3），只让一个请求回源，其他请求短暂等待；
• 雪崩（大批 key 同时失效）：前面说的过期时间随机化已经覆盖了一大部分，再配上主备版实例，可用性就基本有保障了。

四、几个真实的坑

1. 序列化不一致：Java 端写、Node 端读，两边序列化格式不同导致 value 乱码。我们的解法是统一用 JSON 字符串存储，牺牲一点体积换互操作性。
2. 内存被大 key 吃满触发逐出：默认淘汰策略是 allkeys-lru，看似自动，实则意味着你的业务数据可能被"静默"淘汰，命中率悄悄下降。监控里一定要看内存使用率和命中率两条曲线。
3. 直连地址和代理地址混用：主备版通过代理地址访问更稳，主备切换时客户端不用感知。一开始我图省事直连主节点，切换演练时业务抖了一下，后来统一切到代理地址。

五、小结

上缓存这件事，收益是立竿见影的，但前提是 key 设计规范、过期策略合理、监控到位。DCS 控制台自带的监控面板（内存、命中率、连接数、慢日志）建议配成日常巡检项。把这三件事做扎实，缓存就是一个"低风险高收益"的优化点。

以上是我这段时间的实践记录，欢迎交流。