网硕互联帮助中心热key发现：通过lfu算法，如果达到阈值达到就判定为热key，开展热key的相关操作
一、本地缓存方案(现有方案)
整体流程：
二、hotzone热点散列方案
整体流程：
Server端从CFS获取集群分片拓扑及拓扑变更。
Server端识别热key及热key变更，从(1)中的拓扑中获取分片信息，异步将热key及热key变更同步到其他分片实例。
本地分片及其他分片同步下发热key及热key变更和该热key所在的分片-副本编号。
客户端收到热key及热key变更，设置本地缓存。
本地缓存如果没有命中，则从热key所在的所有分片中按策略选一个分片请求。
三、热key即时下发方案
整体流程：
四、通过CFS下发方案
整体流程：
Server端识别热key及热key变更，通过CFS下发给客户端。
客户端通过ping CFS服务获取到热key，并设置本地缓存。
客户端从本地缓存中请求热key。
五、热点集中存储方案
整体流程：
六、集群内热点实例方案
整体流程：
集群内增加实例来存储热key，热key实例通过CFS拓扑下发给客户端。
集群内实例通过CFS获取本集群热key实例拓扑，识别热key后，将热key同步到热key实例，并通过热key实例下发热key给客户端。
客户端收到热key后，缓存到本地，本地过期后请求热key实例来获取热key。
方案对比
|
方案 |
缺陷 |
优势 |
实施 |
|
本地缓存方案(现有方案) |
当客户端规模较大时，热key及热key变更下发不及时，导致数据不一致周期长。 当流量把客户端连接资源占满时，导致热key无法下发，导致实例有down掉风险。 本地缓存实现比较复杂。 |
改动成本小，逻辑简单。 |
Server需要实现异步下发。 客户端需要实现本地缓存。 |
|
hotzone热点散列方案 |
需要从cfs中获取拓扑结构，导致cfs流量突增。影响拓扑数据下发的及时性，导致拓扑变更变慢。 热点hotzone分区选择缺乏优化策略，导致热key问题放大。 当分片的热key变更没有及时同步到其他分片时，也存在不一致窗口。 |
解决“本地缓存方案”中，无法下发热key导致实例down掉的问题，提高稳定性。 有效切分和转移数据流量。 |
|
|
热key即时下发方案 |
|
|
需要兼容现有的协议基础上，扩展现有协议。 |
|
通过CFS下发方案 |
增加数据流的复杂性，架构的复杂性。 数据下发的实时性上也不能完全保证。需要改造cfs下发数据的机制才能保证下发的及时性。 热key变更(增加/变更/删除)的时序性没办法保证，可能导致本地数据错乱不一致风险。 |
|
|
|
热点集中存储方案 |
可能存在数据冲突，需要做到集群之间数据隔离。 全局热点集群，自身有成为热点的可能性。 |
数据统一存储，方便管理。 |
|
|
集群内热点实例方案 |
|
|
需要拓扑中增加额外标记的热key实例。 Server同样需要从CFS获取到自身集群内的热key实例。 |
评论前必须登录！
注册