京东热点缓存探测系统JDhotkey架构剖析

热点探测使用场景

  • MySQL 中被频繁访问的数据 ,如热门商品的主键 Id
  • Redis 缓存中被密集访问的 Key,如热门商品的详情需要 get goods$Id
  • 恶意攻击或机器人爬虫的请求信息,如特定标识的 userId、机器 IP
  • 频繁被访问的接口地址,如获取用户信息接口 /userInfo/ + userId

使用热点探测的好处

提升性能,规避风险

对于无预期的热数据(即突发场景下形成的热 Key),可能会对业务系统带来极大的风险,可将风险分为两个层次:

  1. 对数据层的风险
    正常情况下,Redis 缓存单机就可支持十万左右 QPS,并能通过集群部署提高整体负载能力。对于并发量一般的系统,用 Redis 做缓存就足够了。但是对于瞬时过高并发的请求,因为 Redis 单线程原因会导致正常请求排队,或者因为热点集中导致分片集群压力过载而瘫痪,从而击穿到 DB 引起服务器雪崩。
  2. 对应用服务的风险
    每个应用在单位时间所能接受和处理的请求量是有限的,如果受到恶意请求的攻击,让恶意用户独自占用了大量请求处理资源,就会导致其他人畜无害的正常用户的请求无法及时响应。
    因此,需要一套动态热 Key 检测机制,通过对需要检测的热 Key 规则进行配置,实时监听统计热 Key 数据,当无预期的热点数据出现时,第一时间发现他,并针对这些数据进行特殊处理。如本地缓存、拒绝恶意用户、接口限流 / 降级等

京东热点探测

  1. 热点规则:配置热 Key 的上报规则,圈出需要重点监测的 Key
  2. 热点上报:应用服务将自己的热 Key 访问情况上报给集中计算单元
  3. 热点统计:收集各应用实例上报的信息,使用滑动窗口算法计算 Key 的热度
  4. 热点推送:当 Key 的热度达到设定值时,推送热 Key 信息至所有应用实例
  5. 热点缓存:各应用实例收到热 Key 信息后,对 Key 值进行本地缓存

client

热key上报 ,key的访问次数积攒起来,等待每半秒发送一次。

为了防止阻塞IKeyCollector使用两个ConcurrentHashMap切换,实现轮流提供读写、暂存key的操作。上报时譬如采用定时器,每隔0.5秒调度一次push方法 。在上报过程中,不应阻塞写入操作。所以计划采用2个HashMap加一个atomicLong,如奇数时写入map0,为1写入map1,上传后会清空该map。

热key新增/删除,监听有新key推送事件,收到来自于worker的新增key

worker

收集各应用实例上报的信息,使用滑动窗口算法计算 Key 的热度。当 Key 的热度达到设定值时,推送热 Key 信息至所有应用实例。和dashboard那边的推送主要区别在于,给app 推送每10ms一次dashboard 那边1s一次

相关推荐
白-胖-子5 小时前
深入剖析大模型在文本生成式 AI 产品架构中的核心地位
人工智能·架构
Pomelo_刘金8 小时前
用 DDD 把「闹钟」需求一点点捏出来
架构·rust·领域驱动设计
Pomelo_刘金8 小时前
Clean Architecture 整洁架构:借一只闹钟讲明白「整洁架构」的来龙去脉
后端·架构·rust
碳酸的唐9 小时前
Inception网络架构:深度学习视觉模型的里程碑
网络·深度学习·架构
半新半旧9 小时前
python 整合使用 Redis
redis·python·bootstrap
daixin884811 小时前
什么是缓存雪崩?缓存击穿?缓存穿透?分别如何解决?什么是缓存预热?
java·开发语言·redis·缓存
五点六六六12 小时前
前端常见的性能指标采集
前端·性能优化·架构
daixin884813 小时前
Redis过期数据的删除策略是什么?有哪些?
数据库·redis·缓存
平凡之大路14 小时前
【企业架构】TOGAF概念之二
架构·togaf·企业架构
EmpressBoost14 小时前
谷粒商城170缓存序列化报错
java·spring·缓存