文档首页/ 分布式缓存服务 DCS/ 用户指南(吉隆坡区域)/ 常见问题/ 大Key/热Key分析/ 为了减少大Key和热Key过大,有什么使用建议?
更新时间:2024-07-29 GMT+08:00

为了减少大Key和热Key过大,有什么使用建议?

  • string类型控制在10KB以内,hash、list、set、zset元素尽量不超过5000个
  • Key的命名前缀为业务缩写,禁止包含特殊字符(比如空格、换行、单双引号以及其他转义字符)。
  • Redis事务功能较弱,不建议过多使用。
  • 短连接性能差,推荐使用带有连接池的客户端。
  • 如果只是用于数据缓存,容忍数据丢失,建议关闭持久化。
  • 大Key/热Key的优化方法,请参考下表。

类别

方法

大Key

进行大Key拆分。

分为以下几种场景:

  • 该对象为String类型的大Key:可以尝试将对象分拆成几个Key-Value, 使用MGET或者多个GET组成的pipeline获取值,分拆单次操作的压力。如果是集群实例,由于集群实例包含多个分片,拆分后的Key会自动平摊到集群实例的多个分片上,从而降低对单个分片的影响。
  • 该对象为集合类型的大Key,并且需要整存整取:在设计上严格禁止这种场景的出现,因为无法拆分。有效的方法是将该大Key从Redis去除,单独放到其余存储介质上。
  • 该对象为集合类型的大Key,每次只需操作部分元素:将集合类型中的元素分拆。以Hash类型为例,可以在客户端定义一个分拆Key的数量N,每次对HGET和HSET操作的field计算哈希值并取模N,确定该field落在哪个Key上,实现上类似于Redis Cluster的计算slot的算法。

将大Key单独转移到其余存储介质。

无法拆分的大Key建议使用此方法,将不适用Redis能力的数据存至其它存储介质,并在Redis中删除该大Key。

注意:

禁止使用DEL直接删除大Key,可能会造成Redis阻塞,甚至主备倒换。

热Key

使用客户端缓存/本地缓存。

该方案需要提前了解业务的热点Key有哪些,设计客户端/本地和远端Redis的两级缓存架构,热点数据优先从本地缓存获取,写入时同时更新,这样能够分担热点数据的大部分读压力。缺点是需要修改客户端架构和代码,改造成本较高。

设计熔断/降级机制。

热Key极易造成缓存击穿,高峰期请求都直接透传到后端数据库上,从而导致业务雪崩。因此热Key的优化一定需要设计系统的熔断/降级机制,在发生击穿的场景下进行限流和服务降级,保护系统的可用性。