热点数据监测方法

news2025/1/22 20:52:20

在日常开发中，我们需要着重注意一种场景-热点数据。他可能是一种请求，每次请求的数据类型都是一样的；可能是同一个数据，比如页面上公用的类型数据；可能是同一个用户大量的请求。他们都有着同一个特点，瞬时爆发量大、重复请求、频繁请求，所以这对于系统来说是非常频繁访问的数据，称为热点数据，与不常访问的数据有很明显的不同。

我们在应对热点数据情况时，主要的手段为：非法请求过滤、限流、降级、本地缓存四种。

现有技术第一种架构方法。

在请求打到服务器上面时，由服务器自身对请求key进行识别处理，将其放置到一个如哈希表结构的数据模型中，访问一次进行计数一次，当请求没有达到阈值时，请求会被转发到数据库上，达到阈值时进行访问，会将数据放置于本地jvm内存中，直接走本地缓存。

图1.1 第一种架构方法图

这种方式通过本地进行计算，会存在诸多缺点：

1. 每台机器单独计数，也就意味着每台机器单独进行本地缓存，会导致缓存不一致问题。

2. 每台机器单独计数，计数不准确，若有100台机器，100次请求，可能部分机器没有收到请求。

3. 机器重启，缓存丢失。

4. 直接存储全量数据，会浪费大量内存空间。

现有技术第二种架构方法。

使用缓冲中间件的方法，当请求打到服务层时，会优先请求缓存中间件是否有数据，不会直接请求数据库，中间件中拥有LRU结构，当Redis内存满时，会始终存储热点数据，丢弃冷数据，并且也提供了冷热数据的检测功能。这也是常使用的方式，通过Redis对数据库进行保护，同时提高查询效率。

图1.2 第二种架构方法图

这种方式通过本地进行计算，会存在诸多缺点：

1. 当出现缓存击穿和雪崩时，会出现请求直接打到DB，导致DB直接瘫痪，服务不可用。

2. 使用redis命令，redis-cli时加上–hotkeys，进行统计热key会导致redis性能降低

3.使用monitor进行实时抓取redis命令进而统计热key，或者使用现成的分析工具redis-faina，在高并发场景下会出现内存暴增、降低redis性能的问题，统计热key一般都是高并发场景，所以这是致命的。

现有技术第三种架构方法。

是一种解决热读问题的方案，针对于写少读多，通过在服务层下增加一层SLB层，进行负载均衡转发，转发到路由层Proxy，路由层Proxy负责将请求分为读请求、写请求，分发读请求到读服务器，如Mysql的从机器上，进行读取操作，将写请求分发到写服务器上，即Mysql的Master机器上，进行写操作。读机器可以横向扩充，进行读取性能的横向扩展。读写请求的分离是解决写少读多场景的优秀方案。在这种方法的基础上，可以将底层的数据中间件改变为Redis，通过Redis探测热点数据。当Redis发现热点数据后，可以通过在Proxy层增加本地缓存进行快速返回，横向增加Proxy方法可以扩展读能力，这种方式对Client端完全无感知，具体操作在Proxy层。

图1.3 第三种架构方法图

现有技术第四种架构方法。

这是一种比较完善，性能高，解决大多数场景的方法。在进行缓存获取时，通过异步将 key 访问事件 异步（通过rsyslog将请求日志写入kafka消息队列中，hermes通过消费kafka消息进行请求数统计）上报给 Hermes 服务端集群 ，根据上报数据进行“热点探测，通过ETCD集群进行推送热点数据到服务端，通过apollo进行规则配置、黑白名单、集群地址信息配置。

图1.4 第四种架构方法图

在进行热点数据探测时，在hermes服务器集群内部针对每个App的每个Key都维护了一个时间轮，每3秒钟对收到的热点请求数据进行一次计算，探测出当前的热点数据，然后通过etcd集群通知各个服务端。

hermes-sdk修改了jedis的源码，在获取key时，会先通过hermes-sdk中的代码获取是否有热点数据，本地缓存中是否存在，若存在优先取本地缓存，做到了无感知化接入，原有逻辑无需改动即可提高性能，解决热点数据危害。

现有技术第五种架构方法。

此方法为京东开发的hotKey，流计算worker集群信息注册到etcd集群，启动后的客户端通过etcd可以获取到worker集群信息，客户端与worker之间建立netty长链接，后续当有请求时，异步将请求上报给worker集群进行计算，同时worker集群通过etcd获取规则配置信息，通过规则进行分片计算，最后将结果聚合后通知给客户端。