大key过期易引发击穿，因其del操作阻塞主线程数百毫秒至秒级，导致请求直击db；监控表现为latency突增、clients暴涨但ops骤降，db负载飙升。
大Key过期时为什么更容易引发击穿？
因为大Key的删除（DEL）本身就会阻塞Redis主线程数百毫秒甚至秒级，期间所有请求无法被处理；而一旦该Key恰好是热点数据，过期瞬间大量请求穿透到DB，就不是“单个线程抢锁加载”能缓解的问题了——主线程卡死，连锁都抢不了，setnx命令直接排队超时。
典型现象是：监控看到 latency 突增、connected_clients 暴涨但 instantaneous_ops_per_sec 反而骤降，同时DB CPU/连接数飙升，日志里出现大量 Redis timeout 或 Connection reset by peer。
用 redis-cli --bigkeys 扫描前必须做三件事
直接在生产环境跑 redis-cli -h x.x.x.x -p 6379 --bigkeys 是高危操作：它会阻塞主线程扫描全库，对集群就是雪上加霜。
- 先确认当前实例负载：
redis-cli info | grep -E "(used_memory|instantaneous_ops_per_sec|blocked_clients)"，若blocked_clients > 0或instantaneous_ops_per_sec接近峰值80%，暂停扫描 - 改用
--scan模式分批采样（Redis 4.0+）：redis-cli --scan --pattern "user:*" | head -1000 | xargs -I{} redis-cli debug object {} 2>/dev/null | grep -E "(serializedlength|refcount)"，避免全库阻塞 - 重点盯
Hash/ZSet类型：它们比String更容易藏匿“逻辑大Key”，比如一个user:1001:orders的ZSet存了3年订单，元素数早超5000，但KEYS user:1001:orders看不出异常
EXPIRE 和 PEXPIRE 对大Key过期的影响差异
大Key过期不等于立刻释放内存，Redis采用惰性+定期双策略。但关键区别在于：EXPIRE 设置秒级过期，触发的是更粗粒度的定期清理（默认每100ms抽样20个key），而 PEXPIRE 的毫秒级精度会让key更大概率落入同一轮抽样周期——多个大Key集中在同一毫秒过期，就容易触发批量阻塞。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 禁止对已知大Key使用
PEXPIRE，统一用EXPIRE+ 随机偏移（如EXPIRE key 3600 + random(0, 300)） - 对
Hash等集合类型，不要依赖整体过期，改用HSCAN+ 客户端时间戳字段做逻辑过期（例如每个field值存"value|1730728800"） - 监控
expired_keys和evicted_keys指标突增，结合慢日志SLOWLOG GET 5查看是否集中出现del、hgetall、zrange等耗时命令
真正有效的热Key+大Key混合防护方案
单靠分布式锁挡不住大Key过期击穿，得把防护点前移到“过期前”。核心思路是：让大Key不死，只让它“休眠”。
示例流程（Java伪代码）：
String key = "hot:order:list";
String value = redisTemplate.opsForValue().get(key);
if (value == null) {
// 1. 先尝试获取“预加载锁”
Boolean loaded = redisTemplate.opsForValue()
.setIfAbsent("preload_lock:" + key, "1", Duration.ofSeconds(3));
if (loaded) {
// 2. 异步刷新：不阻塞主线程，用线程池触发DB查询+写入新key
asyncRefreshBigKey(key);
// 3. 返回兜底空缓存（防穿透），TTL设短（如5s）
redisTemplate.opsForValue().set(key + ":stale", "", Duration.ofSeconds(5));
}
// 4. 所有线程统一读 stale key，避免重复加载
value = redisTemplate.opsForValue().get(key + ":stale");
}
这个方案绕开了大Key删除阻塞，也规避了锁竞争，但代价是多维护一个 :stale 辅助key——这恰恰是生产中最容易被忽略的复杂点：你得确保 asyncRefreshBigKey 内部用 UNLINK 替代 DEL，且刷新后立即 EXPIRE 新key，否则 stale key 会堆积成新的大Key。
