3、行情处理流水线并行化设计：流水线设计模式
3.1 什么是流水线？
流水线这个概念，说白了就是把一个大任务拆成几个小步骤，每个步骤交给不同的人（或者线程）去干。就像工厂里的装配线——一个人拧螺丝，一个人装轮子，一个人喷漆。每个人只干自己的活，干完就传给下一个人。
我在做量化系统的时候，一开始也是傻乎乎地单线程处理行情。一个 tick 进来，从解析、清洗、计算指标到推送策略，全在一个循环里搞定。结果呢？行情一密集，CPU 就飙到 100%，后面还堵了一堆 tick 没处理。后来我意识到，这其实就是典型的「串行瓶颈」。
流水线的核心思想就八个字：分工协作，并行推进。每个阶段只关心自己的事，做完就丢给下一个阶段。这样整个系统的吞吐量就能大幅提升。
流水线的本质： 将串行处理拆解为多个并行阶段，每个阶段独立运行，通过队列或缓冲区连接。
3.2 生产者-消费者模型
流水线的底层支撑，其实就是经典的生产者-消费者模型。你想想看，行情源就是生产者，它不停地往外吐数据。而我们各个处理阶段，就是一层层的消费者。
但这里有个坑——生产速度和消费速度不匹配。生产者太快，消费者来不及处理，数据就会堆积。消费者太快，生产者又跟不上，消费者就会空转。
我曾经在一个项目中，直接用无界队列来缓存行情数据。结果行情爆发时，内存直接爆了，系统 OOM 崩溃。嗯，从那以后我再也不敢用无界队列了。
正确的做法是：
- 使用有界阻塞队列，比如 Java 的
ArrayBlockingQueue - 设置合理的队列容量，通常根据行情峰值估算
- 当队列满时，要么丢弃旧数据，要么阻塞生产者
我的经验： 对于高频行情，我建议用「丢弃旧数据」策略。因为行情数据时效性极强，旧数据留着也没用，反而会拖慢系统。
3.3 数据流图与阶段划分
设计流水线的第一步，就是画数据流图。我习惯用一张图把整个处理链路画出来，然后找到可以拆分的节点。
下面这张图是我在项目中实际用过的行情处理流水线结构：
从这张图你能看到，我把行情处理分成了 5 个阶段：
- 行情接入：负责从交易所接收原始数据包
- 协议解析：把二进制协议解码成结构化数据
- 数据清洗：去重、校验、补全缺失字段
- 指标计算：计算技术指标和统计量
- 策略推送：把处理好的数据发给策略模块
每个阶段之间都用有界阻塞队列连接。这样即使某个阶段卡住了，也不会影响其他阶段继续工作。
注意： 阶段划分不是越细越好。每个阶段都有上下文切换和队列传递的开销。我一般控制在 4-6 个阶段，再多反而得不偿失。
3.4 流水线的深度与吞吐量关系
流水线的深度，说白了就是有多少个阶段。深度和吞吐量之间，并不是简单的正比关系。
我刚开始做流水线设计时，总觉得阶段越多越并行，吞吐量就越高。结果有一次我硬生生把 4 个阶段拆成了 8 个，吞吐量反而下降了 20%。
为什么会这样？因为每个阶段都有固定的开销：
- 队列传递延迟：数据从一个阶段传到下一个阶段，需要入队出队操作
- 上下文切换：线程切换有 CPU 开销
- 缓存失效：数据在不同线程间传递，CPU 缓存会失效
下面这张表是我在项目中实测的数据：
| 流水线深度 | 单 tick 延迟 (μs) | 最大吞吐量 (tick/s) | CPU 使用率 |
|---|---|---|---|
| 2 阶段 | 12 | 83,000 | 45% |
| 4 阶段 | 18 | 155,000 | 68% |
| 5 阶段 | 22 | 178,000 | 82% |
| 6 阶段 | 28 | 165,000 | 91% |
| 8 阶段 | 41 | 132,000 | 97% |
你看，从 2 阶段到 5 阶段，吞吐量一直在涨。但到了 6 阶段以后，吞吐量反而开始下降。原因就是阶段太多，开销超过了并行带来的收益。
关键结论： 流水线深度存在一个最优值。对于行情处理系统，我建议深度控制在 4-6 个阶段。超过这个范围，边际收益递减，甚至为负。
另外还有一个容易被忽略的点——各阶段的处理时间要尽量均衡。如果某个阶段特别慢，它就会成为瓶颈，拖慢整个流水线。我习惯用 profiling 工具先跑一遍，找出最慢的阶段，然后想办法优化它。
避坑指南： 我曾经遇到过一个情况，数据清洗阶段因为要做复杂的校验逻辑，比其他阶段慢了 3 倍。结果整个流水线的吞吐量被它卡死了。后来我把校验逻辑拆成两级，才解决了这个问题。
总结一下流水线设计的几个要点：
- 阶段划分要合理，4-6 个阶段是最佳实践
- 各阶段处理时间要均衡，避免单点瓶颈
- 使用有界阻塞队列，防止内存溢出
- 监控每个阶段的队列长度，及时发现拥堵
嗯，流水线设计这部分就讲到这里。记住一句话：流水线不是越深越好，平衡才是关键。