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

背景

前不久,因为公司业务需要,需要解决在大促场景下后端业务的热点缓存问题,所以研究了下缓存热点解决方案。

很多公司的缓存都是基于redis来做的,redis的性能其实已经足以能应付大部分的场景,但是对于大促期间或者活动抢购期间的某个爆品,可能会出现在几秒时间内流入大量的流量,由于某个爆品的数据在redis cluster场景下会按照hash规则被存放在某个redis分片上,那么这几秒的流量都会压到这个redis分片,从而在瞬间会导致这个redis分片的瘫痪,也会影响后续的redis请求的阻塞。

还有个场景,就是公司并不是所有的服务端逻辑都有缓存。在流量起来的时候,这些热key还是会压到数据库层面。导致压力。

解决方案

一般常见的解决方案就是增加二级缓存,对于热点数据写到jvm里一份。设置过期时间。但是什么时候设置,热点如何探测,规则如何设置,过期时间设置多少。甚至于如何快速落地,这都是需要研究的问题。

我们希望有一个统一的方案来解决这些问题。

我们发现了Hotkey这款开源框架。

Hotkey源于京东,hotkey能自动地对任意突发性的无法预知的热点数据,按照配置的规则进行毫秒级别的探测,探测到的热数据会推送到所有的服务端JVM中,大幅减轻对后端数据层的冲击。这些热数据在整个微服务集群会保持一致性,当热点消失的时候,自动从jvm中进行移除。

Hotkey的特性能很好的实现我们的目标。并且京东内部也用Hotkey实战了618大促,稳定性有所保障。

Hotkey的架构图(以下图引用自Hotkey在Gitee的主页)

缓存热点,缓存穿透,终极解决方案看过来_第1张图片

Hotkey整个架构共分为以下几个部分:

worker:负责采集上报信息,根据规则计算出热点信息,规则来自于etcd。热点信息推送到client里

client: 每个client连接etcd,获取每个worker的ip和端口,和worker保持长链接,接受worker的热点信息推送

etcd:分布式的协调者,接受每个worker的心跳上报,并把worker的连接信息推送给client。监听规则的改变,推送给worker

dashboard:ui界面,查看实例以及worker的状态,查看以及修改规则数据。规则存到mysql,同时由etcd推送给worker

下面给出hotkey的项目地址

https://gitee.com/jd-platform...

关于Hotkey的介绍和如何搭建,大家可以看这篇文章来了解,这里就不多赘述。

https://mp.weixin.qq.com/s/xO...

碰到的问题

我们在搭建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的项目地址:https://gitee.com/openbeast/h...

该客户端框架有以下特点:

  • 业务接入简单,只需要一个标注,1分钟就能使你的RPC接口接入热点探测框架
  • 启动时动态扫描所有Hotlink标注的接口,创建动态代理
  • 基于动态代理去对接口做增强,理论上只要有接口,就支持任何RPC框架
  • 本地方法只要有接口,也能使用热点探测

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

缓存热点,缓存穿透,终极解决方案看过来_第2张图片

Hotlink如何使用

第一步

按照Hotkey的部署要求,搭建好worker和dashboard。具体方式请参照:

https://gitee.com/jd-platform...

同时为了方便大家搭建,我把编译好的worker和dashboard包也进行了上传

worker下载地址:

公网IP版本(适合调试用,本地能连上worker):

https://gitee.com/openbeast/h...

内网IP版本:

https://gitee.com/openbeast/h...

Dashboard:

https://gitee.com/openbeast/h...

第二步

本地业务项目依赖jar包(此jar包并未上传到中央仓库,需要大家自己deploy到自己公司的私库)


  com.thebeastshop
  hotlink-spring-boot-starter
  1.0.12

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

1.2.70
29.0-jre

第三步

本地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信息查询,相关活动信息的查询,这些信息在一定时间范围内不会频繁变动,那么就适合做热点探测。

非幂等性的接口,即便是相同参数,每次返回也会不一样。那就不建议做热点探测。比如下单,库存的查询,余额的查询。这样的接口如果一旦被升级成热点。那会影响业务界面的正确性和后续逻辑的判断错误。

关于我

我是一个开源作者,也是一名内容创作者。「元人部落」是一个坚持做原创的技术科技分享号,会一直分享原创的技术文章,陪你一起成长。
缓存热点,缓存穿透,终极解决方案看过来_第3张图片

你可能感兴趣的:(缓存热点,缓存穿透,终极解决方案看过来)