Redis----大key、热key解决方案、脑裂问题

文章中相关知识点在往期已经更新过了，如果有友友不理解可翻看往期内容

出现脑裂问题怎么保证集群还是高可用的

什么是脑裂问题

脑裂说的就是当我们的主节点没有挂，但是因为网络延迟较大，然后和主节点相连的哨兵通信较差，之后主从之间的同步就会受影响，主节点和哨兵之间的信号也不好，但是客户端和主节点之间还能进行通信，此时向主节点更新了一条数据，而由于网络问题，从节点未能同步，且由于哨兵集群和主节点之间的通信较差每次ping都收到主节点的恢复，那么哨兵集群就会判断主节点从主观下线到了客观下线（超过了设置的客观下线的数量），那么此时哨兵就会认为主节点挂了，此时会选取一个哨兵作为主节点，然后强行修改原来主节点的配置将其设置为该slave节点的从节点（然后向新的主节点发起主从同步的时候就会进行全量同步，因此原来主节点中更新的那个消息就会彻底丢失），但是此时的问题就是新的从节点并没有原来更新的那条数据的信息，这样就造成了数据的不一致。这就是脑裂问题

解决的核心思路就是

由于是因为主节点能处理客服端的更新操作和，网络延迟导致主从不一致，然后又由哨兵选取从节点变更为主节点导致的数据丢失，那么我们就可以采取这样的操作，即当发生这种网络延迟问题时，我们就拒绝客服端发过来的请求，这样就保证网络延迟期间主从的一致性，此时就算哨兵将从节点设置为新的主节点也没关系，因为数据被没有被更新，从节点中还是有所有数据

具体解决

具体解决就可以在配置文件中进行配置主节点发现从节点下线或者通信超时的总数量小于阈值

当主节点发现从节点下线或者通信超时的总数量小于阈值时，那么禁止主节点进行写数据，直接把错误返回给客户端。

在 Redis 的配置文件中有两个参数我们可以设置：

min-slaves-to-write x，与主节点能连接的同的从节点个数只有超过x时才能进行写操作，否之拒绝写操作
min-slaves-max-lag x，主从数据同步的延迟不能超过 x 秒，如果超过，主节点会禁止写数据。

我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用，分别给它们设置一定的阈值，假设为 N 和 T。

这就表示这两个配置项组合后的要求是，主库连接的从库中至少有 N 个从库，和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主库就不会再接收客户端的写请求了。

大key、热key问题

大key

是什么？

Redis 中的 大 Key（Big Key） 是指存储的单个 Key 对应的 Value 过大（如字符串类型 Value 体积过大，或集合/列表/哈希等类型的元素数量过多）。这类 Key 会显著影响 Redis 的性能和稳定性，是实际应用中需要重点规避的问题。

大 Key 的典型场景

字符串类型

- 存储大体积数据（如 1MB 以上的 JSON/二进制数据）。
- 示例：缓存一个完整的商品详情页 HTML（可能达到几 MB）。

集合/列表/哈希类型

- 元素数量过多（如哈希表存储百万级字段）。
- 示例：用户粉丝列表存储了 100 万用户 ID。

流（Stream）类型

- 消息队列堆积未及时消费，导致单个流包含大量消息。

大key的危害

影响redis的持久化
客户端超时阻塞：由于redis执行命令是单线程的，然后再操作大key时会比较耗时，那么就会阻塞redis，从客户端这边看，就是很久很久没响应
引发网络阻塞。每次获取大key产生的流量都较大，比如假设一个key的大小是1MB，此时每秒访问量为1000MB，那么每秒就会产生1000MB的流量，这对于普通的千兆服务器来说是灾难性的
阻塞工作线程。如果使用了del命令删除了大key，就会阻塞工作线程可以采用unclink来异步删除
存储倾斜（内存分布不均）：集群再slot分片均匀的情况下，会产生数据和查询倾斜的情况，存储大key的Redis节点占用内存多

这里讲一下为什么会影响redis的持久化

主要还是redis的fork以及写时复制这个原因

首先关于aof的刷盘策略：

always:每次更新数据都进行刷盘，既每次都执行fsync()
everysecond:每秒刷盘：会创建一个异步任务来执行fsync()
no:数据到了aof buffer之后就不管了，由操作系统来进行控制刷盘,既永不执行fsync()函数

其实核心都是控制fsync()函数将内核缓冲区中的数据写到磁盘中

大key对于aof的持久化影响

如果设置的aof刷盘策略是Always策略,主线程再执行命令之后，会将数据写到AOF日志文件中，然后调用fsync()函数将内核缓冲区中的数据直接写到磁盘，等磁盘写操作完该函数才会返回，可以看到redis在这个过程中一直是阻塞等待的，即是单线程处理

所以在使用Always策略的时候，如果写入的是以一个大key，主线程执行fsync()函数的时候，阻塞时间会比较久，因为当写入的数据量很大的时候，数据会同步到磁盘这个过程很耗时

如果使用的是everysec或no的刷盘策略的话就持久化过程就不会影响主线程

大key对AOF重写和RDB的影响

1.对fork过程的影响

主要核心问题，AOF重写和RDB生成过程其实核心都是需要fork一个子进程，内核会将父进程中的页表也会复制一份给子进程，虽然子进程是独立运行的不影响主进程，但是在fork子进程的这个过程中是需要主进程参与的，

而大key说明所占空间比较大，也会导致页表所占空间增大，所以要是页表很大那么复制过程也是很耗时的，那么在fork时就会发生阻塞现象

2.因为在fork复制之后，主进程还会处理客户端的命令，如果客户端执行执行修改操作，那么主进程会进行写时复制操作（这个操作是主进程进行的），即将修改的数据拷贝一份到物理内存中，但如果修改的这个key就是大key那么这个复制过程也可能造成阻塞

- 示例：对字符串类型的大 Value 按固定大小分块存储（如 big_data:part1, big_data:part2）。

对于海量数据存储时，我们也可以通过上面两种方式先进行拆分key，拆分key之后redis会计算key的哈希值去找到对应的哈希巢slot，然后将这个大key就将其拆成不同的小key，对应不同的哈希槽slot，然后就可以分布到不同的节点，这样就可以有效解决数据倾斜问题

热key问题

是什么

Redis 中的 热 Key（Hot Key） 是指被高频访问的单个 Key，其请求量远高于其他 Key。这类 Key 会导致 Redis 实例或某个分片（Cluster 模式）的负载过高，引发性能瓶颈甚至服务崩溃。热 Key 问题需要结合业务场景和架构设计来预防和解决。

热 Key 的危害

单节点过载（多级缓存+对key拆分解决）

- 在 Redis 集群模式下，热 Key 可能集中在某个分片（哈希槽），导致该节点 CPU/网络过载，而其他节点空闲。
- 示例：某商品库存 Key 每秒接收 10 万次读取，远超单节点处理能力。

缓存雪崩风险（一致性要求高就直接加分布式锁，否之可以使用key的逻辑过期）

- 若热 Key 突然失效（如过期或主动删除），大量请求穿透到数据库，可能引发级联故障。

性能抖动（参考大key问题）

- 热 Key 的频繁访问可能导致 Redis 主线程阻塞（如大 Value 读取），影响其他请求的延迟

解决方案

主要：本地缓存+热key的冗余话存储+读写分离，如果读多那么可以考虑增加从节点的个数

2. 压缩数据

对字符串类型的 Value 使用压缩算法（如 gzip、Snappy），读取时解压。
需权衡 CPU 与内存的消耗（适合读少写多的场景）。

3. 设置过期时间

对临时性大 Key 设置 TTL（如 EXPIRE），避免长期占用内存。

4. 异步删除

Redis 4.0+ 支持 UNLINK 命令替代 DEL，后台异步删除大 Key。
配置 lazyfree-lazy-user-del yes，自动异步删除。

5. 限流与熔断

客户端对大 Key 的访问做限流（如令牌桶算法），避免突发流量压垮服务。

1. 本地缓存（多级缓存）

在应用层（客户端）对热 Key 添加本地缓存（如 Guava、Caffeine），减少对 Redis 的直接访问。
适用场景：读多写少，允许短暂数据不一致（设置较短的本地 TTL）。
示例：商品库存读取时，客户端缓存库存值 100ms，期间所有请求直接读本地缓存。

2. Key 分片（分散压力）

将热 Key 拆分为多个子 Key，通过哈希或随机后缀分散到不同节点。

- 示例：原 Key stock:item_123 拆分为 stock:item_123:1、stock:item_123:2，客户端随机访问一个子 Key。

注意：需确保数据一致性（如所有子 Key 同时更新）。

3. 读写分离

对热 Key 启用读写分离，将读请求分发到从节点（需容忍主从同步延迟）。
限制：Redis 集群模式下从节点不分担读请求（需 Proxy 或客户端分片）。

4. 缓存永不过期 + 异步更新

对热 Key 不设置过期时间，通过后台任务定期更新缓存，避免缓存击穿。
示例：商品库存每 10 秒异步更新一次，Key 永不过期。

5. 限流与熔断

对热 Key 的访问进行限流（如令牌桶算法），超出阈值时熔断，返回默认值或降级数据。
工具：使用 Sentinel、Hystrix 或 Resilience4j 实现。

6. 使用更高效的数据结构

优化存储格式，减少单次访问的数据量。

- 示例：用哈希表存储商品信息，按需获取字段（HGET 替代 GET），避免传输冗余数据。

7. Redis 集群扩容

对热 Key 所在的分片进行垂直扩容（提升单节点配置）或水平扩容（增加分片数量，需迁移数据）。

这里讲一下key分片策略

方案核心思想

冗余存储
将热 Key 复制多份，存储在不同的 Master 节点，例如 key:1（节点1）、key:2（节点2）。
请求分发
客户端通过轮询或哈希算法，将请求均匀分发到不同副本，降低单个节点的压力。

适用场景

读多写少：写入频率低，且容忍一定同步延迟（如缓存热点新闻）。
高并发读：单 Key 的 QPS 远超单节点处理能力（如 10万+/秒）。
集群模式：Redis 部署为 Cluster 模式，且 Master 节点数量充足。

优势

分散读压力
读请求被均匀分发到多个节点，避免单节点过载。
高可用性
冗余副本分散在不同节点，单个节点故障时，其他副本仍可提供服务（需配合故障转移）。
扩展性
可通过增加副本数量（如 key:3、key:4）应对更高并发。

潜在问题

1. 数据一致性

写入成本高：每次更新需同步修改所有副本，否则会读到旧数据。

- 示例：更新 key 时需同时更新 key:1、key:2，若某次更新失败，会导致数据不一致。

最终一致性：若副本间同步有延迟，客户端可能读到不同版本的数据。

2. 额外存储开销

冗余副本占用更多内存，若 Key 的 Value 较大（如 1MB），存储成本显著增加。

3. 客户端复杂度

客户端需维护所有副本的位置（如 key:1、key:2），并实现负载均衡逻辑。
若集群拓扑变化（如节点扩容/缩容），客户端需动态感知副本分布。

4. 写入放大效应

对热 Key 的写入操作会放大 N 倍（N=副本数），可能引发性能问题。

优化方案

1. 异步复制（最终一致性）

写入时仅更新主副本（如 key:1），通过后台任务异步同步到其他副本（如 key:2）。
代价：读可能短暂不一致，适合对一致性要求不高的场景（如计数器缓存）。

2. 版本号控制

为每个 Key 添加版本号（如 key:1:v100、key:2:v100），客户端读取时校验版本号，若不一致则触发同步。
示例：

- 写入时更新所有副本，并递增版本号。
- 读取时优先访问一个副本，若发现版本号落后，触发同步。

3. 代理层分发

使用中间件（如 Redis Proxy 或 Envoy）统一管理副本，客户端无感知。

- 代理层维护副本列表，自动负载均衡读请求。
- 写入时由代理层同步更新所有副本。

4. 结合读写分离

主副本（如 key:1）处理写请求，其他副本（如 key:2、key:3）作为只读副本。
读请求分发到只读副本，写入仅需更新主副本，降低一致性复杂度。

与其他方案的对比

方案	优点	缺点	适用场景
冗余分片	分散读压力，高可用	数据一致性难，写入成本高	读多写少，容忍最终一致性
本地缓存	零网络开销，响应快	数据不一致，内存占用高	极高频读，允许短暂不一致
Key 分片（Hash）	天然分散压力，无需维护副本	拆分逻辑复杂，需修改业务代码	数据可拆分（如按用户 ID 分片）
读写分离	利用从节点资源，简单易行	主从延迟，集群模式不支持	读占比高，容忍延迟