当前位置：首页 > news >正文

15天 — 如何解决 Redis 中的热点 key 问题？Redis 集群的实现原理是什么？Redis 中的 Big Key 问题是什么？如何解决？

news 来源：原创 2025/6/17 9:43:39

如何解决 Redis 中的热点 key 问题？

1. 热点 key 拆分
- 全量拷贝：将热点 key 拆分成多个 key，它们的数据是一致的。例如，在主从复制架构下，将 hot_key 拆分成 hot_key1、hot_key2、hot_key3 等，不同的请求可以访问到全量的数据。
- 切片拷贝：将热点 key 的数据进行切分，每个分片 key 存储原 key 的一部分数据。
2. 使用二级缓存
- 本地缓存：在应用层引入本地缓存（如 Guava Cache、Ehcache 等），将热点 key 的数据缓存到本地，减少对 Redis 的访问。
- 多级缓存体系：构建多层缓存防线，如 Nginx 本地缓存 → Redis 集群 → 数据库，层层拦截请求。
3. 读写分离

在主从复制模式下，将读请求负载均衡分发到不同的从节点上，从而降低单节点的压力。

4. 限流与降级
- 限流：对热点 key 的访问进行限流，控制访问频率，防止过载。
- 降级：在必要时，对热点 key 的访问进行降级处理，如返回默认值或提示用户稍后重试。
5. 数据分片
- 水平分片：将热点 key 的数据分散到多个 Redis 实例中，降低单个实例的负载。
- 垂直分片：根据业务逻辑，将不同类型的 key 分配到不同的 Redis 实例中，避免热点 key 集中。
6. 热点预热

在系统启动时或流量高峰期前，将热点 key 的数据预热到 Redis 中，避免突发流量对热点 key 的冲击。

7. 随机缓存失效时间

避免大量 key 同一时间批量失效，造成缓存雪崩与缓存穿透。

8. 使用分布式锁

在对热点 key 进行更新时，使用分布式锁来保证数据的原子性和一致性。

9. 永远不过期策略
- 物理不过期：从缓存层面来看，热点 key 不设置过期时间。
- 逻辑过期：为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。
Redis 集群的实现原理是什么？

数据分片
- 哈希槽 ：Redis 集群将所有的键值对分布到 16384 个哈希槽中。每个键值对通过特定的哈希算法（如 CRC16）计算出一个哈希值，然后对 16384 取模，得到对应的哈希槽编号。
- 槽的分配 ：这些哈希槽会被分配到不同的 Redis 节点上，每个节点负责一部分哈希槽。例如，在一个有 3 个节点的集群中，可以将 0 - 5461 号槽分配给节点 A，5462 - 10922 号槽分配给节点 B，10923 - 16383 号槽分配给节点 C。这样，不同的键值对会根据其哈希槽分布到不同的节点上，实现了数据的分片存储。
节点通信
- Gossip 协议 ：Redis 集群中的节点通过 Gossip 协议进行相互通信。每个节点会周期性地向其他节点发送 Gossip 消息，这些消息包含了节点自身的一些信息，如节点的 IP 地址、端口号、状态等，以及其他节点的信息。通过这种方式，集群中的每个节点都能了解其他节点的存在和状态。
- 心跳机制 ：节点之间还会通过心跳机制来检测彼此的存活状态。主节点会定期向其他主节点发送心跳包，从节点则向主节点发送心跳包。如果一个节点在一定时间内没有收到其他节点的心跳包，就会认为该节点可能出现了故障。
主从复制
- 数据同步 ：Redis 集群支持主从复制，主节点可以将数据同步给从节点。当主节点处理写请求时，它会将操作记录到内存中的复制缓冲区中，然后从节点会定期向主节点发送同步请求，获取复制缓冲区中的数据并应用到自己的数据库中，从而实现数据的同步。
- 故障恢复 ：如果主节点发生故障，从节点可以进行故障恢复。集群会通过 Gossip 协议选举出一个新的主节点，从节点会重新指向新的主节点，并继续进行数据同步。
分布式事务
- 乐观锁 ：Redis 集群通过乐观锁来实现分布式事务。在事务开始时，客户端会获取一个版本号，然后在事务执行过程中，如果数据的版本号发生变化，事务就会回滚。这种方式可以保证在高并发环境下数据的一致性。
- 两阶段提交 ：在涉及到多个节点的分布式事务中，Redis 集群采用两阶段提交的方式来保证事务的原子性。第一阶段是准备阶段，主节点会向所有从节点发送事务准备请求，从节点在收到请求后会进行事务的预执行，并将结果返回给主节点。第二阶段是提交阶段，主节点在收到所有从节点的准备成功消息后，会向所有从节点发送提交请求，从节点在收到提交请求后会正式提交事务。
客户端路由
- 客户端缓存 ：客户端会缓存集群的拓扑结构，包括每个节点的 IP 地址、端口号以及负责的哈希槽范围等信息。当客户端需要访问某个键值对时，它会根据键的哈希值计算出对应的哈希槽，然后根据缓存的拓扑结构信息，直接将请求发送到负责该哈希槽的节点上。
- 请求转发 ：如果客户端的缓存信息过期或者不准确，它可能会将请求发送到错误的节点上。此时，接收到错误请求的节点会向客户端返回一个特殊的错误信息，告诉客户端应该将请求发送到哪个正确的节点上，客户端收到该信息后会重新发送请求到正确的节点。
Redis 中的 Big Key 问题是什么？如何解决？

Redis 中的 Big Key 问题是指在 Redis 数据库中，某些键值对占用的内存空间过大，导致在高并发场景下，对这些键值对的访问和操作可能引发严重的性能问题，甚至导致系统瘫痪。

Redis Big Key 问题的解决方法

1. 发现 Big Key

使用 Redis 自带的 --bigkeys 参数：通过命令 redis-cli -p 端口号 --bigkeys，可以扫描整个 Redis 实例，找出五种数据类型里最大的键。
使用 Python 扫描脚本：编写 Python 脚本，通过 scan_iter 方法遍历 Redis 中的键，并使用 check_big_key 函数检查每个键的大小。如果键的大小超过设定的阈值，则认为是大键。
使用 rdb-bigkeys 工具：该工具通过分析 Redis 的 RDB 文件来找出大键。该工具的执行时间短，准确度高，可以将结果导出到 CSV 文件中，方便查看。

2. 解决 Big Key

数据结构优化：优化 Redis 的数据结构，使用合适的数据结构来存储数据，避免出现 Redis 大键的情况。例如，文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息。
拆分 String 类型的大键：将大字符串拆分为多个小字符串，存储在不同的键中。
使用分页读取：对于 List、Hash、Set、ZSet 类型的大键，可以使用分页读取的方式，减少一次性读取的数据量。
使用 Redis 的 SCAN 命令：扫描 Redis 中的键，结合 MEMORY USAGE 命令，批量检查键的大小。
使用 Redis 的 MEMORY USAGE 命令：返回指定键的内存占用大小（以字节为单位），批量检查键的大小，发现并处理大键。
使用 Redis 的 DEBUG OBJECT 命令：提供关于键的详细调试信息，包括编码方式和元素个数，检查键的详细信息，发现并处理大键。