redis原生pub/sub不能直接用作分布式事件总线，因其依赖客户端直连单实例，集群扩缩容、主从切换会导致订阅断开和消息丢失，且缺乏事件过滤、投递确认与失败重试机制；eval脚本可原子化实现“写入+通知+状态更新”，需将zadd、publish、set封装于同一脚本内，并严格对齐keys/argv顺序；消费者须通过轮询有序集合+lua闭环完成拉取、确认与清理，避免幂等缺失与清理顺序错误；集群下绕过key分片约束的可行方案仅有两种：改用单节点/sentinel模式，或以中心协调键（如coord:events）统一存储所有事件元数据。
为什么不能直接用 PUBLISH / SUBSCRIBE 做分布式事件总线？
Redis 原生的 PUBLISH / SUBSCRIBE 是客户端直连模式，订阅者必须长连接到同一台 Redis 实例；一旦集群横向扩容、分片迁移或主从切换，订阅关系就断开，消息丢失。更关键的是，它不支持“事件过滤”“投递确认”“失败重试”这些分布式系统刚需——你没法知道某条消息是否被某个服务真正消费了。
EVAL 脚本里如何原子化完成“写入 + 通知 + 状态更新”？
核心是把发布动作和元数据变更打包进一个 Lua 脚本，利用 Redis 单线程执行特性保证原子性。比如发一条订单创建事件，同时要：1）追加到有序集合 event:order:pending（按时间戳排序）；2）往频道 channel:order 发通知；3）更新 event:order:offset 记录最新 ID。这三步必须在一个 EVAL 里做完，否则可能漏通知或状态错乱。
常见错误是把 redis.call('PUBLISH', ...) 和 redis.call('ZADD', ...) 拆成两个独立命令——它们不在同一事务里，中间若崩溃，就会出现“通知发了但没记 offset”的情况。
实操建议：
- 脚本开头用
local now = redis.call('TIME')获取一致时间戳，避免多命令间时钟漂移 - 用
redis.call('ZADD', KEYS[1], ARGV[1], ARGV[2])把事件内容存为 score=时间戳、value=JSON 字符串 - 用
redis.call('PUBLISH', KEYS[2], ARGV[2])触发通知，但注意：PUBLISH返回值是接收客户端数，别误当成功标志 - 最后用
redis.call('SET', KEYS[3], ARGV[1])更新 offset，KEYS 和 ARGV 顺序要和调用端严格对齐
消费者怎么安全地“拉取 + 确认 + 清理”事件？
不能依赖 SUBSCRIBE 的推送，得用轮询 + Lua 脚本做“拉取-确认”闭环。典型流程是：消费者读 ZRANGEBYSCORE event:order:pending 0 <current_offset></current_offset>，处理完后调用另一个 Lua 脚本把已处理的事件从有序集合删掉，并更新本地 offset。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
容易踩的坑：
- 没做幂等判断：同一条事件可能被多个消费者拉到，脚本里要用
redis.call('SISMEMBER', 'event:order:acked', event_id)先查是否已确认 - 清理时机错乱：先删 ZSET 再写 ack 集合，万一中间崩溃，事件就永久丢失；正确顺序是先
SADD到 ack 集合，再ZREM - 没设超时：用
redis.call('EXPIRE', 'event:order:acked', 86400)防止 ack 集合无限膨胀
集群环境下 Lua 脚本的 key 分片约束怎么绕过？
Redis Cluster 要求所有 key 必须在同一个 slot，但你的事件数据 event:order:pending、通知频道 channel:order、offset 键 event:order:offset 很可能落在不同节点。硬凑哈希标签（如 {order}:pending）会破坏语义，且无法跨 slot 通信。
实操方案只有两个：
- 放弃 Cluster，用单节点 Redis 或 Redis Sentinel 模式跑这个模块——对中小规模系统最稳妥
- 改用“中心协调键”：所有操作都基于一个固定 key（如
coord:events），用 Hash 结构存不同事件类型的 pending list、offset、ack 状态，这样所有操作都在同一 slot
后者性能略低（所有事件类型竞争同一 slot），但能兼容 Cluster；前者部署简单、延迟低，只是扩展性受限。选哪个，取决于你能不能接受“事件总线不随业务 DB 一起分片”这个事实。
