PUBLISH 返回值不能作为投递成功依据，因其仅返回当前在线订阅者数，不保证消息被处理、解析、存储或校验；Redis Cluster 下也不保证单频道内消息顺序。
Pub/Sub 的 PUBLISH 返回值为什么不能当作投递成功依据
PUBLISH 命令返回的是当前在线订阅者数量（例如 (integer) 2），它只反映“此刻谁在听”，不表示消息是否被业务逻辑处理、是否反序列化成功、是否写入数据库或触发风控校验。
常见错误现象：
- 返回
0≠ 消息失败：可能是订阅者刚启动，SUBSCRIBE命令还没抵达 Redis，或网络延迟导致状态未同步 - 返回
3≠ 消息安全：三个客户端中可能两个在 JSON 解析时 panic，一个在 DB 写入时抛出唯一键冲突，但PUBLISH早已返回 - 无法与下游形成因果链：你调用
PUBLISH trade:1001 {"amt":100.5}成功，不代表风控模块已更新用户限额——中间没有任何确认或事务锚点
集群环境下 Pub/Sub 为何连“单频道内顺序”都保不住
Redis Cluster 不保证同一 channel 的所有消息路由到同一个 master 节点。哈希槽迁移、重分片、节点临时离线都会导致消息跨节点转发，最终推送给客户端的顺序不可控。
典型风险场景：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端 A 向
channel:order连续PUBLISH两条消息：{"id":"101","status":"created"}和{"id":"101","status":"filled"} - 因 slot 分配变化，前者落在 node-1，后者落在 node-2；两个节点各自推送，订阅者收到顺序颠倒
- 风控服务看到 “filled” 却没看到 “created”，直接判定为异常交易，触发误拦截
-
PUBLISH不参与MULTI/EXEC，也无法用WATCH监控 channel 状态，无法和DECRBY user:1001 100.5绑定为原子操作
等保三级系统下 Pub/Sub 直接暴露的合规硬伤
等保2.0对三级系统明确要求“重要数据泄露可能造成重大经济损失”，而 Pub/Sub 在设计上天然违反多项核心条款：
- 无消息持久化：断连即丢，不满足“数据完整性保护”与“剩余信息保护”要求
- 无审计能力：
SUBSCRIBE/UNSUBSCRIBE不记日志，PUBLISH不记录发送方 IP 或 traceID，无法满足“安全审计”类测评项 - 无访问控制粒度：ACL 无法限制某用户只能
PUBLISH到trade:*但不能发到admin:*，全靠应用层兜底，不符合“访问控制”基线 - 传输未强制加密：若未启用
tls-port，明文传输交易事件，直接触犯“通信传输”条款
替代方案落地时最容易被忽略的边界
很多团队转向 Stream 后以为万事大吉，但真实金融系统里几个关键边界必须手动补位：
-
XADD不提供跨 Stream 事务：你无法让XADD order-stream和XADD risk-stream原子提交，需在应用层实现两阶段写或 Saga 补偿 -
XPENDING查到的未 ACK 消息，重投前必须做幂等判断——Stream 本身不校验 payload 是否重复，靠业务字段（如trade_id）+ 外部去重表 - 即使开了
MAXLEN ~ 1000000，也要监控stream.length增速，防止突发流量撑爆内存；等保测评会查INFO MEMORY中的used_memory_peak_human - Kafka 才是主事件总线的通用解法：Redis Stream 仅适合低延迟旁路（如行情快照刷新），别把它当主干消息通道来压测
真正卡住上线的，往往不是技术选型，而是没在架构图里标清楚：哪条链路允许丢消息，哪条必须至少一次，哪条要恰好一次——这些决定得写进等保《安全设计方案》文档，而不是藏在代码注释里。
