# 为了减少大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单独转移到其余存储介质。** 无法拆分的大Key建议使用此方法，将不适用Redis能力的数据存至其它存储介质，如[SFS](https://www.huaweicloud.com/product/sfs.html)或者其余NoSQL数据库，并在Redis中删除该大Key。 注意： 禁止使用DEL直接删除大Key，可能会造成Redis阻塞，甚至主备倒换。Redis 4.0及以上版本建议采用UNLINK命令删除大Key。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| 大Key | **合理设置过期时间并对过期数据定期清理。** 合理设置过期时间，避免历史数据在Redis中大量堆积。由于Redis的惰性删除策略，过期数据可能并不能及时清理，如果发现Redis过期Key清理较慢，建议配置[过期Key扫描](https://support.huaweicloud.com/usermanual-dcs/dcs-ug-210330002.html)。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| 热Key | **使用读写分离。** 如果热Key主要是读流量较大，则可以在客户端[配置读写分离](https://support.huaweicloud.com/dcs_faq/dcs-faq-0427027.html)，降低对主节点的影响。还可以增加多个副本以满足读需求，但是备机较多也有相应的影响，DCS主备节点之间使用的是星型复制，即所有的备节点都直接和主节点保持同步，这样能保证备节点之间相互独立，且复制延迟较小。缺点是在备节点数量较多的情况下，主节点的CPU和网络负载会较高。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| 热Key | **使用客户端缓存/本地缓存。** 该方案需要提前了解业务的热点Key有哪些，设计客户端/本地和远端Redis的两级缓存架构，热点数据优先从本地缓存获取，写入时同时更新，这样能够分担热点数据的大部分读压力。缺点是需要修改客户端架构和代码，改造成本较高。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
| 热Key | **设计熔断/降级机制。** 热Key极易造成缓存击穿，高峰期请求都直接透传到后端数据库上，从而导致业务雪崩。因此热Key的优化一定需要设计系统的熔断/降级机制，在发生击穿的场景下进行限流和服务降级，保护系统的可用性。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |