核心概念与术语：报价流、询价流、成交流、做市商、流动性提供商
好，咱们正式开始聊报价路由系统的核心概念。说实话，这些术语你如果去翻金融教科书，每个都能写一整章。但在我眼里，它们就是四个流和两类角色。搞懂了这些，整个系统的骨架你就抓住了。
报价流（Quote Flow）
报价流，说白了就是市场里不断刷新的买卖价格。做市商不停地喊：「我出价买，我出价卖」，这些喊价信息像水流一样涌向交易系统。
我个人习惯把报价流分成两类：
- 被动报价：做市商提前挂好的双边价格，比如 EUR/USD 一直挂着 1.1050/1.1052
- 主动报价：针对特定询价请求给出的即时价格，时效性极强
关键点：报价流的核心指标是「报价更新频率」和「报价深度」。我在项目中遇到过一家做市商，每秒推送 5000 条报价更新，结果我们的路由系统直接被打满了 CPU。后来加了报价聚合层才扛住。
报价流在系统里通常用 Quote 对象表示：
{
"instrument": "EUR/USD",
"bid": 1.1050,
"ask": 1.1052,
"bidVolume": 1000000,
"askVolume": 1000000,
"timestamp": 1712345678000,
"provider": "MS_BANK"
}询价流（RFQ Flow）
询价流，就是交易员发起的价格询问。你想想看，当一个大客户想交易 5000 万欧元，他不会直接按市场价打，而是先问一圈：「你们谁给的价格好？」
RFQ（Request For Quote）的典型流程：
- 交易员发起询价，指定品种、数量、方向
- 路由系统把询价分发给多个做市商
- 做市商在规定时间内回复报价
- 系统收集所有回复，选出最优价
- 交易员决定是否成交
实战经验：我曾经优化过一个 RFQ 路由逻辑，发现 80% 的询价其实只需要发给 3 家核心做市商。盲目广播反而会泄露交易意图，让市场知道你急着买。嗯，这里要注意——询价流的「隐私保护」比你想的重要得多。
成交流（Execution Flow）
成交流，就是交易真正发生的那一刻。报价流和询价流都是「前戏」，成交流才是「高潮」。
成交流包含几个关键阶段：
| 阶段 | 说明 | 耗时要求 |
|---|---|---|
| 订单提交 | 交易员点击「成交」按钮 | < 1ms |
| 路由决策 | 系统决定发给哪个做市商 | < 100μs |
| 做市商处理 | 做市商确认成交或拒绝 | < 10ms |
| 成交回报 | 结果返回给交易员 | < 5ms |
这里有个坑，我踩过。成交流的「原子性」非常重要——要么全成，要么全不成。有一次系统在处理成交流时，订单已经发给做市商 A 成交了，但做市商 B 的回复还没回来，结果系统误判为「部分成交」，导致账目对不上。后来我们引入了两阶段提交协议才解决。
做市商（Market Maker）
做市商，就是那些天天在市场上喊价的人。他们不是来炒作的，是来提供流动性的。你想想看，如果没有做市商，你想买 100 万欧元，可能等半天都找不到卖家。
做市商的核心特征：
- 双边报价：同时报买入价和卖出价，赚取差价
- 持续报价：交易时间内必须持续提供报价
- 义务成交：在报价范围内必须接受成交
注意：不是所有做市商都靠谱。我见过一些「伪做市商」，平时报价很积极，一到市场剧烈波动就撤单或者拒绝成交。路由系统必须能识别这种行为，降低他们的路由优先级。
流动性提供商（Liquidity Provider）
流动性提供商的范围比做市商更广。做市商是流动性提供商的一种，但流动性提供商还包括：
- 银行：传统的大额流动性来源
- ECN（电子通信网络）：撮合多个参与者的订单
- 对冲基金：有时也提供流动性
- 其他交易平台：比如 FXAll、Hotspot
我个人习惯把流动性提供商分成 Tier 1 和 Tier 2：
| 层级 | 特点 | 典型代表 |
|---|---|---|
| Tier 1 | 报价深、信用好、延迟低 | 摩根大通、德意志银行 |
| Tier 2 | 报价灵活、可定制、但深度有限 | 区域性银行、做市商 |
四个流的关系
这四个流不是孤立的。我画了一张图，帮你理清它们的关系：
从图上你能看到：报价流持续注入路由引擎，询价流按需触发，成交流是最终产出。路由引擎就是那个「大脑」，它决定把哪个流发给哪个做市商。
我的建议：刚开始设计系统时，别急着优化性能。先把这四个流的边界定义清楚。我在第一个版本里把报价流和询价流混在一起处理，结果代码越写越乱，重构了两次才理顺。先分清楚，再谈优化。
好了，核心概念就这些。记住这四个流和两类角色，你就能看懂大部分报价路由系统的设计文档了。下一节我们会深入路由引擎的内部，看看它到底是怎么做决策的。
公众号:蓝海资料掘金营，微信deep3321