【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的方式
- 分批删除：将大key分批删除，使用
SCAN迭代获取大key中的元素，逐个删除
HSCAN bigkey 0 COUNT 100
HDEL bigkey f1 f2 f3 ...
- 异步删除：利用redis4.0引入的
UNLINK代替DEL，在后台进行删除，减少阻塞
UNLINK bigkey
- 设置过期时间：为大key设置过期时间，等过期在后台自己删除
EXPIRE bigkey 60
- 使用lua脚本：使用lua脚本代替发大量操作，减少网络IO
-- 分批删除 set 中的成员（每次删100个）
local members = redis.call('SRANDMEMBER', KEYS[1], 100)
for i=1,#members doredis.call('SREM', KEYS[1], members[i])
end
return #members
https://github.com/0voice