云数据库 Redis 热点 Key 排查首选通过控制台监控或慢日志定位高频访问 Key，优化方案包括本地缓存、Key 拆分或读写分离。注意开启热 Key 分析可能增加实例负载，建议在业务低峰期操作。
先说结论：热点 Key 会导致单分片流量不均，引发拥塞，需结合监控与日志定位。
- 先定位：通过云控制台热 Key 分析功能或大 Key 日志确认目标 Key。
- 先做：优先接入本地缓存或对 Key 添加随机后缀拆分流量。
- 再验证：观察实例 CPU 使用率、带宽及命令延迟是否回落。
命令速用版
生产环境严禁直接使用 MONITOR 命令，会阻塞服务。建议使用云厂商控制台自带的热 Key 分析功能，或在低峰期使用 redis-cli 采样。
# 仅建议在测试环境或低峰期采样使用，部分 Redis 版本支持
redis-cli `--hotkeys`
# 查看慢日志，辅助判断是否存在耗时操作加剧热点影响
redis-cli slowlog get 10为什么会这样
热点 Key 本质是请求倾斜，导致单分片 CPU 或带宽打满。Redis 集群模式下 Key 分布在不同槽位，热点 Key 集中在一个槽，该槽所在节点压力大，而其他节点空闲，造成整体性能瓶颈。
分步处理
步骤 1：确认热点 Key
登录云数据库控制台，找到实例监控页面，查看“热 Key 分析”或“大 Key 分析”报表。如果没有自带功能，需联系技术支持开启抓包分析，避免自行部署抓包工具影响网络。
步骤 2：实施本地缓存
在应用层引入本地缓存（如 Guava Cache、Caffeine），将热点 Key 数据缓存在应用内存中。设置较短的过期时间（如 1-5 秒），防止数据不一致。适用场景：读多写少且允许短暂不一致的数据。
步骤 3：拆分热点 Key
对于必须访问 Redis 的场景，在 Key 名称后添加随机后缀，将单个 Key 拆分为多个 Key（如 key_1, key_2...）。读取时随机请求其中一个，写入时更新所有分片。适用场景：计数器、高频配置项。
步骤 4：启用读写分离
如果云数据库支持读写分离架构，将读请求路由到只读副本。注意主从同步延迟可能导致读取旧数据，需评估业务容忍度。
怎么验证是否生效
操作完成后，回到云控制台监控页面，观察以下指标变化：
- CPU 使用率：热点分片的 CPU 峰值应明显下降。
- 网络带宽：实例总带宽及单节点带宽波动应趋于平稳。
- 命令延迟：平均延迟和高百分位延迟（如 P99）应回落至正常基线。
如果指标未改善，检查本地缓存命中率或 Key 拆分逻辑是否均匀。
常见坑
- 禁用 MONITOR：生产环境使用
MONITOR命令会导致 Redis 吞吐量急剧下降，甚至服务不可用。 - 直接删除 Key：不要直接删除正在被高频访问的 Key，可能引发缓存穿透，导致数据库压力激增。
- 缓存一致性：使用本地缓存时，若后端数据变更，需确保本地缓存能及时失效，否则会出现数据错误。
- 拆分不均：Key 拆分时随机算法需均匀，避免产生新的次热点 Key。
常见问题
生产环境能用 MONITOR 命令抓热点吗？
不能，MONITOR 会阻塞 Redis 服务，导致性能急剧下降，请使用云控制台分析功能。
Key 拆分后写入数据怎么处理？
写入时需要更新所有拆分后的 Key，或者采用异步更新策略，确保读取时能拿到最新数据。
云控制台的热 Key 分析准确吗？
云厂商通常采用采样或流量镜像技术，数据具有参考价值，但可能存在秒级延迟，不适合实时性极高的场景。
本地缓存过期时间设置多少合适？
公开资料中没有看到可靠的量化数据，通常建议根据业务容忍度设置 1-10 秒，平衡一致性与防护效果。