Redis键空间事件订阅通知实现指南

Redis键空间事件订阅通知的实现方法

Redis键空间事件默认处于关闭状态

一个关键细节是，许多开发者初次使用时容易忽略：Redis启动后，其notify-keyspace-events配置项默认值为空字符串。这意味着所有键空间事件通知功能均未激活。因此，如果你的代码执行了PSUBSCRIBE __keyspace@0__:*却收不到消息，首先应检查服务端配置是否已开启通知功能。

• 启用通知有两种方式：一是使用CONFIG SET notify-keyspace-events命令动态设置（立即生效），二是在redis.conf配置文件中预先配置（重启后生效）。
• 最常用的配置组合是KEA。其中K表示开启键空间通知（对应__keyspace@N__:频道），E表示开启键事件通知（对应__keyevent@N__:频道），A表示包含所有类型的命令事件，如set、del、expire。
• 配置字母顺序不限，但组合需正确。例如仅配置KA而缺少E，则无法接收del等事件；仅配置EA而缺少K，则按数据库订阅__keyspace@0__:的模式将失效。
• 需注意：通过CONFIG SET进行的修改仅对当前Redis实例有效，且不会持久化。在容器化部署或云服务环境中，还需确认启动参数或管理控制台是否支持此类配置。

订阅时需使用正确的频道名称格式

事件通知的频道名称格式固定且严格。所有事件仅发布至两个特定前缀的频道：__keyspace@{db}__: 和 __keyevent@{db}__:。格式必须完全匹配，包括下划线和数据库编号。

• 数据库编号必须与目标键所在的库一致。例如使用SELECT 2切换至2号库后执行SET foo bar，对应事件将发布至__keyspace@2__:foo频道，订阅@0或@1将无法接收。
• 支持使用通配符订阅，如PSUBSCRIBE __keyspace@0__:*可匹配0号库所有键的事件。但需注意，通配符*遵循Redis自身的模式匹配规则，不能用于模糊匹配键名内容。
• Redis的发布/订阅机制仅针对订阅后的操作生效。客户端必须在连接成功并执行订阅命令后，才能接收到后续发生的事件，无法获取历史事件。

EXPIRE与TTL触发的事件存在延迟且非实时

键过期事件并非实时触发。Redis采用“惰性删除”与“定期抽样清理”相结合的机制。使用EXPIRE设置过期时间后，实际的删除操作及对应事件通知可能存在数秒或更长的延迟。

这种延迟具有不确定性。若键在过期前被访问，惰性删除机制会立即清除并触发事件；若键未被访问，则需等待后台定期任务处理。因此，依赖过期事件的应用需考虑此特性。

• 不建议依赖__keyevent@0__:expired等事件实现需精确时效的控制（如订单超时关闭）。此类事件仅适用于对时效性要求不高的旁路场景。
• TTL命令本身不会触发事件，仅当键被实际删除时才会产生expired事件。使用SET key val EX 5或SETEX设置带过期时间的键，同样遵循延迟机制。
• 若业务对时效性有严格要求，可考虑自行实现方案，例如使用ZSET有序集合存储过期时间戳并通过轮询处理，或改用Redis Streams由生产者主动写入到期消息。

客户端断开连接后事件丢失且无自动重订阅

Redis的发布/订阅模型为纯内存通道，不提供消息持久化。若客户端因网络波动、进程崩溃或未正确处理PSUBSCRIBE返回而断开连接，断连期间的所有事件将永久丢失。

• PSUBSCRIBE命令非幂等。客户端重连后需重新执行订阅命令，原有订阅关系不会自动恢复。
• 许多客户端库（如Python的redis-py）提供的pubsub对象默认不包含自动重连与重新订阅逻辑。开发者需监听connection_error等事件，并在回调函数中手动调用psubscribe()。
• 键空间事件不应作为可靠消息队列使用。其缺乏ACK确认机制、消费位点记录，且无法保证“至少一次”投递。

此外需注意，事件通知内容较为精简。消息体通常仅包含事件键名（key）和事件类型（如set、del），不包含键值（value）、时间戳或触发者信息。若需完整操作链路上下文，应在业务层自行补充，例如记录详细日志或将完整信息写入Redis Streams。