redis pub/sub 无法与 multi/exec 事务结合，因 publish 被协议层面禁止在事务中执行；它不修改数据、不可回滚、无持久化语义，且属连接上下文强依赖命令。
Redis 的 Pub/Sub 无法与 MULTI/EXEC 事务结合使用，根本不存在“保证原子性”的可行路径。 因为 PUBLISH 命令本身就被明确排除在事务命令列表之外——它在 MULTI 块中执行会直接报错，不是行为异常，而是协议层面禁止。
为什么 PUBLISH 不能放进 MULTI 事务？
Redis 事务只允许包含「数据修改类」且「可回滚」的命令（如 SET、HSET、LPUSH），而 PUBLISH 是一个「通知广播」操作：它不改变任何键值，也不参与 AOF/RDB 持久化，更没有对应的回滚语义。服务端在解析 MULTI 块时会硬性拦截，返回错误：
ERR DISCARD, EXEC, MULTI, EXEC, WATCH, UNWATCH cannot be used inside a transaction
注意这个错误信息里提到的命令列表，PUBLISH 虽未显式列出，但和 PSUBSCRIBE 等一样属于「连接上下文强依赖型」命令，被统一归入禁止范围。
常见误用场景与替代方案
开发者常想实现「更新数据库 + 同时发消息」的原子效果，比如库存扣减后通知下游。这时试图把 DECR 和 PUBLISH 塞进同一个 MULTI 块，必然失败。
- ✅ 正确做法：先执行事务（如
DECR stock:123），检查返回值是否 ≥0；成功后再单独调用PUBLISH order:123 "paid" - ✅ 更健壮的做法：用
SET stock:123 0 NX EX 30占位，再异步投递消息到队列（如 Redis Stream 或 Kafka），由消费者最终一致性处理 - ❌ 不要尝试用
WATCH监控某个 key 再PUBLISH——WATCH只影响后续EXEC，对PUBLISH完全无约束力
Pub/Sub 本身就不具备事务语义
即使绕过事务限制（比如用 Lua 脚本强行包裹），也无法获得原子性保障：
-
PUBLISH发送成功 ≠ 订阅者收到消息（网络丢包、客户端断连、缓冲区溢出都会导致丢失） - 订阅者收到消息的顺序不保证与
PUBLISH顺序严格一致（尤其跨多个 subscriber 连接时） - Redis 不存储 Pub/Sub 消息历史，
SUBSCRIBE之前发出的消息永远不可追溯
所以别把 Pub/Sub 当成可靠消息总线用；它适合实时通知、日志广播这类「最多一次」且允许丢失的场景。
真正需要原子协同的业务逻辑，必须拆解为「状态变更」+「异步触发」两阶段，并接受最终一致性。硬凑 Pub/Sub 到事务里，只会掩盖问题，让失败更难排查。
