Discover sohutv/hotcaffeine Open Source project by @sohutv

HotCaffeine：热咖啡

高性能，高可靠的热点数据探测系统。热乎的分享文章参考：Caffeine如何变热？

架构如下：

组件介绍：

Etcd：配置中心，用于服务发现和配置等。
client：客户端SDK，用于数据收集上报和接收热key。
Worker：用于接收客户端数据上报和热key计算。
Dashboard：管理后台和数据展示。

调用流程：

Worker启动后注册到etcd。
客户端通过etcd监视worker地址。
Etcd通知客户端etcd变动。
客户端上报统计数据到worker。
Worker收到统计数据计算热key。
Worker将热key推送给客户端。
Worker将热key推送给Dashboard。

特性：

高性能：内置高性能缓存库caffeine实现数据缓存和统计。

16核32G内存的worker实例支持每秒59万key探测。
高可用：任何组件宕机或异常不影响接入业务。
准确性：采用sentinel滑窗计数，防止时间影响速率。
实时性：秒级发现推送热点数据。
扩展性：支持大规模接入，支持水平扩容。

一、环境初始化

HotCaffeine数据采用redis存储(下载链接)，故redis务必开启持久化机制。

1. redis数据初始化

redis安装配置步骤略去，安装好后初始化如下数据：

hset user [email protected] "{"userName": "[email protected]", "pwd":"hQ6xcq67rh0nn/0sl82paQ==", role:"ADMIN"}"

2. ETCD权限设置

注意etcd需要为V3版本，下载链接参考，etcd安装配置步骤略去。

etcd的安全模型如下：

HotCaffeine采用如下鉴权保障安全性：

针对客户端，需要单独的用户名和密码，但是他们共同拥有同样的角色，就是client，而client对资源/hotcaffeine/只有只读权限。注：如果每个客户端都具有单独的角色，设计过于复杂，对于内网应用来说，只读安全性应该够了。后续如果需要精细控制，客户端无需任何修改，在etcd中可以为每个业务端再分配单独的角色。
针对worker，由于是内部应用，单独建立一个worker的角色，对资源/hotcaffeine/具有读写权限。
针对dashboard，由于是内部应用，需要给各个用户赋权，故其拥有root用户和权限。

etcd权限初始化如下：

将etcd-auth.sh放到etcd安装目录下，执行。root密码输入H&O%T=C9AFF]。worker密码输入=+WK%&#*。

或者直接执行com.hotcaffeine.common.etcd.EtcdAuthInit.java

二、Dashboard使用

http://127.0.0.1:8081

用户名：[email protected] 密码：admin

1. app配置

新增app：客户端接入名称
关联app：一个app属于多个用户时，其他用户可以关联该app。

2. 规则配置

缓存规则
- name：缓存名，每条key规则都需要关联一个缓存规则。
- duration：缓存过期时间，单位：秒。
- size：缓存大小。
key规则：
```
[
    {
        "key":"*",
        "prefix":false,
        "cacheName":"default",
        "interval":1,
        "threshold":100,
        "enableLocalDetector":false,
        "topkCount":100,
        "useTopKAsHotKey":false
    }
]
```
- key：精准匹配或前缀匹配名，*表示为默认规则。
- cacheName：缓存规则的名字。
- prefix：是否为前缀匹配。
- interval：滑动窗口时间间隔。
- threshold：在interval达到threshold即变为热点数据。
- enableLocalDetector：是否开启本地检测。
- topkCount：topk的数量。
- useTopKAsHotKey：是否使用topk作为热点数据。
缓存规则和key规则是一对多的关系。

精准匹配：即直接在代码中使用key规则中配置的key，详情请参考客户端使用。

前缀匹配：如果缓存的key是有规律的，可以使用前缀匹配，假如有如下key规则：

api:user:vip

api:user

可以针对这两种key设置不同的规则，前缀匹配会优先匹配较长的串，例如：

api:user:vip:1234会优先匹配api:user:vip对应的规则，而不是api:user对应的规则。

3. 实时热点

该模块可以查看各个规则的热点数据，默认只保留1万条，如下：

点击热key名可以查看热key在各个客户的实例对应的值：

4. 调用量分布

该模块用于辅助业务发现key的分布情况，用于设置缓存大小和过期时间等重要指标，以满足某个命中率。

下面举个具体的例子来说明一下，假设业务系统在某段时间内共有如下6个key访问，访问总量为100：

那么，如果这段时间内，key6在缓存中的话，命中率就能达到50%。而key1和key2在缓存中的话，命中率仅为10%。

根据这个简单的例子，来看下调用量分布：

左边第一列是调用量，也就是上面那个例子中说的访问量。
第二列是key的数量，根据这列可以大概知道key的多少(非重复)，进而可以设置缓存大小。
第三列是调用量占比，比如以第二行的数据为例来说明一下：
- 调用量=2的key有944个，那么调用量为2的key的总调用量为1888，它占本次统计的总调用量的比例为17.95%。
- 也就是说如果把调用量为2的key都缓存下来，需要缓存大小为944，命中率为17.95%。
第四列是key的生存时间数据，可以参照个这个数据设置缓存的过期时间。

注意: 这些统计不包含已经变热的数据，建议业务方一开始把热点阈值调大，让所有的key都上报，再参考调用量分布调整缓存大小和过期时间。

5. TopK热键

默认hotkey探测热键采用的是阈值，即达到某个阈值即认为变热了。

topk作为阈值规则的补充，从另外一个维度来选择热键，它的度量指标是访问量，即访问量最高的k个键作为热键。

同样，topk统计的数据不包含已经变热的数据，默认每分钟进行一次数据统计。

此曲线图纵坐标轴含义是topk的访问量与总量的比例，即可以认为，此段时间内，如果将这些topk的键缓存下来，命中率可以达到此比例。

鼠标放到曲线点上展示的是具体的数据情况。当点击该曲线点时，可以看到具体的topk数据，如下：

这里的调用量是指从key上报开始，如果后续持续的有数据上报会持续统计。

存活时间是指从key上报开始，至统计时的时间

点击key的名字即可看到该key实时的滑动窗口数据，如下：

各项指标含义如下：

总时间窗口：在key规则里配置的滑动窗口时间。
时间窗口长度：每个时间窗口是多少ms。
- 默认如果总时间窗口为1秒，有2个滑动窗口。
- 两秒钟有四个滑动窗口。
- 3秒及以上每秒一个滑动窗口。
- 最多不能超过10秒。
生存时间：key从创建到目前一共存在的时间。
活跃时间：类似生存时间，在每分钟统计topk时此key的滑动窗口没有有效的量将会把活跃时间置0。
总调用量：key从创建导目前一共被访问的次数。

滑动窗口：

滑动窗口默认1秒钟拉取一次数据，最左边为旧的窗口，最右边为最近的窗口。
窗口虚线表示该窗口已经废弃（超过有效窗口时间的为废弃）。
窗口红色实线表示该窗口有效，窗口内文字如果红色加粗，表示该窗口正在计数。

三、客户端的使用

1.pom

<dependency>
    <groupId>com.hotcaffeine</groupId>
    <artifactId>annotation</artifactId>
    <version>1.0</version>
</dependency>

2.日志

<appender name="hotcaffeine" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOGS_DIR}/hotcaffeine.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${LOGS_DIR}/otherdays/hotcaffeine.log.%d{yyyy-MM-dd}</fileNamePattern>
        <maxHistory>10</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} {%thread} %-5level %logger{50}-%L - %msg%n</pattern>
    </encoder>
</appender>
<logger name="hotcaffeine" level="info" additivity="false">
    <appender-ref ref="hotcaffeine" />
</logger>

3.初始化

HotCaffeineDetector hotCaffeineDetector = new HotCaffeineDetector.Builder().endpoints("http://127.0.0.1:2379").appName("core.user.hotcaffeine").build();
hotCaffeineDetector.start();
HotCaffeine hotCaffeine = hotCaffeineDetector.build();

4.使用方式

/**
 * 满足热点阈值的key会返回true
 */
hotCaffeine.isHot(key)

/**
 * 此种使用方式将会把redis里满足热点阈值的数据会存储在HotCaffeine中
 */
public Video get(String key){
    return hotCaffeine.getValue(key, k->{
        return redis.get(k);
    });
}

5.异步通知

当key变成热键时，支持异步的方式进行通知，需要实现如下接口：

public interface IKeyListener {
     
    /**
     * key变热时通知，只通知一次，不会重复通知
     * 如果需要缓存hot(String key)的返回值，请将needCacheValue返回为true
     * 尽量一秒内返回
     * @param key
     * @return 需要缓存的值
     */
    public Object hot(String key);
     
    /**
     * 是否需要缓存值
     * @return 默认缓存
     */
    default boolean needCacheValue() {
        return true;
    } 
}
 
同时需要在构建HotCaffeine的时候将其传入，例如：
HotCaffeine hotCaffeine = hotCaffeineDetector.build(videoKeyListener);

6.使用精准缓存

如果想将不同的数据存储在不同的缓存中，例如用户数据存储在user的缓存，视频数据存储在video的缓存，可以按照如下步骤操作：

在缓存规则中配置两条记录：

{
    "name":"user",
    "duration":600,
    "size":1000
},
{
    "name":"video",
    "duration":60,
    "size":20000
}

在key规则中配置两条规则：

{
    "key":"video",
    "prefix":false,
    "cacheName":"video",
    "interval":1,
    "threshold":10
},
{
    "key":"user",
    "prefix":false,
    "cacheName":"user",
    "interval":5,
    "threshold":10
}

在代码中构建不同的实例，即可使用：
```
HotCaffeine videoHotCaffeine = hotCaffeineDetector.build("video");
HotCaffeine userHotCaffeine = hotCaffeineDetector.build("user");
```
用videoHotCaffeine的数据会执行video的key规则。

用userHotCaffeine的数据会执行user的key规则。

7.使用前缀匹配

前缀匹配的代码使用如下：

HotCaffeine prefixHotCaffeine = hotCaffeineDetector.buildPrefix();

即使用prefixHotCaffeine会使用key规则中prefix为true的所有规则。

四、数据统计

HotCaffeine使用了micrometer进行了各种维度的数据统计，包括如下：

缓存命中率、大小、淘汰等：

# HELP cache_eviction_weight The sum of weights of evicted entries. This total does not include manual invalidations.
# TYPE cache_eviction_weight gauge
cache_eviction_weight{cache="core.user.hotcaffeine",} 0.0
cache_eviction_weight{cache="syncRequest",} 0.0
cache_eviction_weight{cache="recentCache",} 0.0
# HELP cache_puts_total The number of entries added to the cache
# TYPE cache_puts_total counter
cache_puts_total{cache="core.user.hotcaffeine",} 1.0
cache_puts_total{cache="syncRequest",} 0.0
cache_puts_total{cache="recentCache",} 1.0
# HELP cache_gets_total the number of times cache lookup methods have returned an uncached (newly loaded) value, or null
# TYPE cache_gets_total counter
cache_gets_total{cache="syncRequest",result="miss",} 0.0
cache_gets_total{cache="recentCache",result="hit",} 1.0
cache_gets_total{cache="syncRequest",result="hit",} 0.0
cache_gets_total{cache="core.user.hotcaffeine",result="hit",} 0.0
cache_gets_total{cache="recentCache",result="miss",} 2.0
cache_gets_total{cache="core.user.hotcaffeine",result="miss",} 1.0
# HELP cache_evictions_total cache evictions
# TYPE cache_evictions_total counter
cache_evictions_total{cache="core.user.hotcaffeine",} 0.0
cache_evictions_total{cache="syncRequest",} 0.0
cache_evictions_total{cache="recentCache",} 0.0
# HELP cache_size The number of entries in this cache. This may be an approximation, depending on the type of cache.
# TYPE cache_size gauge
cache_size{cache="core.user.hotcaffeine",} 0.0
cache_size{cache="syncRequest",} 0.0
cache_size{cache="recentCache",} 1.0

netty流量：

# HELP hotcaffeine_netty_traffic  
# TYPE hotcaffeine_netty_traffic gauge
hotcaffeine_netty_traffic{group="read",} 492.0
hotcaffeine_netty_traffic{group="write",} 203.0

key发送接收：

# HELP hotcaffeine_send_keys_total  
# TYPE hotcaffeine_send_keys_total counter
hotcaffeine_send_keys_total 1.0
# HELP hotcaffeine_receive_keys_total  
# TYPE hotcaffeine_receive_keys_total counter
hotcaffeine_receive_keys_total 2.0
# HELP hotcaffeine_deal_keys_total  
# TYPE hotcaffeine_deal_keys_total counter
hotcaffeine_deal_keys_total 2.0

客户端连接数量：

# HELP hotCaffeine_app  
# TYPE hotCaffeine_app gauge
hotCaffeine_app{app="core.user.hotcaffeine",} 1.0

worker指标地址：http://127.0.0.1:9998/actuator/prometheus

dashboard指标地址：http://127.0.0.1:8888/actuator/prometheus

客户端如果是boot项目，也会自动暴露，这些指标可以使用prometheus+grafana进行收集展示。

sohutv/hotcaffeine

sohutv

Reviews

Repository Details