利用Keyspace Notifications解决Redis集群Key过期事件全局监听

先从一个常见的误区说起：在 Redis Cluster 中监听 key 过期事件，折腾半天却发现只收到了一小部分，很多团队的第一反应往往是代码写错了。实际上并非如此——这是 Redis 设计上就明确做出的选择：Keyspace Notifications 是本地行为，不会跨节点广播。换言之，要监听整个集群的过期事件，就必须手动连接每一个 master 节点。

你之所以只收到部分 key 的 expired 事件，不是代码写错了，而是设计如此——Keyspace Notifications 天生不跨节点广播，必须手动连接并订阅每一个 master 节点。

为什么集群里只收到部分 key 的 expired 事件

Redis Cluster 按照 slot 将 key 分片到不同的 master 节点，而 __keyevent@0__:expired 这类通知仅在 key 实际所在的节点上发布。如果你使用 redis-py-cluster 或 Spring Data Redis 默认连接一个随机节点，那么只能听到该节点上过期的 key——其他节点的过期事件自然就丢失了。

这不是 bug，而是 Redis 明确的设计权衡：避免全集群广播键事件带来的带宽和 CPU 压力。以下几个关键点值得注意：

• Pub/Sub 消息本身会在集群内广播，但 Keyspace Notifications 是本地（local）行为，不会跟随广播扩散。
• 即使你使用 psubscribe __keyevent@*__:expired，Redis 也不支持通配 db 号的跨库订阅。
• 客户端必须主动发现所有 master 节点，并为每个节点单独建立 Pub/Sub 连接。

如何正确订阅全部 master 节点的 expired 事件

核心操作只有两步：获取当前集群所有 master 节点列表，然后对每个 master 建立独立的 Pub/Sub 连接并订阅 __keyevent@0__:expired——注意 db 号必须匹配，否则事件不会推送。

以 Python + redis-py 为例，大致实现如下：

from redis.cluster import RedisCluster
import redis

# 1. 先连集群拿到节点拓扑
rc = RedisCluster(startup_nodes=[{"host": "node1", "port": 7000}], decode_responses=True)
masters = [node for node in rc.nodes_cache.values() if node.server_type == "master"]

# 2. 对每个 master 单独建连接并订阅
for master in masters:
    r = redis.Redis(host=master.host, port=master.port, db=0)
    pubsub = r.pubsub()
    pubsub.psubscribe("__keyevent@0__:expired")
    # 启动监听（通常放在线程里）
    def listen():
        for msg in pubsub.listen():
            if msg["type"] == "pmessage":
                key = msg["data"]
                print(f"[{master.host}:{master.port}] expired key: {key}")
    # 启动线程...

使用过程中有几个容易踩的坑：

• 不要使用 redis-py-cluster 的 pubsub 接口——它内部只选一个节点，无法覆盖全部。
• db 编号必须显式对齐，比如你的 key 存储在 db 1，就需要订阅 __keyevent@1__:expired。
• 节点扩缩容时，必须监听 CLUSTER NODES 输出或定期重新拉取拓扑，否则会漏掉新加入的 master。

notify-keyspace-events 配置必须每个节点都开启

即使你成功连接了所有 master，如果某个节点没有开启 notify-keyspace-events Ex，它就不会发送任何 expired 事件——这个配置不会继承也不会自动同步，必须逐个节点手动设置。

• 云托管 Redis（如阿里云、腾讯云）通常禁用 CONFIG SET，此时只能提交工单让运维人员在配置模板中添加 notify-keyspace-events Ex 并重启实例。
• 切勿使用 AKE 或 gxE 等宽泛配置，否则会触发 del、rename 等高频事件，压垮监听服务。
• 确认是否生效：连接某个节点执行 CONFIG GET notify-keyspace-events，返回值应包含 Ex。

Spring Boot 里怎么绕过自动 CONFIG 调用报错

Spring Data Redis 的 KeyspaceEventMessageListener 初始化时会尝试调用 CONFIG GET/SET，在云环境中会直接抛出 ERR unknown command 'CONFIG'。这并非监听逻辑失败，而是框架“好心办坏事”——本想帮你自动配置，结果却无法执行。

• 禁用自动配置：在 @Bean RedisMessageListenerContainer 里设置 setPhase(0) 并跳过 KeyspaceEventMessageListener 的自动注册。
• 改用手动监听：使用 Lettuce 或 Jedis 直连各个 master，自己实现 MessageListener 并注册到对应的 PubSubConnection。
• 关键点：不要依赖 @RedisListener 注解监听 __keyevent@*__:expired，它底层仍然走自动配置路径。

真正麻烦的从来不是写几行订阅代码，而是维护多个 Pub/Sub 连接的生命周期、处理节点故障转移后的重连、以及确保每个 master 的 notify-keyspace-events 配置长期有效——这些细节一旦遗漏，过期事件就会静默丢失，且毫无日志可查。