PUBLISH返回1仅表示当前有1个在线订阅者，不保证消息被解析、处理成功或持久化；Redis Pub/Sub无重试、无确认、无历史回溯，断连即丢消息，无法满足支付回调的可靠性要求。
不能仅依赖 Redis Pub/Sub 做支付异步回调通知，因为它不保证消息可达、不支持重试、无法回溯、也不提供消费确认 —— 任何一环断开，用户支付成功但商户没收到通知，资金就卡住了。
为什么 PUBLISH 返回 1 不代表回调已送达
PUBLISH 命令返回的是当前在线订阅者数量（如 (integer) 1），它只说明“此刻有 1 个客户端连着这个频道”，不代表消息被反序列化、没抛异常、没写进 DB、更不代表风控或账务模块已完成校验。常见误判场景：
- 订阅服务刚启动，
SUBSCRIBE命令还没执行完，PUBLISH 就发了 → 返回 0，但不是失败，是“还没准备好” - 消费者在处理时触发了
redis.delete("order:123")但后续 DB 更新失败 → 消息已“收完”，业务却漏单 - 用 Lettuce 订阅，JVM Full GC 导致连接空闲超时被 Redis 踢掉 → 断连期间所有
PUBLISH永久丢失，无日志、无告警、无补发
断连后收不到历史支付事件，这是设计使然
Redis Pub/Sub 是纯广播模型，没有 offset、没有 cursor、不存消息体。只要订阅连接中断（哪怕只有 200ms），中间发布的 pay:success:1001 就彻底消失：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis-cli --csv pubsub channels只显示当前活跃频道，断连后频道名还在，但没人监听 - 重启消费者后执行
SUBSCRIBE pay:success:1001，不会收到之前那笔订单的任何信息 - 无法像 Kafka 那样指定
seek(offset)或 Redis Stream 那样XREAD ID $last_id补读
集群环境下顺序和事务都不可靠
支付回调必须保证“先创建订单，再通知成功”，而 Pub/Sub 在 redis-cluster 中天然破坏这个前提：
- 同一笔订单的两个事件（如
{"type":"created","id":"1001"}和{"type":"paid","id":"1001"}）可能被哈希到不同 master 节点 → 推送顺序错乱 -
PUBLISH不参与MULTI/EXEC，你没法把SET order:1001 "paid"和PUBLISH pay:1001 "ok"绑成原子操作 - 即使单机部署，也无法用
WATCH监控频道状态，不能基于 channel 变更做条件执行
真正能落地的替代方案长什么样
生产环境支付回调必须满足“至少一次 + 可追溯 + 可重放”，推荐链路是：
- 支付网关完成扣款后，写一条带唯一
trace_id的记录到 MySQL 状态表（含status=success,notify_status=pending） - 独立补偿服务定时扫描
notify_status=pending的记录，调用下游接口并更新为notified；失败则重试 + 告警 - 若需实时性，可用 Redis Stream 替代 Pub/Sub：
XADD pay:stream * event_type "success" order_id "1001" trace_id "t-abc"，再由消费者组XREADGROUP GROUP g1 c1 COUNT 1 STREAMS pay:stream >拉取，配合XACK和XPENDING管理未确认消息
最后强调一点：微信支付回调本身就有重试机制，且明确要求商户做幂等校验 —— 这恰恰说明“通知通道不可靠”是共识。拿 Pub/Sub 当主通道，等于主动放弃这个兜底能力。
