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

大Key

进行大Key拆分。

分为以下几种场景：

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

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

无法拆分的大Key建议使用此方法，将不适用Redis能力的数据存至其它存储介质，如SFS或者其余NoSQL数据库，并在Redis中删除该大Key。

合理设置过期时间并对过期数据定期清理。

合理设置过期时间，避免历史数据在Redis中大量堆积。由于Redis的惰性删除策略，过期数据可能并不能及时清理，如果发现Redis过期Key清理较慢，建议配置过期Key扫描。

热Key

使用读写分离。

如果热Key主要是读流量较大，则可以在客户端配置读写分离，降低对主节点的影响。还可以增加多个副本以满足读需求，但是备机较多也有相应的影响，DCS主备节点之间使用的是星型复制，即所有的备节点都直接和主节点保持同步，这样能保证备节点之间相互独立，且复制延迟较小。缺点是在备节点数量较多的情况下，主节点的CPU和网络负载会较高。

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

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

设计熔断/降级机制。

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