Redis 过期了解
Redis 版本：5.0 ：
一：过期监听：
Spring Data Redis 封装了 Redis 的 Pub/Sub 功能，提供了对 key 过期事件的监听支持。
1. 核心类：KeyExpirationEventMessageListener
这个抽象类是 Spring 提供的，专门用于监听 Redis 的 key 过期事件。
代码中的 RedisKeyExpiredListener 继承自它
Redis 的 key 过期事件是一种发布/订阅（Pub/Sub）机制，当某个设置了过期时间的 key 被 Redis 删除时，Redis 会发布一个事件通知。Spring 通过监听这些事件，并将其封装为 Spring 事件模型中的对象，从而实现对 key 过期事件的捕获和处理
Redis 的定期删除策略是 默认每秒执行 10 次（即每 100 毫秒运行一次），这是由 Redis 配置中的 hz 参数控制的。
实际上：默认配置中，hz=10，表示每秒运行 10 次过期键清理任务。
每次运行时，Redis 会从数据库中随机选取一批设置了过期时间的键进行检查，并删除其中已过期的键。
这个过程不会扫描所有键，因此可能会有部分过期键在过期后不会立刻被删除，导致“过期键延迟删除”
可以在 redis.conf 文件中调整 hz 参数来改变 Redis 清理过期键的频率：
增大 hz 值（例如设为 20 或 30）可以提高清理频率，从而提升过期键的删除实时性，但也会增加 CPU 消耗。
减小 hz 值则节省 CPU 资源，但可能导致更多的过期键滞留内存。
实际操作也会遇到，手动更改了TTL方便更快过期，然后不刷新Redis Manager的情况下，尽管有定期删除策略，也没有收到那几个key的过期监听
首先来认知原理：
Redis 使用两种策略来处理设置了 TTL 的键（即有过期时间的键）：
| 删除策略 | 触发方式 | 是否会触发 expired 事件 |
| 惰性删除（Lazy Expiration） | key 被访问时发现已过期但未被删除（惰性删除） | ✅ 会触发 expired 事件 |
| 定期删除（Active Expiration） | Redis 每隔一段时间扫描并随机删除部分过期键 | ❌ 不会触发 expired 事件 |
public class RedisKeyExpiredListener extends KeyExpirationEventMessageListener
这个类继承自 Spring Data Redis 提供的 KeyExpirationEventMessageListener。
它监听的是 Redis 的 __keyevent@*:expired 通道。
只有当 Redis 通过惰性删除触发过期事件时，才会向这个通道发布消息，从而触发你的 onMessage() 方法。
如果一个 key 设置了过期时间（TTL），不主动访问它，也没有在过期后被 Redis 的惰性删除机制触发，那么你确实 可能永远收不到 expired 过期通知。
疑问？
如果 Redis 通过定期删除策略已经删除了一个设置了 TTL 的 key，此时再去手动 GET 这个 key，还会触发 Redis 的 expired 过期事件吗？
答：不会触发过期事件监听器（如 RedisKeyExpiredListener）
只有在访问一个 key 时，发现它已经过期但尚未被删除的情况下，才会真正执行删除操作，并触发 expired 事件。
但如果这个 key 已经被 Redis 的定期删除机制提前删掉了：
它已经不存在于 Redis 中；此时你再访问它（如 GET my_key），会直接返回 nil；
不会再次触发 Redis 的过期检查和事件通知。
二: 那么问题来了：什么是“查询”key？什么又是“访问”key？
2.1这是关键区分点 👇
| 操作 | 是否算作“访问” |
| GET key | ✅ 是 |
| EXISTS key | ✅ 是 |
| TTL key | ✅ 是 |
| DEL key | ✅ 是 |
| Redis 内部线程检查 key 是否存在 | ✅ 是 |
| Redis 定期删除时只是遍历并比较过期时间 | ❌ 不是 |
所以就是代码中有对Redis进行不定时的设置复合键的key时，就会访问key，这样不用直接去手动get 此key,一样是访问到了
key格式复合键：TEST_KEY:
redisTemplate.opsForValue().set(TEST_KEY+ relatedId , null ,60, TimeUnit.SECONDS);
使用这类代码，就是会导致，如果有进行定期set,就会访问key,从而触发一些过期key的过期监听收到消息，
如果不进行设置，则一些已经过期的就有可能被定时删除而收不到消息，导致消息丢失，数据不准确的问题
另外： Redis 定期删除到底做了什么？
Redis 使用了一个叫做 activeExpireCycle() 的函数来执行定期删除。
它的大致流程如下：
void activeExpireCycle(...) {// 获取当前数据库for (j = 0; j < dbs_per_call; j++) {for (k = 0; k < keys_per_call; k++) {// 随机选取一个设置了 TTL 的 keyif (currentExpiresTime < now()) {// 直接删除，不进行任何访问操作dbDelete(db, key);}}}
}
关键点：
Redis 只检查 key 的过期时间；
没有真正访问这个 key 的内容（比如读取、修改等）；
所以 不会触发惰性删除逻辑；自然也就 不会发布 expired 事件。
2.2 除了上面说的情况，某些 key 即使没手动 get，也被监听到过期事件？
| 模块 | 行为 | 是否可能访问 key |
| Lua 脚本 | EVAL 中使用 key | ✅ 是 |
| 集群迁移 | MIGRATE 命令 | ✅ 是 |
| 持久化 | RDB 快照生成时 | ❌ 否 |
| 主从同步 | 复制 key 到从节点 | ❌ 否 |
| 慢日志 | 记录慢命令 | ❌ 否 |
| 其他业务模块 | 如缓存统计、监控工具 | ✅ 是 |
所以你虽然没有显式调用 get(key)，但这些模块可能会在你不察觉的情况下访问 key，从而触发惰性删除。
三：Redis 淘汰策略中访问到这个 key
| 场景 | 是否触发 expired 事件 |
| Redis 定期删除直接删掉了这个 key | ❌ 否 |
| Redis 主从同步时访问了这个 key | ✅ 是 |
| Redis 集群迁移该 key 到新节点 | ✅ 是 |
| Redis 慢日志记录了访问该 key 的命令 | ✅ 是（说明它已经被访问） |
| Redis 监控工具周期性检查 key | ✅ 是 |
| Redis 淘汰策略中访问到这个 key | ✅ 是 |
所以，你的 key 是如何被访问到的？
| 机制 | 是否可能访问 key |
| Redisson 的 RLock、RLock.tryLock() | ✅ 是 |
| Spring Cacheable 缓存组件 | ✅ 是 |
| Redis 的 SCAN 命令 | ✅ 是 |
| Redis 的 KEYS * 命令 | ✅ 是 |
| Redis 的 EXPIRE 命令 | ✅ 是 |
| Redis 的 DEL 命令 | ✅ 是 |
这些命令虽然你不写，但 Redis 内部模块或框架库可能会使用它们。
四：使用 Redisson 的延迟队列（推荐）
RDelayedQueue<String> queue = redisson.getDelayedQueue(redisson.getQueue("my_queue"));
queue.offer("data", 60, TimeUnit.SECONDS);// 注册监听器
queue.registerListener(item -> {log.info("收到延迟消息: {}", item);
});
这种方式比依赖 Redis 的 expired 事件更加稳定可靠。
Redis 内部模块和后台任务 可能 会访问你的 key，但这不是一定会发生的行为。
所以你看到的 key 过期事件，是 “可能触发”的结果，而不是“一定会触发”的机制。
如果你需要确保 key 过期后触发回调，请使用 Redisson 的延迟队列 或 Kafka + 定时轮询 等更可靠的机制。