关于java:缓存热点缓存穿透终极解决方案看过来

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

很多公司的缓存都是基于 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 的我的项目地址

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 框架落地。

为此咱们基于 Hotkey client 研发了 Hotlink 客户端框架，该客户端框架能让 Hotkey 更完满的落地，加强了 Hotkey 客户端的能力。

Hotlink 的我的项目地址：https://gitee.com/openbeast/h…

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

业务接入简略，只须要一个标注，1 分钟就能使你的 RPC 接口接入热点探测框架
启动时动静扫描所有 Hotlink 标注的接口，创立动静代理
基于动静代理去对接口做加强，实践上只有有接口，就反对任何 RPC 框架
本地办法只有有接口，也能应用热点探测

联合 Hotkey 的架构图，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 到本人公司的私库)

<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
相干实现会被注入 Spring 上下文中

在标注接口的时候，尽量标注在肯定工夫范畴内是幂等的接口。比方会员查问，sku 信息查问，相干流动信息的查问，这些信息在肯定工夫范畴内不会频繁变动，那么就适宜做热点探测。

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

我是一个开源作者，也是一名内容创作者。「元人部落」是一个保持做原创的技术科技分享号，会始终分享原创的技术文章，陪你一起成长。

关于java:缓存热点缓存穿透终极解决方案看过来

背景

解决方案

碰到的问题

Hotlink 客户端

Hotlink 如何应用

应用 Hotlink 须要留神的事项

对于我