【Redis】bigKey、hotKey问题

1、什么是bigKey？bigKey会导致什么问题？

        俗称“大key”，一般value的体积较大（Hash、String数据结构）、或是集合中含有的元素数量过多（List、ZSet数据结构）的key都是大key。以常用的数据结构为例：

        String类型的Key，它的值为5MB（value的体积较大）。

        Hash类型的Key，如果它的成员数量只有1000个，但这些成员的value总大小为100MB，那么这个key就是bigKey（成员的value体积过大）。

        List类型的Key，它的成员数量为20000个（元素数量过多）。

        ZSet类型的Key，它的成员数量为10000个（元素数量过多）。

        问题：

        （1）内存瓶颈：bigKey会占用大量的内存资源。当Redis实例的内存被大key占满时，可能导致其他数据无法存储，甚至触发内存溢出，导致Redis服务崩溃；如果没有配置合适的内存淘汰策略，甚至会将访问频次高的hotKey从redis内存中淘汰，进一步扩大负面影响。

        （2）性能瓶颈：对bigKey的读取、更新或删除操作可能会消耗较长的时间，导致慢查询。这会对Redis的性能产生负面影响，并可能导致客户端请求的延迟增加。

2、什么是hotKey？hotKey会导致什么问题？

        俗称“热key”，一个key的访问次数显著高于其它key时，这个key就可以被视为热key。打个比方：一个redis服务实例的QPS为10000，其中一个key的每秒访问量达到了7000，这个key就是热key。

        问题：

        （1）单点故障：hotkey只存在于redis cluster的其中一个redis节点上，如果这个redis节点宕机了，不光热key的请求会失败，其它所有依赖于这个redis节点的请求都会失败；后续的所有请求都会打到数据库，影响其它依赖于数据库的业务处理速度，极端情况下，甚至会将数据库打挂，导致整个服务不可用。

        （2）性能瓶颈：对hotKey的访问会大量占用redis服务的CPU时间，影响redis服务处理请求的速度。

3、bigKey、hotKey的产生原因？

        （1）在设计数据模型时没有合理划分数据，导致某些key的元素数量较多。

        （2）使用List数据结构作为消息队列时，消费端发生故障，消息堆积在List列表并不断累加。

        （3）预期外的key请求量激增，热点数据被频繁写入，导致热点数据所在的key变得很大。

4、如何解决bigKey、hotKey问题？

        bigKey：

        （1）合理拆分：将含有数万成员的一个HASH Key拆分为多个HASH Key，并确保每个Key的成员数量在合理范围。在Redis集群架构中，拆分大Key能对数据分片间的内存平衡起到显著作用。

        （2）定时清理：堆积大量过期数据会造成大Key的产生，例如在HASH数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性。可以通过定时任务的方式对失效数据进行清理。

        （3）实时监控：使用工具实时监控Redis的内存情况，根据内存使用率、单位时间内的内存增长率来设置报警阈值。

        hotKey：

        （1）读写分离架构：主节点应对写请求、从节点应对读请求。通过增加从节点的数量来避免hotKey高频访问带来的性能问题。

        缺点：要保证多个从节点可用，增加了运维难度；主从数据同步延迟时，会有脏数据问题等。

        （2）多节点覆盖：假设key：ann是hotKey，那么就复制多份value相同的key：ann2、ann3、ann4，将这些key迁移到其它redis节点，减少单个redis节点的压力，实现负载均衡。

        缺点：代码需要修改；多个key对应同一份数据，引入了数据一致性问题。

        （3）本地缓存：将hotKey的内容写入本地缓存中，后续请求会先打到本地缓存。

        缺点：需要防止本地缓存过大，影响系统性能；一份数据存储在不同地方（本地缓存、redis服务属于两个不同地方），还是有数据一致性问题。