【Redis】热点key问题，的原因和处理，一致性哈希，删除大key的方法

热点 Key 指单个 Key 被高并发访问（如爆款商品），导致 Redis 压力骤增。解决方案应针对 “单个 Key 高并发”：

• 分片缓存：将热点 Key 分散到不同 Redis 节点（如按一致性哈希算法分片）。
• 本地缓存：在应用层缓存热点数据（如 Caffeine），减少 Redis 压力。
• 增加缓存副本：为热点数据增加缓存副本，将热点数据复制到多个缓存节点上，分散访问压力。（例如，使用 Redis 的主从复制，将热点数据存储在多个从节点上，分散读请求。）

热点 Key 的产生原因（除 Redis 宕机外）

• 热点 Key 的核心原因是突发流量或热门事件，例如：
• 突发活动：秒杀、直播带货导致某个商品 Key 被高频访问。
• 热点事件：微博热搜话题对应的缓存 Key。
• 数据倾斜：数据库中某类数据天然访问量高（如高频查询的用户 ID）。

一致性hash了解过吗？

一致性哈希是一种用于分布式系统中的负载均衡算法，它的核心目标是：在节点数量发生变化时，尽量减少数据迁移，同时保持数据的均匀分布。

• 主要目的是将数据均匀分布到多个节点上，并在节点增减时尽可能减少数据的重新分配。

核心原理

• 哈希环（Hash Ring）：

  • 一致性哈希把整个哈希值空间组织成一个环状结构（0 ~ 2³² - 1）。

• 节点映射：

  • 每个节点通过哈希函数（如 FNV、MD5 等）被映射到环上的一个点。

• 数据映射：

  • 数据项（key）同样通过哈希函数映射到环上。
  • 每个数据项存储在顺时针方向遇到的第一个节点上。

节点变动对数据影响最小

• 增加节点：

  • 新节点插入环后，只接管其顺时针方向上第一个节点的部分数据，其余数据不受影响。

• 删除节点：

  • 节点下线后，其数据由顺时针方向的下一个节点接管。

这保证了在节点动态增减的情况下，只需迁移小部分数据，极大提升了系统的可扩展性与稳定性。

应用场景

• 分布式缓存（如 Redis Cluster）
• 负载均衡（如 Nginx+Consistent Hash）
• 分布式存储（如 Cassandra、Amazon Dynamo）

删除大key的方式

1. 分批删除：将大key分批删除，使用SCAN迭代获取大key中的元素，逐个删除

HSCAN bigkey 0 COUNT 100
HDEL bigkey f1 f2 f3 ...

2. 异步删除：利用redis4.0引入的UNLINK代替DEL，在后台进行删除，减少阻塞

UNLINK bigkey

3. 设置过期时间：为大key设置过期时间，等过期在后台自己删除

EXPIRE bigkey 60

4. 使用lua脚本：使用lua脚本代替发大量操作，减少网络IO

-- 分批删除 set 中的成员（每次删100个）
local members = redis.call('SRANDMEMBER', KEYS[1], 100)
for i=1,#members do
  redis.call('SREM', KEYS[1], members[i])
end
return #members

https://github.com/0voice