java八股学习2 -热key问题

什么是热点key
通常以其接收到的Key被请求频率来判定，例如：
● QPS集中在特定的Key：Redis实例的总QPS很高，单个 Key 占了绝大部分请求流量。
● 带宽使用率集中在特定的Key：对一个拥有上千个成员且总大小为1 MB的HASH Key每秒发送大量的HGETALL操作请求。
● CPU使用时间占比集中在特定的Key：对一个拥有数万个成员的Key（ZSET类型）每秒发送大量的ZRANGE操作请求。
 热 Key 会导致 Redis 集群分片压力不均，单节点 CPU、带宽被打满，引发请求超时、甚至连锁缓存故障。 

如何识别 哪些是 Redis热点 Key
识别热点 Key 有五种方式：
临时排查可以用 redis-cli --hotkeys 一键扫描，也可以临时开 MONITOR 命令实时抓请求统计；
常态化可以在 Redis 客户端埋点计数统计，或者依靠 Codis、云 Redis 的 Proxy 代理层自动汇总 QPS；
也可以直接用云 Redis 和运维平台自带的热点 Key 可视化报表，快速定位流量倾斜的热 Key。

如何解决热key问题？
● 接入本地 JVM 一级缓存：在业务服务本地做 Caffeine/Guava 本地缓存，把热 Key 缓存到应用内存，大量读请求直接不走 Redis，从本地内存返回，从源头拦截热点流量，成本最低、效果最好；设置短过期时间，保证数据弱一致性即可满足大部分业务。
● 热key分片复制：Redis 集群槽位固定，热 Key 无法自动迁移分流。可把热 Key 复制多份生成 foo1、foo2 等同值 Key（名字不同），迁移到不同集群分片；客户端请求随机路由到不同副本，分摊单分片压力。
● 使用读写分离架构。针对读多写少的热 Key，搭建 Redis 主从架构，主节点负责写，从节点负责读；通过 Proxy、LVS 做读请求负载均衡，横向扩容从节点分担读压力；缺点是会增加架构和运维复杂度，故障风险也会提升。
#发面经攒人品#