热 key 问题就是突然有几十万的请求去访问 redis 上的某个特定 key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台 redis 服务器直接宕机。
凭借业务经验，进行预估哪些是热 key。比如某些商品要做秒杀，则商品 key 就可以判断为热 key，但并非所有业务都能预估出热 key。
在客户端进行收集。比如在 redis 客户端执行 redis 命令之前，加入一行代码进行命令数据收集，然后通过网络将收集的命令发送出去，缺点是对客户端代码有入侵。
在 Proxy 层做收集，但是并非所有的 redis 集群都有 proxy。
用 redis 自带命令，monitor 命令可以实时抓取出 redis 服务器接收到的命令，然后写代码统计出热 key 是啥，不过高并发条件下，有内存暴增的隐患，影响 redis 的性能。redis4.0.3 提供了客户端热点 key 发现功能，如果 key 比较多，执行比较慢。
自己抓包评估，redis 客户端使用 TCP 协议与服务端进行交互，通信协议采用 RESP，自己写程序监听端口，按照 RESP 协议规则解析数据进行分析，不过开发成本较高，不易维护。
增加二级缓存，发现热 key 以后，可以把热 key 数据加载到系统 JVM 并设置合适的缓存过期时间，针对热 key 的请求就会直接分散到各业务服务器上，防止所有请求同时访问同一台 redis。
备份热 key。可以把热点 key 的数据备份到所有 redis 的集群节点中，可以通过在热点 key 后面拼接集群节点编号，然后将这些备份 key 分散到所有集群节点中，客户端访问热点 key 的时候也在热点 key 后面随机拼接集群节点编号，将热点 key 的请求分散到不同集群节点上。
作者：京东零售 曹志飞
来源：京东云开发社区 转载请注明来源