缓存热点,缓存穿透,终极解决方案看过来

业界 作者:SegmentFault 2021-08-28 19:13:37 阅读:35
推广:爱奇艺黄金会员年卡¥128元,送QQ音乐会员。
作者:铂赛东
来源:SegmentFault 思否社区

背景

前不久,因为公司业务需要,需要解决在大促场景下后端业务的热点缓存问题,所以研究了下缓存热点解决方案。
很多公司的缓存都是基于redis来做的,redis的性能其实已经足以能应付大部分的场景,但是对于大促期间或者活动抢购期间的某个爆品,可能会出现在几秒时间内流入大量的流量,由于某个爆品的数据在redis cluster场景下会按照hash规则被存放在某个redis分片上,那么这几秒的流量都会压到这个redis分片,从而在瞬间会导致这个redis分片的瘫痪,也会影响后续的redis请求的阻塞。
还有个场景,就是公司并不是所有的服务端逻辑都有缓存。在流量起来的时候,这些热key还是会压到数据库层面。导致压力。

解决方案

一般常见的解决方案就是增加二级缓存,对于热点数据写到jvm里一份。设置过期时间。但是什么时候设置,热点如何探测,规则如何设置,过期时间设置多少。甚至于如何快速落地,这都是需要研究的问题。
我们希望有一个统一的方案来解决这些问题。
我们发现了Hotkey这款开源框架。
Hotkey源于京东,hotkey能自动地对任意突发性的无法预知的热点数据,按照配置的规则进行毫秒级别的探测,探测到的热数据会推送到所有的服务端JVM中,大幅减轻对后端数据层的冲击。这些热数据在整个微服务集群会保持一致性,当热点消失的时候,自动从jvm中进行移除。
Hotkey的特性能很好的实现我们的目标。并且京东内部也用Hotkey实战了618大促,稳定性有所保障。
Hotkey的架构图(以下图引用自Hotkey在Gitee的主页)


Hotkey整个架构共分为以下几个部分:
worker:负责采集上报信息,根据规则计算出热点信息,规则来自于etcd。热点信息推送到client里
client:每个client连接etcd,获取每个worker的ip和端口,和worker保持长链接,接受worker的热点信息推送
etcd:分布式的协调者,接受每个worker的心跳上报,并把worker的连接信息推送给client。监听规则的改变,推送给worker
dashboard:ui界面,查看实例以及worker的状态,查看以及修改规则数据。规则存到mysql,同时由etcd推送给worker
下面给出hotkey的项目地址
hotkey: 京东App后台中间件,毫秒级探测热点数据,毫秒级推送至服务器集群内存,大幅降低热key对数据层查询压力 (gitee.com)
关于Hotkey的介绍和如何搭建,大家可以看这篇文章来了解,这里就不多赘述。
京东毫秒级热key探测框架设计与实践,已实战于618大促 (qq.com)

碰到的问题

我们在搭建hotkey环境和落地实施中,碰到2个问题:
  • Hotkey虽然开源,但是相关client jar包并未上传中央仓库,dashboard和worker启动包也并未提供下载。需要下载源码进行编译,编译过程中也碰到一些包依赖的问题。

  • Hotkey的client jar只提供了api级别的方法供程序使用,如果要落地到业务项目中,需要大规模的修改代码才能实施。


我们更希望提供一种侵入更少的方式,在RPC以及接口的层面进行代理包装。使用者无论使用什么RPC框架,只是在相关接口上打上标注,而无需动业务的任何代码。就可以在这个接口层面进行检测热点。如果该接口的某个参数为热点的话,就自动进行代理,走jvm的热点数据,等热点消除后,依旧走原来的调用。
如果你觉得上述的描述过于难以理解的话,那么直白点说就是:
比如某个活动大促期间有个商品S001进行抢购,有大量的流量进入了商品详情页面。这个商品详情RPC方式调用了商品服务的以下接口方法获取商品信息:
public interface ProductService{
  SkuInfo getSkuInfo(String skuCode);
}

那么我们希望只在这个接口上打上标注。就可以适配Hotkey框架进行探测热点,当商品S001被大量请求时,S001这个商品就可以成为热点,这时getSkuInfo这个接口就会被自动代理,从而只从Jvm中获取数据,而不会真正走RPC调用。等热点消除后,这个接口依旧调用RPC获取数据。
这样的方式无疑侵入性更小,更容易使Hotkey框架落地。

Hotlink客户端

为此我们基于Hotkey client研发了Hotlink客户端框架,该客户端框架能让Hotkey更完美的落地,增强了Hotkey客户端的能力。
Hotlink的项目地址:hotlink: Hotlink框架是一个基于Hotkey框架的客户端增强版实现,该客户端框架能让Hotkey更完美的落地,增强了Hotkey客户端的能力。(gitee.com)
该客户端框架有以下特点:
  • 业务接入简单,只需要一个标注,1分钟就能使你的RPC接口接入热点探测框架

  • 启动时动态扫描所有Hotlink标注的接口,创建动态代理

  • 基于动态代理去对接口做增强,理论上只要有接口,就支持任何RPC框架

  • 本地方法只要有接口,也能使用热点探测






结合Hotkey的架构图,Hotlink在整个架构图中的位置如下图:

Hotlink如何使用

第一步
按照Hotkey的部署要求,搭建好worker和dashboard。具体方式请参照:
hotkey: 京东App后台中间件,毫秒级探测热点数据,毫秒级推送至服务器集群内存,大幅降低热key对数据层查询压力 (gitee.com)
第二步
本地业务项目依赖jar包(此jar包并未上传到中央仓库,需要大家自己deploy到自己公司的私库)
<dependency>
  <groupId>com.thebeastshop</groupId>
  <artifactId>hotlink-spring-boot-starter</artifactId>
  <version>1.0.12</version>
</dependency>

hotlink需要的fastjson和groovy版本有点要求,如果你项目中的这2个包版本过低又同时覆盖了hotlink的传递依赖包时,需要额外指定版本:
<fastjson.version>1.2.70</fastjson.version>
<guava.version>29.0-jre</guava.version>

第三步
本地springboot配置文件里加入参数
#此app-name不配置的话,会优先读取spring.application.name属性
hotlink.app-name=test
#etcd地址和端口
hotlink.etcd-url=http://xxx.xxx.xxx.xxx:2379

第四步
在你的接口里加入标签@Hotlink
在接口上加:接口里所有的方法都会自动探测热点
在方法上加:只有这个方法会自动探测热点
比如:
public interface ProductService{
  @Hotlink
  SkuInfo getSkuInfo(String skuCode);
}

那么当某一个SKU001成为热点时,那么传入参数SKU001会自动代理从JVM里取到数据,而SKU002则继续走RPC调用。
这样就完成了所有的配置。启动皆可。

使用Hotlink需要注意的事项

由于Hotlink的实现是用动态代理来实现,只要满足这两个条件,即可在启动时会扫描器扫到:
  • 接口层面上标注@Hotlink

  • 相关实现会被注入Spring上下文中




在标注接口的时候,尽量标注在一定时间范围内是幂等的接口。比如会员查询,sku信息查询,相关活动信息的查询,这些信息在一定时间范围内不会频繁变动,那么就适合做热点探测。
非幂等性的接口,即便是相同参数,每次返回也会不一样。那就不建议做热点探测。比如下单,库存的查询,余额的查询。这样的接口如果一旦被升级成热点。那会影响业务界面的正确性和后续逻辑的判断错误。


点击左下角阅读原文,到 SegmentFault 思否社区 和文章作者展开更多互动和交流,扫描下方”二维码“或在“公众号后台回复“ 入群 ”即可加入我们的技术交流群,收获更多的技术文章~

- END -


关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

关注数据与安全,洞悉企业级服务市场:http://www.ijiandao.com/
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

图库
关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接