先从一个常见的误区说起：在 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 配置长期有效——这些细节一旦遗漏，过期事件就会静默丢失，且毫无日志可查。
