云数据库 GEMINIDB-如何检测和解决大key与热key问题:热key问题
热key问题
- 热key的危害:
在日常生活中,经常会发生各种热门事件,应用中对该热点新闻进行上万次的点击浏览和评论时,会形成一个较大的请求量。这种情况下会造成短时间内对同一个key频繁操作,会导致key所在节点的CPU和负载突然升高,从而影响落在该节点的其他请求,导致业务成功率下降。诸如此类的还有热门商品促销,网红直播等场景,这些典型的读多写少的场景也会产生热点问题。
热key问题会产生如下危害:
- 流量集中,达到物理网卡上限。
- 请求过多,缓存分片服务被打垮。
- 数据库击穿,引起业务雪崩。
- 处理思路:
针对热key问题,一般采取如下处理思路。
- 设计上需要考虑热key的问题,避免在数据库上产生热key。
- 业务侧通过增加缓存来减少热key出现的情况。考虑多级缓存解决热key问题(如Redis + 本地二级缓存)
- 屏蔽热点key。 比如:在业务侧进行定制,支持热key黑白名单能力,可以将热key临时屏蔽。
- 检测方法:
我们定义访问频率大于100000 次/min的key为热key。
热key事件分为两种类型。一种是Writes事件,代表写热点,一种是Reads事件,表示读热点。
GeminiDB Cassandra提供了热key的监测与告警。在 CES 界面,可以配置实例的热key告警,具体方法请参见设置告警规则。
当发生热key事件时,系统会第一时间发送预警通知,您可以前往CES界面查看监控事件数据,及时处理,避免业务波动。
图2 热key告警
热key告警字段说明:
{ "sampler_type": "WRITES", //采样类型。取值有WRITES,READS;WRITES代表写,READS代表读。 "partition_num": "2969", //分区键的热点次数 "keyspace_name": "performance", //keyspace名称 "table_id": "a10f3bb0-3626-11ec-bbdf-63e05bbb4391", //表id "table_name": "stresstable", //表名 "partition_key": "85897376" //产生热点分区键的值 }