用Redis Lua脚本优化Pub/Sub消息过滤与分类

Redis Pub/Sub 框架原生不支持在服务端进行消息过滤，广播逻辑被硬编码在核心代码中，Lua 脚本无法介入。开发者只能在 PUBLISH 执行前加入校验逻辑，或通过结构化键值对写入消息，但无法拦截已发出的消息。简言之，EVAL 脚本无法干预 PUBLISH 之后的广播流程：你无法在 Lua 中拦截已发布的消息并决定其分发对象。

如果必须实现服务端消息分类，就需要放弃原生广播模型，转而采用“事件写入 + 脚本路由”的混合架构。

为何无法在 Lua 脚本中过滤 Pub/Sub 消息

Pub/Sub 的消息投递逻辑被硬编码在 Redis 内核中（即 pubsubPublishMessage 函数），而 Lua 脚本运行在命令执行层，其执行时机早于广播动作。因此，Lua 脚本最多只能实现以下两个功能：

• 在 PUBLISH 前执行条件检查，例如验证 EXISTS user:1001 键是否存在；
• 将消息结构化为带有业务语义的键值存储，例如 HSET event:123 type "order" user_id "1001"，然后由消费者主动拉取并判断。

这两种操作都不属于 Pub/Sub 流程，也不具备实时广播特性——因此，不要指望在 Lua 中直接拦截广播消息。

使用 EVAL 实现“伪精准分类”的常见误区

许多开发者可能会写出类似如下的代码：

redis-cli EVAL "if redis.call('GET', 'route:'..ARGV[1]) == 'shanghai' then redis.call('PUBLISH', 'region:shanghai', ARGV[2]) end" 0 1001 '{"order_id":"O123"}'

问题何在？首先，ARGV[1] 是硬编码的用户 ID，无法从原始消息体中动态提取——Lua 不支持 JSON 解析。其次，每次都需要手动构造下游频道名称，导致维护成本高昂。第三，如果 route:1001 键不存在，脚本会静默失败，缺乏日志记录、重试机制和监控。最后，当多个 EVAL 脚本并发执行时，无法保证执行顺序或幂等性。

真正可行的 Lua 与 Pub/Sub 协作方案

正确的做法是让 Lua 脚本扮演“发布前守门员”和“结构化写入器”的角色，而非充当消息路由器：

• 使用统一的 PUBLISH event:raw 作为上游原始消息入口。
• 利用 EVAL 脚本执行校验、提取关键字段（例如 user_id）、写入临时结构化键（例如 SET event:123:user_id "1001"），并设置 TTL 以防止堆积。
• 启动一个常驻服务（如 Go 或 Python）订阅 event:raw，接收到消息后立即从临时键中获取路由信息，然后 PUBLISH 到细分频道。
• 所有消费者仅订阅自身关注的频道（例如 user:1001），不依赖 Lua 进行运行时匹配。

这种方案既利用了 Lua 的原子写入能力，又规避了其无法介入广播流程的根本限制。

频道命名与模式订阅的隐藏成本

许多人尝试使用 PSUBSCRIBE user:* 结合 Lua 解析消息体来模拟过滤，但有几点需要注意：

• PSUBSCRIBE 的模式匹配具有 O(n) 时间复杂度，当活跃模式数量超过 50 个时，会显著拖慢整个 Pub/Sub 系统。
• Redis 不支持 ** 或正则表达式，user:*:order 是可行的，但 user:** 会直接报错。
• 每个订阅连接必须独占使用，不能复用，否则会阻塞其他命令的执行。

因此，消息“分类”应通过命名规约提前收敛——例如 service:order:user:1001 这种结构——而不是依赖运行时的脚本或模式匹配来兜底。