1. 行情网关架构概览

各位同学好，我是老张。在金融交易系统里摸爬滚打了十几年，今天咱们聊聊嵌入式行情网关。

说实话，行情网关这玩意儿，看着不起眼，但它是整个交易系统的"眼睛"。没有它，你再牛的交易策略都是瞎子。我见过太多团队，策略写得天花乱坠，结果行情网关一压测就崩，那叫一个惨。

什么是嵌入式行情网关

简单说，行情网关就是连接交易所和内部系统的"翻译官"。它从交易所拿到原始行情数据，解析成内部能用的格式，再分发给各个业务模块。

为什么叫"嵌入式"？因为它通常跑在交易服务器上，跟交易引擎同进程部署。这样做的好处是延迟极低——数据不用跨网络，直接内存传递。我在项目中遇到过，有些团队把行情网关单独部署成微服务，结果延迟多了几十微秒，做高频交易的根本受不了。

嗯，这里要注意：嵌入式不等于简单。恰恰相反，它要处理的问题非常复杂。

核心功能模块

行情网关一般分三层，我习惯这么划分：

接入层

这一层负责跟交易所"握手"。说白了，就是建立网络连接、管理会话、处理心跳。

• 协议适配：每家交易所的协议都不一样。上交所用STEP，深交所用Binary，期货用FIX。你得给每家都写一个适配器。
• 连接管理：断线重连、主备切换、流量控制。我曾经遇到过一个坑：交易所行情爆发时，瞬间涌入大量数据，网卡缓冲区直接撑爆。后来加了应用层流控才解决。
• 数据校验：CRC校验、序列号检查、时间戳验证。别小看这一步，数据错一个字节，后面全完蛋。

协议解析层

这是最核心的一层。原始行情数据是二进制流，你得把它解析成结构体。

// 一个简化的行情解析示例
struct MarketData {
    uint64_t timestamp;   // 时间戳，纳秒级
    char     symbol[8];   // 合约代码
    double   last_price;  // 最新价
    uint64_t volume;      // 成交量
    double   bid_price;   // 买一价
    double   ask_price;   // 卖一价
};

// 解析函数
int parse_market_data(const char* raw, size_t len, MarketData* out) {
    // 这里省略了具体的位操作和校验逻辑
    // 实际项目中，这一步要极致优化
    memcpy(out, raw, sizeof(MarketData));
    return 0;
}

你想想看，一秒钟几万笔行情，每笔都要解析。解析慢了，后面的分发就得排队。我见过有人用std::string来存行情数据，结果内存分配成了瓶颈。后来全改成栈上分配，性能直接翻倍。

分发层

解析完的数据，得发给各个订阅者。这里有两种模式：

• 推模式：行情一来，主动推给所有订阅者。延迟低，但订阅者处理不过来会丢数据。
• 拉模式：订阅者自己来取。控制权在订阅者手里，但延迟会高一些。

我个人习惯用推模式，配合无锁队列。为什么？因为高频场景下，延迟就是金钱。但要注意，无锁队列的ABA问题是个大坑，我曾经在这个问题上debug了整整两天。

性能指标定义

做性能调优，你得先知道"好"的标准是什么。我一般看三个指标：

指标	定义	典型要求	我的经验值
吞吐量	单位时间内处理的行情笔数	≥ 10万笔/秒	优化后可达50万+
延迟	从数据到达网关到分发出去的耗时	≤ 10微秒	极致优化可到1微秒以内
抖动	延迟的波动范围（P99 - P50）	≤ 5微秒	这个最难搞，GC和中断是元凶

吞吐量好理解，就是"能扛多少活"。延迟是"干得快不快"。抖动呢？说白了就是"稳不稳"。

我遇到过最头疼的问题：平均延迟只有2微秒，但P99延迟飙到100微秒。查了半天，发现是Linux内核的CFS调度器在作祟。后来把行情线程绑到独立CPU核心上，才把抖动压下来。

架构总览图

下面这张图，是我画了无数遍才定下来的。它展示了行情网关的核心数据流：

这张图我画得很克制，只展示了最核心的数据流。实际项目中，还有日志、监控、热切换等模块，但那些是锦上添花。先把这三层搞明白，后面的章节我们再逐个深入。

好了，第一章就到这里。记住：行情网关不是花架子，每一行代码都跟真金白银挂钩。后面我们会从接入层开始，一步步把性能榨干。

---

公众号:蓝海资料掘金营，微信deep3321