一、撮合引擎概述
1.1 什么是撮合引擎
撮合引擎，说白了就是交易系统的「心脏」。
它的核心任务很简单：把买单和卖单匹配起来。你挂一个买入订单，我挂一个卖出订单，系统得在毫秒级内判断能不能成交、以什么价格成交、成交多少。
我刚开始做交易系统时，觉得这不就是个排序+匹配嘛，有什么难的？后来真正上手才发现，这里面的坑多到你想象不到。嗯，咱们后面慢慢聊。
从技术角度看，撮合引擎是一个有状态的高性能计算引擎。它维护着订单簿（Order Book），实时处理源源不断的订单流，输出成交结果。
核心定义：撮合引擎 = 订单簿管理 + 价格优先/时间优先匹配 + 成交生成
1.2 撮合引擎在交易系统中的地位
一个完整的交易系统，通常包含这些模块：
- 接入层：接收客户订单，做风控检查
- 路由层：把订单分发到对应的撮合引擎
- 撮合引擎：核心匹配逻辑
- 结算层：处理资金和资产的划转
- 行情系统：发布实时成交数据
你看，撮合引擎处在中间位置。它前面连着接入和路由，后面连着结算和行情。一旦它出问题，整个交易系统就瘫痪了。
我记得有一次线上事故，撮合引擎因为内存泄漏导致GC停顿了3秒。就这3秒，交易所的订单堆积了十几万笔，恢复后瞬间爆发，直接把下游结算系统打崩了。那次之后，我们团队把撮合引擎的监控做到了「每笔订单耗时超过1ms就报警」的级别。
避坑指南：我曾经见过一个团队，把撮合引擎和业务逻辑混在一起写。结果每次业务改需求，撮合逻辑就得跟着改，改一次崩一次。记住：撮合引擎必须是独立的、无业务侵入的模块。
1.3 核心功能
撮合引擎到底要做什么？我把它拆成四个核心功能：
| 功能模块 | 说明 | 关键点 |
|---|---|---|
| 订单管理 | 接收、校验、存储订单 | 订单状态机必须严谨 |
| 订单簿维护 | 维护买盘和卖盘的价量队列 | 价格排序、数量聚合 |
| 匹配逻辑 | 按规则撮合买卖订单 | 价格优先、时间优先 |
| 成交生成 | 生成成交记录，更新订单状态 | 部分成交、完全成交的处理 |
你想想看，这四个功能环环相扣。订单管理做不好，后面的匹配就是空中楼阁。订单簿维护慢了，匹配速度就上不去。匹配逻辑写错了，那整个交易所就乱套了。
1.4 设计目标
设计一个撮合引擎，我们追求什么？我个人习惯用这四个指标来衡量：
- 高性能：单机每秒处理10万+笔订单是基本要求。我见过用Go写的撮合引擎，单核就能跑到50万TPS。
- 低延迟：从收到订单到返回成交，延迟要控制在微秒级。每多1微秒，对高频交易者来说都是真金白银。
- 确定性：同样的订单序列，无论跑多少次，结果必须完全一致。这是金融系统的铁律。
- 可恢复性：系统崩溃后，能从最近的快照恢复，不丢数据、不错数据。
个人经验：很多新手一上来就追求极致性能，结果忽略了确定性。我踩过这个坑——为了优化性能用了非确定性算法，结果回放日志时发现成交记录对不上。那次教训让我明白：金融系统里，正确性永远比性能重要。
下面这张图，是我自己总结的撮合引擎核心架构。你看一眼，基本就能理解整个系统的脉络了。
这张图展示的是最基础的撮合流程。实际生产环境中，每个环节都会复杂得多。比如订单校验这一步，除了基本的合法性检查，还要做资金校验、持仓校验、限价检查等等。
我个人习惯把撮合引擎的设计分成三个阶段：
- 第一阶段：实现基础功能，能跑通就行。这个阶段别想太多，先让系统动起来。
- 第二阶段：优化性能，引入内存数据库、无锁队列、批量处理等技术。
- 第三阶段：做容灾和可恢复性设计，保证系统7x24小时稳定运行。
很多团队在第一阶段就想着做到第三阶段的事，结果项目拖了半年还没上线。我的建议是：先跑起来，再跑快，最后跑稳。
一句话总结：撮合引擎是交易系统的核心，它负责把买卖双方的订单高效、公平、确定地匹配成交。设计时优先保证正确性，再追求性能，最后完善可靠性。