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 有五种方式： 6. 临时排查可以用 redis-cli —hotkeys 一键扫描，也可以临时开 MONITOR 命令实时抓请求统计； 7. 常态化可以在 Redis 客户端埋点计数统计，或者依靠 Codis、云 Redis 的 Proxy 代理层自动汇总 QPS； 8. 也可以直接用云 Redis 和运维平台自带的热点 Key 可视化报表，快速定位流量倾斜的热 Key。 9. 如何解决热key问题？ 10. ● 接入本地 JVM 一级缓存：在业务服务本地做 Caffeine/Guava 本地缓存，把热 Key 缓存到应用内存，大量读请求直接不走 Redis，从本地内存返回，从源头拦截热点流量，成本最低、效果最好；设置短过期时间，保证数据弱一致性即可满足大部分业务。 11. ● 热key分片复制：Redis 集群槽位固定，热 Key 无法自动迁移分流。可把热 Key 复制多份生成 foo1、foo2 等同值 Key（名字不同），迁移到不同集群分片；客户端请求随机路由到不同副本，分摊单分片压力。 12. ● 使用读写分离架构。针对读多写少的热 Key，搭建 Redis 主从架构，主节点负责写，从节点负责读；通过 Proxy、LVS 做读请求负载均衡，横向扩容从节点分担读压力；缺点是会增加架构和运维复杂度，故障风险也会提升。
《参考解析》
-
Redis核心：Redis常用数据结构：String/Hash/List/Set/ZSet。持久化：RDB（定期快照，恢复快，数据可能丢失）和AOF（追加日志，数据安全，文件大）。缓存穿透用布隆过滤器；缓存雪崩加随机过期时间+多级缓存；缓存击穿用互斥锁或逻辑过期。分布式锁用SET key value NX PX + Lua脚本保证原子释放。
-
JVM与GC：JVM内存模型：堆（对象分配，GC管理）、方法区（类信息、常量池）、虚拟机栈（栈帧/局部变量/操作数栈）、本地方法栈、程序计数器。GC算法：标记-清除（内存碎片）、标记-整理（无碎片，但移动对象）、复制（新生代）。G1按Region划分堆，预测停顿时间。