2. 消息队列核心模型：深入理解点对点模型与发布订阅模型，在交易场景下的选择策略
消息队列的模型选择，说白了就是决定「谁」能拿到「什么」消息。我在交易系统里踩过不少坑，今天跟你聊聊两种核心模型——点对点和发布订阅。它们看起来简单，但选错了，系统可能直接崩掉。
2.1 点对点模型（P2P）
点对点模型，也叫队列模型。一个消息只能被一个消费者消费。消息进入队列后，多个消费者竞争，谁抢到算谁的。
核心特征：
- 一条消息只被一个消费者处理
- 消息一旦被消费，就从队列中移除
- 消费者之间是竞争关系
- 天然支持负载均衡
我在做订单处理系统时，就用点对点模型。订单消息进入队列，多个处理节点抢着处理。为什么？因为一个订单只能被处理一次，重复处理就出大问题了。
我的经验：点对点模型最适合「任务分发」场景。比如订单处理、风控校验、清算对账。每个任务只需要一个worker处理，多了反而乱。
2.2 发布订阅模型（Pub/Sub）
发布订阅模型就完全不一样了。一个消息可以被多个消费者同时消费。生产者发布消息到Topic，所有订阅了这个Topic的消费者都能收到。
核心特征：
- 一条消息可以被多个消费者消费
- 消费者之间是独立关系
- 消息通常持久化在Topic中
- 支持广播模式
我记得有一次做行情系统，行情数据需要同时推送给交易引擎、风控系统、监控平台。这时候用点对点模型就傻了——每个系统都得单独发一份。发布订阅模型正好解决这个问题，行情Topic一发，所有订阅者都能收到。
2.3 交易场景下的选择策略
你想想看，交易系统里什么场景用点对点，什么场景用发布订阅？我总结了一套选择策略，直接上表格。
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 订单处理 | 点对点 | 一个订单只需一个处理器 |
| 行情推送 | 发布订阅 | 多系统需要同时接收 |
| 风控校验 | 点对点 | 避免重复校验 |
| 交易日志 | 发布订阅 | 归档、分析、监控都需要 |
| 清算对账 | 点对点 | 任务隔离，互不干扰 |
| 系统通知 | 发布订阅 | 所有节点需要感知 |
避坑指南：我曾经在一个项目里，把行情推送用成了点对点模型。结果每个消费者都单独拉取行情，导致行情网关压力巨大，延迟飙升。后来改成发布订阅，问题直接解决。选错模型，代价很大。
2.4 混合使用策略
实际交易系统中，很少只用一种模型。我习惯把两种模型混着用。比如一个交易链路：
- 订单进入时，用点对点模型分发到不同的处理节点
- 订单状态变更时，用发布订阅模型通知所有相关系统
- 成交结果产生时，点对点模型写入数据库，发布订阅模型推送给行情和风控
嗯，这里要注意。混合使用时，一定要做好消息的幂等处理。因为发布订阅模型下，同一个消息可能被多个消费者处理，如果处理逻辑有副作用，必须保证幂等。
2.5 核心逻辑框架图
下面这张图，我画了两种模型在交易系统中的典型应用。你看一眼就明白了。
2.6 性能与可靠性权衡
选模型时，还得考虑性能和可靠性。我直接说结论：
- 点对点模型：性能更高，因为消息不需要复制给多个消费者。但可靠性依赖队列的持久化机制。
- 发布订阅模型：灵活性更高，但性能开销大。每个订阅者都要独立消费，消息复制有成本。
我在做高频交易系统时，行情推送用的发布订阅，但做了优化——订阅者分组，同组内用点对点竞争消费。这样既保证了广播，又实现了负载均衡。
我的建议：别死磕一种模型。交易系统里，灵活组合才是王道。先画清楚数据流图，再决定每个环节用什么模型。模型选对了，后面少改很多代码。
好了，关于点对点和发布订阅，今天就聊这么多。记住一句话：点对点解决「谁来做」，发布订阅解决「谁知道」。交易场景下，两者缺一不可。