3. Serving策略基础：Serving层定义、在量化交易链路中的位置与核心目标

3.1 Serving层定义

Serving层（在线服务层）是量化交易系统中直接面向行情数据消费与交易决策执行的中间层。它负责将经过清洗、加工、存储的行情数据，以极低延迟、高吞吐的方式推送给策略引擎或交易执行模块。Serving层是连接“数据生产”与“策略消费”的桥梁，也是整个链路中延迟敏感度最高的环节。

Serving层通常以发布-订阅（Pub/Sub）模式工作，支持多策略、多交易标的的并行订阅。它不负责策略逻辑计算，也不负责订单路由，只专注于将正确的数据在正确的时间送达正确的消费者。

3.2 Serving层在量化交易链路中的位置

量化交易系统的典型数据流链路如下：

1. 交易所行情网关 — 接收原始行情（Tick/Level2）
2. 行情解码与校验层 — 协议解析、去重、时间戳校准
3. 行情加工与聚合层 — K线合成、价差计算、指标衍生
4. 行情存储层 — 历史行情数据库、快照存储
5. Serving层 — 实时分发、订阅管理、协议转换
6. 策略引擎 — 信号生成、订单管理
7. 交易执行层 — 订单路由、风控检查、交易所对接

Serving层位于第5层，是数据从“加工完成”到“策略消费”的最后一公里。其性能直接决定了策略能否在毫秒甚至微秒级别响应市场变化。

3.3 Serving策略的核心目标

Serving策略的设计围绕三个核心目标展开：低延迟、高可用、一致性。这三个目标相互制约，需要在架构设计中做权衡。

3.3.1 低延迟

低延迟是Serving层最核心的竞争力。在量化交易中，微秒级的延迟差异可能直接转化为盈亏。Serving层的延迟优化通常从以下维度展开：

• 数据路径优化：减少数据拷贝次数，使用共享内存或RDMA直接传输。
• 线程模型：采用Reactor模式或Busy-polling，避免上下文切换。
• 序列化/反序列化：使用FlatBuffers、Cap'n Proto等零拷贝序列化方案。
• 网络协议：基于UDP组播或TCP私有协议，减少协议栈开销。

3.3.2 高可用

Serving层一旦中断，所有依赖实时行情的策略将立即失效。高可用设计需要覆盖以下场景：

1. 节点故障：主节点宕机后，备用节点在1秒内接管服务。
2. 网络分区：多机房部署，避免单点网络故障影响全局。
3. 流量突增：行情爆发时（如开盘、重大事件），Serving层需具备弹性扩缩能力。
4. 数据源切换：交易所行情源切换时，Serving层需平滑过渡，不中断服务。

3.3.3 一致性

一致性保证所有策略在同一时间点看到相同的行情数据。在分布式Serving架构中，一致性面临以下挑战：

• 数据乱序：网络传输或多线程处理可能导致行情数据到达顺序与交易所产生顺序不一致。
• 数据重复：故障切换或重传机制可能导致同一笔行情被多次投递。
• 数据丢失：缓冲区溢出或网络丢包可能导致行情缺失。

一致性保障的常用策略：

3.4 三个目标的权衡关系

低延迟、高可用、一致性三者之间存在经典的CAP-like权衡：

• 低延迟 vs 高可用：高可用需要冗余和故障检测，这会增加数据路径的延迟。例如，主备切换需要心跳检测和状态同步。
• 低延迟 vs 一致性：严格一致性需要排序、去重、等待窗口，这些操作都会增加延迟。放松一致性要求可以换取更低的延迟。
• 高可用 vs 一致性：故障切换时，如果追求高可用快速切换，可能牺牲数据一致性（如丢包或重复）。

在实际Serving策略设计中，需要根据业务场景确定优先级：