京东的热点key探测系统发布,单机 QPS 提升至 37 万

公众号程序猿DD

共 1418字,需浏览 3分钟

 ·

2020-10-01 05:15

点击上方蓝色“程序猿DD”,选择“设为星标”

回复“资源”获取独家整理的学习资料!

发布

HotKey在618稳定版0.2版基础上,引入了protobuf序列化方式,并优化了传输对象。

worker单机性能从618大促稳定版的20万QPS稳定,30万极限,提升至30万稳定,37万极限。且cpu峰值下降了15%。

该中间件目前在京东内部10余个核心部门接入使用,服务于京东App服务端前台、中台,数据中台等多个核心业务线。

架构

京东APP后台热数据探测框架,历经多次高压压测和2020年京东618大促考验。在上线运行的这段时间内,每天探测的key数量数十亿计,精准捕获了大量爬虫、刷子用户,另准确探测大量热门商品并毫秒级推送到各个服务端内存,大幅降低了热数据对数据层的查询压力,提升了应用性能。


该框架历经多次压测,性能指标主要有两个:


1 探测性能:8核单机worker端每秒可接收处理16万个key探测任务,16核单机至少每秒平稳处理30万以上,实际压测达到37万,CPU平稳支撑,框架无异常。


2 推送性能:在高并发写入的同时,对外推送目前性能约平稳推送每秒10-12万次,譬如有1千台server,一台worker上每秒产生了100个热key,那么这1秒会平稳推送100 * 1000 = 10万次,10万次推送会明确在1s内全部送达。如果是写入少,推送多,以纯推送来计数的话,该框架每秒可稳定对外推送40-60万次平稳,80万次极限可撑几秒。


在真实业务场景中,可用1:1000的比例,即1台worker支撑1000台业务服务端的key探测任务,即可带来极大的数据存储资源节省(如对redis集群的扩充)。

介绍

对任意突发性的无法预先感知的热点请求,包括并不限于热点数据(如突发大量请求同一个商品)、热用户(如爬虫、刷子)、热接口(突发海量请求同一个接口)等,进行毫秒级精准探测到。然后对这些热数据、热用户等,推送到该应用部署的所有机器JVM内存中,以大幅减轻对后端数据存储层的冲击,并可以由客户端决定如何使用这些热key(譬如对热商品做本地缓存、对热用户进行拒绝访问、对热接口进行熔断或返回默认值)。这些热key在整个应用集群内保持一致性。

核心功能:热数据探测并推送至集群各个服务器。

适用场景:

1 mysql热数据本地缓存

2 redis热数据本地缓存

3 黑名单用户本地缓存

4 爬虫用户限流

5 接口、用户维度限流

6 单机接口、用户维度限流限流

7 集群用户维度限流

8 集群接口维度限流

界面效果

源码&文章参考:https://gitee.com/jd-platform-opensource/hotkey


往期推荐

干掉Navicat:正版 MySQL 官方客户端真香!

赠书:算法与数据中台“网约车业务实践”

HTTPS证书知识扫盲

这样配置,让你的 IDEA 好用到飞起来!

中国工商银行已使用OceanBase!

陌陌开源合规审计平台 Bombus


专注于「开发者」综合成长的深度星球
限时优惠进行中
热门分享内容回顾
- 社会人0924期:新手架构最容易忽略的点!
- 技术人0725期:说说我在银行科技部门学到的东西!
浏览 29
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报