如何使用Redis Lua脚本优化Pub/Sub的消息过滤_在服务端完成消息分类

Redis Pub/Sub不支持服务端消息过滤，因广播逻辑硬编码于内核，Lua仅能在PUBLISH前校验或结构化写入，无法干预已发出消息的投递。

Redis Pub/Sub 本身不支持服务端消息过滤，EVAL 脚本无法干预 PUBLISH 后的广播行为——你不能在 Lua 中“拦下”一条已发出的消息，再决定发给谁。

想在服务端“分类”，本质是放弃原生 Pub/Sub 的广播模型，改用「事件写入 + 脚本路由」混合模式。

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

Pub/Sub 的投递逻辑硬编码在 Redis 内核中（pubsubPublishMessage 函数），Lua 运行在命令执行层，早于广播动作发生；它最多能做两件事：
– 在 PUBLISH 前检查条件（比如 EXISTS user:1001）
– 把消息结构化写入带业务语义的键（如 HSET event:123 type "order" user_id "1001"），再由消费者主动拉取判断
这两者都不属于 Pub/Sub 流程，也不具备实时广播特性。

用 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，收到后立即调用 GET event:123:user_id 获取路由信息，再 PUBLISH 到细分频道
• 所有消费者只订阅自己关心的频道（如 user:1001），不依赖 Lua 做运行时匹配

这样既利用了 Lua 的原子写入能力，又规避了它不能介入广播流程的根本限制。

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

很多人试图用 PSUBSCRIBE user:* + Lua 解析消息体来模拟过滤，但要注意：
– PSUBSCRIBE 匹配是 O(n) 时间复杂度，活跃模式超 50 个就会明显拖慢整个 Pub/Sub 系统
– Redis 不支持 ** 或正则，user:*:order 可行，user:** 直接报错
– 每个订阅连接必须独占，不能复用，否则阻塞其他命令
所以“分类”应靠命名规约（如 service:order:user:1001）提前收敛，而不是靠运行时脚本或模式匹配去兜底。