Redis Pub/Sub 不适用于金融交易场景，因其纯内存、无持久化、无确认机制，导致消息必然丢失；集群下无全局顺序且不支持事务，应改用 Streams 或 Kafka。
Redis Pub/Sub 无法保证消息不丢失
金融交易数据要求“至少一次”甚至“恰好一次”投递，而 PUBSUB 是纯内存、无持久化、无确认机制的广播模型。客户端断连期间发布的消息直接丢弃，SUBSCRIBE 命令本身也不返回历史消息 —— 这意味着只要订阅者网络抖动或重启，就必然漏掉事件。
常见错误现象：redis-cli 手动 SUBSCRIBE 后 Ctrl+C 断开，再 SUBSCRIBE 就收不到断连时发布的所有 PUBLISH 消息；应用进程崩溃重启后，中间几秒的成交价更新完全不可追溯。
- 没有重试队列，不支持 offset 或 cursor 回溯
- 发布者不知道谁在线、谁断线、谁没收到
- 即使搭配
CLIENT LIST查连接状态，也无法补发已丢失的消息
Pub/Sub 不提供消息顺序与事务保障
Redis 单实例内 PUBSUB 按接收顺序向每个客户端推送，但一旦部署为集群（redis-cluster），不同 channel 的消息可能被路由到不同 master 节点，天然失去全局顺序。更关键的是：它不参与 Redis 的 MULTI/EXEC 事务，也无法和 SET、INCR 等原子操作协同。
典型使用场景陷阱：你想在更新账户余额（DECRBY user:1001 100.5）的同时，通过 PUBLISH trade:1001 "{'amt':100.5}" 通知风控模块 —— 但这两步不是原子的。如果 DECRBY 成功而 PUBLISH 失败（如网络超时），风控看到的数据就是陈旧的；反之，PUBLISH 成功但 DECRBY 因 watch 失败回滚，风控却收到了一笔根本没发生的交易。
- 集群模式下跨 slot 的 channel 无法保证跨节点消息顺序
- 无法用
WATCH监控 channel 状态，不能纳入事务上下文 -
PUBLISH返回值只是接收者数量，不表示消息是否被消费
替代方案应优先考虑 Streams 或外部消息队列
如果必须用 Redis 承载金融事件流，XRANGE/XADD 构建的 Stream 是唯一可行路径：它支持消费者组（XGROUP）、ACK 确认（XACK）、未处理消息自动重投（XPENDING）、按 ID 回溯（XREAD with id），且单个 Stream 内严格保序。
但要注意：Stream 仍不提供跨 Stream 的分布式事务，也不能替代 Kafka/Pulsar 的副本仲裁与 ISR 机制。真实金融系统中，更常见的做法是用 Kafka 做主事件总线，Redis 仅作低延迟缓存（如最新行情快照），两者职责分离。
-
XADD trade-stream * amt 100.5 side buy是可追溯、可确认的基础操作 - 务必设置
MAXLEN防止内存无限增长，例如XADD ... MAXLEN ~ 1000000 - 不要把
Stream当作 WAL 使用 —— 它不保证磁盘落盘时序，RDB/AOF 仍是异步刷盘
监控和压测时容易忽略的隐性瓶颈
Pub/Sub 在高吞吐下会显著放大 Redis 的 CPU 和网络压力：每个 PUBLISH 都要遍历所有订阅该 channel 的客户端连接，逐个写 socket。当有数百个订阅者时，单次发布延迟可能从微秒级跳到毫秒级，且无法水平扩展 —— redis-cluster 中一个 channel 只能属于一个 master，成为热点节点。
性能影响常被低估：模拟 5000 TPS 的订单发布，若平均每个 channel 有 50 个订阅者，Redis 实际需执行 25 万次 socket write/s，远超单纯 SET 的负载。此时 INFO clients 中的 client_longest_output_list 会持续升高，最终触发连接踢出。
- 用
CLIENT LIST定期检查omem（输出缓冲区大小），超过 1MB 就危险 - 避免让业务服务直连 Redis 做订阅 —— 应通过网关聚合后推送给前端或下游
- 不要用
PUBSUB NUMSUB做健康检查依据，它只反映当前连接数，不反映消费能力
金融系统里，消息“发出去了”和“被正确处理了”之间隔着一整套可靠性设计。Pub/Sub 连前半句都做不到。
