一、定义

热 Key 是 Redis 高并发场景中，访问频率显著高于其他键的特殊键，其核心问题是 “单键请求过度集中于某一 Redis 节点”，导致该节点 CPU、内存资源占用飙升，进而引发节点响应延迟、命令阻塞，甚至拖累整个集群稳定性。

1.1 核心判定特征

  • 访问频率：单键 QPS（每秒请求数）占集群总 QPS 的 10% 以上，或单键每秒访问次数持续超过 1000 次（具体阈值可根据集群规模调整，小集群可适当降低）；

  • 节点资源占用：热 Key 所在节点的 CPU 使用率（系统 CPU + 用户 CPU）持续超过 80%（Redis 为单线程模型，CPU 满负荷会阻塞所有命令执行），或该节点内存占用远超集群内其他节点；

  • 业务影响范围：热 Key 关联核心功能，若其所在节点故障，会导致大范围业务不可用，而非局部功能异常。

二、识别方法

识别的核心目标是 “精准定位热 Key 及所在节点”，常用方法按 “轻量临时→专业长期” 分为两类：

轻量临时识别（依赖 Redis 原生命令）

步骤 1：获取集群性能基线

  • 执行redis-cli info stats命令，查看total_commands_processed（总命令数）、instantaneous_ops_per_sec（实时 QPS），明确集群整体请求规模，为后续判定热 Key 提供基准；

步骤 2：捕捉高频键

  • 执行redis-cli monitor命令（单次执行时间不超过 10 秒，避免阻塞 Redis），实时打印所有命令，筛选重复出现频次极高的键；或通过redis-cli info commandstats查看各命令调用次数，结合命令关联的键，定位高频访问的键；

  • 注意事项：monitor命令在生产环境仅可临时使用，不可长时间执行，否则会占用大量 CPU 资源。

三、处理方案

处理核心思路是 “分散热 Key 的请求压力”，优先采用 Redis 内置机制，再补充应用层优化，以下为 4 类通用方案：

方案 1：热 Key 分片

  • 原理：将单个热 Key 拆分为多个子 Key，分散存储到不同 Redis 节点，使每个子 Key 的请求量降至原热 Key 的 1 / 分片数，缓解单节点压力；

  • 实施步骤：

    确定分片数量（根据热 Key 原 QPS 与单节点承载能力计算，通常为 5-20 个）；

    采用 “取模” 或 “一致性哈希” 算法生成子 Key（确保请求均匀分布）；

    数据写入时，将原热 Key 的 Value 同步写入所有子 Key；

    应用端请求时，通过固定算法（如基于请求参数取模）选择对应子 Key 访问；

  • 注意事项：适合读多写少场景；若需更新数据，需同步更新所有子 Key（可通过批量命令减少操作次数）；避免子 Key 数量过多导致内存冗余。

方案 2：主从分流

  • 原理：利用 Redis 主从架构，让主节点处理热 Key 的写请求，从节点处理热 Key 的读请求，将读压力分散到多个从节点；

  • 实施步骤：

    部署主从集群（1 主 N 从，N≥2），确保主从数据同步正常（通过redis-cli info replication查看同步状态）；

    配置从节点为只读模式（通过slave-read-only yes开启，Redis 2.8 + 支持）；

    应用端将热 Key 的读请求路由到从节点（采用轮询或随机算法分发），写请求路由到主节点；

  • 注意事项：需监控主从同步延迟（避免从节点返回旧数据）；若主节点故障，需通过集群机制切换主节点，确保写请求正常处理。

方案 3：应用层本地缓存

  • 原理：在应用服务本地（如进程内存）缓存热 Key 的 Value，使部分读请求直接在本地响应，无需访问 Redis，减少 Redis 节点的请求量；

  • 实施步骤：

    选择轻量级本地缓存组件（需支持过期时间、内存限制）；

    应用端首次访问热 Key 时，从 Redis 获取 Value 并写入本地缓存，同时设置过期时间（短于 Redis 中热 Key 的过期时间，避免数据不一致）；

    后续读请求优先查询本地缓存，命中则直接返回，未命中再访问 Redis 并更新本地缓存；

  • 注意事项：适合 Value 更新频率低的场景；需控制本地缓存内存占用（避免应用内存溢出）；若 Redis 中热 Key 更新，需主动失效对应本地缓存（避免脏数据）。

方案 4：限流保护

  • 原理：对热 Key 的请求量设置阈值，当请求超过阈值时，拒绝部分非核心请求或返回默认结果，避免 Redis 节点被过量请求压垮；

  • 实施步骤：

    基于 Redis 的 Lua 脚本或应用层限流组件，为热 Key 设置 QPS 阈值（根据节点承载能力确定）；

    当热 Key 的请求量达到阈值时，触发限流逻辑（如返回默认值、提示 “服务繁忙”）；

    监控限流触发频率，动态调整阈值（避免过度限流影响正常业务）；

  • 注意事项：需区分核心与非核心请求（优先保障核心请求）；限流逻辑需轻量化（避免自身成为性能瓶颈）。

四、处理热 Key 的核心原则

先识别后处理：必须通过监控工具量化热 Key 的访问频率、命令类型，避免盲目优化；

优先用 Redis 内置机制：如主从、集群分片，再补充应用层方案（本地缓存、限流），减少外部依赖；

匹配热 Key 特征：读多写少场景优先用 “主从分流 + 本地缓存”，写多读少场景优先用 “集群分片 + 批量操作”；

保障数据一致性：若涉及多节点 / 本地缓存，需明确数据更新策略（如同步更新、过期时间控制），避免脏数据。