尽管沉淀 level
获赞
88
粉丝
35
关注
111
看过 TA
1337
门头沟学院
2027
Java
IP属地:广东
停止无意义的思考,just start do it
私信
关注
05-18 12:03
门头沟学院 Java
0 点赞 评论 收藏
分享
05-03 11:04
门头沟学院 Java
0 点赞 评论 收藏
分享
05-02 22:48
门头沟学院 Java
什么是热点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 做读请求负载均衡,横向扩容从节点分担读压力;缺点是会增加架构和运维复杂度,故障风险也会提升。
查看3道真题和解析
0 点赞 评论 收藏
分享
04-29 09:03
门头沟学院 Java
0 点赞 评论 收藏
分享

创作者周榜

更多
关注他的用户也关注了:
牛客网
牛客网在线编程
牛客网题解
牛客企业服务