Redis Lua脚本优化服务端Pub/Sub消息过滤分类

Redis Pub/Sub 天生就不支持在服务端做消息过滤——广播逻辑是硬编码在内核里的，Lua 脚本根本插不上手。它只能在 PUBLISH 之前做点校验，或者把消息结构化成键值对写进去，但没法拦截已经发出的消息。换句话说，EVAL 脚本无法干预 PUBLISH 之后的广播行为：你没法在 Lua 里拦下一条已经发出的消息，再决定发给谁。

如果非要在服务端做分类，那就得放弃原生的广播模型，改用“事件写入 + 脚本路由”的混合模式。

为什么不能在 Lua 中过滤 Pub/Sub 消息

Pub/Sub 的投递逻辑硬编码在 Redis 内核里（就是那个 pubsubPublishMessage 函数），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 这种结构——而不是靠运行时脚本或模式匹配去兜底。