数字货币撮合引擎原理：一笔订单从挂单到成交，到底经历了什么

数字货币撮合引擎原理：一笔订单从挂单到成交，到底经历了什么

搞了六年交易所后端，写过两个版本的撮合引擎，最深的一体感是：数字货币交易里最核心的那几十毫秒，全凭撮合引擎撑着。下面聊聊一笔订单从挂到成交，引擎里到底在跑什么。

你按下"买入"键，订单不是直接丢进一个池子就完事了。订单先过风控模块数字货币撮合引擎原理：一笔订单从挂单到成交，到底经历了什么，校验余额、合规、限速，通过后才进入价格优先、时间优先的撮合队列。数字货币7×24小时不停机，队列里同时可能挂着几十万笔订单，引擎要在微秒级完成排序。

撮合的核心逻辑其实不复杂：买单最高价和卖单最低价，谁先"碰到"谁就成交。但难点在于并发。BTC合约盘口每秒几千笔订单在进出，引擎不能锁整张订单簿，否则就退化成单线程了。我之前的方案是把盘口拆成价格档位，每档独立加锁，不同价格并行走，同一档内串行撮合引擎数字货币，吞吐上去了。

一旦配对成功，引擎生成成交记录，广播给所有订阅该品种的客户端，同时更新盘口深度。数字货币波动大，一次闪崩可能让订单簿瞬间清空再重建，引擎必须扛住这种"脉冲式"流量。我们压测时模拟过2019年BTC从9000砸到3500的场景，P99延迟不能超过5毫秒，否则滑损就把交易者坑了。

后来转去做量化，再回看自己的撮合代码，发现真正难写的是异常恢复——宕机重启后订单簿状态怎么秒级还原，比正常路径的代码量还大。这块东西公开文档里很少提，但生产环境里每天都在救火。