下一輪中心化交易所（CEX）配對引擎的競爭焦點，不再是「每秒能處理多少筆交易」——而是機構訂單路徑上的端到端延遲與尾部波動。 從客戶端 API 閘道到匹配核心、訂單確認及市場數據分發，整個處理流程必須以微秒為單位進行測量，並須針對高頻做市商提供可承諾的 P99 / P99.9 服務水準協議（SLA）。 SoonTech 的低延遲配對引擎涵蓋核心繞過（DPDK / io_uring）、無鎖佇列、 NUMA 親和性、FPGA 加速、尾部延遲消除、快速快照恢復以及機構級 SLA 報告——確保與一線中心化交易所（CEX）競爭高頻交易（HFT）流量的白標交易所，不會在「200 微秒上限」測試中遭淘汰。

1. 產業背景

中心化交易所（CEX）的配對引擎歷經三代演進：

1. 第一代（2013–2018）——單執行緒配對 + REST API，延遲達數毫秒。 Mt.Gox、早期 OKCoin、Bitfinex。匹配核心運行於通用雲端實例上；每秒交易量（TPS）僅數萬級；做市商更關注「能否連線」而非 P99 值。
2. 第二代（2018–2022）——多核心匹配 + WebSocket + 無鎖佇列，延遲數百微秒。 Binance、Bybit、OKX。採用環形緩衝區、按符號分片，WebSocket 推送取代了 REST 長輪詢。做市商開始要求平均從下單到確認（Order-to-ACK）時間低於 300 微秒。
3. 第三代（2022–至今）——內核繞過 + NUMA 親和性 + FPGA 加速，延遲縮短至數十微秒。機構級通道配備機房共置、專用光纖及 PTP 時間同步。做市商關注點從平均值轉向 P99 / P99.9 / P99.99 的尾部抖動。

在 SoonTech 的白標客戶群中，過去 18 個月間，市場造市商與高頻交易客戶提出的問題已從「你們的每秒交易筆數（TPS）是多少？」轉變為「根據服務水準協議（SLA），你們能承諾達到什麼樣的 P99 訂單至確認（Order-to-ACK）延遲？」 原因有二：其一，加密貨幣現貨與永續合約的套利窗口如今以毫秒為單位衡量；其二，當前這波市場造市商多為傳統市場的老將（如 Jump、Optiver、Jane Street、IMC 風格），他們將在傳統市場的 P99 期望原封不動地帶入了加密貨幣領域。

2. 市場痛點

• API 閘道延遲過高——通用雲端閘道中堆疊的 TLS 卸載、身份驗證、速率限制及稽核記錄，輕易就會消耗數百微秒。 網關也是 P99 違規的主因：TLS 重新協商、速率限制滑動視窗的輪替，以及日誌清空阻塞，都會將特定訂單的延遲拉高至平均值的 10 倍。
• 核心開銷 — Linux 網路堆疊的套接字緩衝區、上下文切換以及中斷處理，在高吞吐量下會產生抖動。 10G / 25G 網卡的 NAPI 中斷會將核心從用戶空間的配對迴圈中拉出，導致引擎不斷在「處理下一個訂單」與「處理中斷」之間切換——P99 指標因此崩潰。
• 鎖爭用 — 多執行緒匹配核心在訂單簿上使用互斥鎖（mutex）／自旋鎖（spinlock），在中等並發量下會出現爭用；這意味著表面看似正常，但 P99.9 會出現長尾現象。
• 市場資料傳輸緩慢 — 配對過程可能僅需數十微秒，但市場資料分發（訂閱 → 編碼 → WebSocket 推送）往往需耗時數百微秒至數毫秒。ACK 確認與市場資料接收之間的差距，正是實際的套利窗口。
• P99 波動 — 機構關注的重點是 P99 / P99.9，而非平均值。垃圾回收暫停、記憶體分配、TLB 缺失以及 NUMA 跨插槽存取，都會在長尾部分留下延遲「釘子」。 5 毫秒的 GC 暫停意味著 25 筆訂單被排入佇列——市場製造商會立即察覺並削減其配額。

共同點在於：問題不在於配對演算法，而在於其周邊的 I/O、記憶體、排程與分發機制。配對演算法在過去十年間早已是已解決的問題——真正的挑戰在於讓整個端到端路徑具有可預測性。

3. 數據與趨勢

數字背後四大新趨勢：

• 技術手段已商品化；機構追求確定的 P99 / P99.9 效能；
• 機房共置已成常態——競爭現已轉向物理層；
• 時間同步至關重要——PTP（IEEE 1588）精準度已成為跨場域套利交易日益重要的要求；
• P99.9 為紅線——許多市場造市商將 P99.9 < 1 毫秒視為硬性簽約門檻。

競爭焦點已從「每秒交易量（TPS）」轉向「穩定的 P99 / P99.9」。任何希望爭取機構資金流的白標交易所，都必須原生支援上述所有八個維度的功能。

4. 案例分析：引入高頻交易市場造市商

匿名化情境：某新加坡高頻交易做市商（HFT MM）在 15 組主要現貨交易對及 5 組永續合約交易對上投入 5,000 萬美元的庫存，並將簽署門檻設定為「從訂單到確認（Order-to-ACK）」的 P99 < 200 微秒、P99.9 < 800 微秒。SoonTech 的調校路徑：

• 步驟 1（硬體層）：市場造市商機櫃與匹配叢集同置於同一台 ToR 交換機下，跳線長度 < 50 公尺；採用 25G 雙埠網路介面卡（NIC），將訂單與 ACK 分開傳輸至不同埠以隔離中斷請求（IRQ）；PTP 時間同步功能整合至 NIC 硬體層。
• 步驟 2（API 閘道）：閘道採用 DPDK 核心繞過模式；TLS 握手過程於啟動時預先快取；認證／速率限制／稽核皆在使用者空間執行；速率限制採用無鎖令牌桶機制；閘道至配對節點的路徑使用共享記憶體佇列取代套接字。
• 步驟 3（匹配核心）：核心將每個符號固定至 NUMA 節點，確保同一符號的指令絕不跨接套接字；採用快取對齊的優先級佇列 + SPSC 佇列，完全無鎖；C++/Rust 核心無垃圾回收機制；記憶體採用池化管理 — 熱路徑上不使用 malloc。
• 步驟 4（ACK 路徑）：使用者空間 UDP 搭配直接映射至 MM 機櫃的記憶體映射；採用二進位緊湊協定，無需 JSON 序列化。
• 步驟 5（市場數據）：將訂單簿頂端（Top-of-Book）的變動量編碼為固定長度的二進位幀，於 FPGA 上處理並進行多播；FPGA 標記奈秒級的硬體時間戳記。
• 步驟 6（穩定性與故障轉移）：主備熱故障轉移，搭配記憶體內快照恢復機制。 端到端 P99 穩定值低於 180 µs，P99.9 低於 700 µs — MM 簽署，且連續 30 天的 P99/P99.9 報告成為每月 SLA 的交付成果。

低延遲匹配並非取決於「更快的 CPU」或「更多核心」——而是將 API 閘道、核心繞過、無鎖佇列、NUMA 親和性、FPGA 加速以及熱故障轉移，轉化為可承諾的機構級訂單路徑。 若缺乏端到端的一致性，任何單點優化都毫無價值：若 500 µs 閘道後方存在 200 µs 的核心延遲，仍會導致 MM 失敗。

5. SoonTech 功能

5.1 核心繞過

• 基於 NIC 與作業系統組合的 DPDK / io_uring 雙模式。
• 使用者空間 TCP / UDP 堆疊（F-Stack 或自研）；支援 HTTP/2 及 QUIC。
• 具備 CPU 隔離（isolcpus / nohz_full）的硬體卸載（RSS / RDMA / TSO / GRO）。
• 遷移工具鏈 — 業務程式碼變更幅度為 10–15%。

5.2 無鎖匹配核心

• SPSC / MPSC 環形緩衝區 + 無鎖優先級佇列。
• 按符號分片 — 符號內強一致性、跨符號並行處理。
• 快取行對齊 + 假共享管控。
• C++ / Rust 核心，熱路徑上無垃圾回收 (GC) 且無 malloc。

5.3 NUMA 親和性

• 將執行緒與實體核心緊密綁定；無超執行緒干擾。
• 本地記憶體分配（numactl + jemalloc / mimalloc）。
• 中斷親和性 — 網路介面卡（NIC）中斷處理位於專用核心上。
• HugePage / THP 管理機制。

5.4 FPGA 加速

• 市場數據編碼／解碼 IP 核心（SBE 或自研緊湊協定）。
• 硬體時間戳記（PTP + 網卡層級）。
• SoonTech 客製化 IP 核心 — 預匹配過濾可在非法訂單抵達核心之前，於 FPGA 上予以拒絕。
• FPGA／CPU 雙模式熱備援。

5.5 消除尾部延遲

• 消除垃圾回收暫停 — 採用 C++/Rust 核心，Java 僅用於管理平面。
• 記憶體池化（物件池 + 板塊分配器）。
• 透過核心追蹤與 eBPF 監控 P99 / P99.9 抖動。
• 中斷匯合（NAPI / adaptive-rx）與 CPU C 狀態管理。

5.6 快速快照恢復

• 內核級快照持久化（記憶體映像 + WAL）。
• 冷啟動時間低於 5 秒；主備機故障轉移時間低於 1 秒。
• 快照驗證（Merkle 摘要 + 結算對帳）。
• 快照可重複用於災難演練及合規重播。

5.7 機構級 SLA 報告

• 每週 P99 / P99.9 / P99.99 波動報告。
• 每月訂單至確認（Order-to-ACK）時程表 + 熱點分析。
• 已對齊市場製造商（MM）關鍵績效指標（成交貢獻率、報價佔比）。
• 供機構及監管機構使用的事件重播介面。

6. 企業級實施建議

1. 量化訂單路徑的 P99 / P99.9 端到端時間 — 無需儀器監測，無需優化。
2. 部署核心繞過機制 — DPDK 或 io_uring；移除閘道與核心之間的套接字。
3. 採用無鎖佇列 + 按符號分片。
4. 落實 NUMA 親和性 — 將 CPU、記憶體、中斷 (IRQ) 及 HugePage 整合為一，而非零散處理。
5. 整合 FPGA 加速 — 首先從市場資料編碼與預配對篩選著手。
6. 建立快照恢復與熱備援機制 — 作為強制性的 SLA 安全網。
7. 以合約形式承諾 P99 / P99.9 SLA，並包含每月報告與違約條款。
8. 部署時間同步與硬體時間戳記 — 跨交易場所套利與合規性皆仰賴此功能。

供應商篩選清單

• DPDK / io_uring 核心繞過機制。
• SPSC / MPSC 無鎖佇列 + 按符號分片。
• NUMA 親和性 + 中斷請求 (IRQ) 調校。
• 原生 FPGA 加速。
• P99 / P99.9 服務水準協議 (SLA) 報告 + 違約條款。
• 次秒級快照恢復 + 故障轉移。
• PTP 時間同步 + 硬體時間戳記。
• 用於合規稽核的事件重播介面。

7. 未來展望

2026–2028 年間：

1. 矽晶片匹配 — 核心匹配邏輯燒錄至 FPGA／ASIC；熱路徑可預測性與傳統證券市場相當。
2. 雲原生並行處理 — 在 Kubernetes 環境下針對各交易標的進行分散式配對，採用本地儲存與共享記憶體的混合架構；跨交易標的進行非同步對帳。
3. 嵌入式合規 — 在匹配前擷取「認識你的交易對手」（KYT）／制裁及「旅行規則」資料，且不增加延遲；於 FPGA 端進行匹配前篩選。
4. 值得信賴的端到端時間戳記 — 涵蓋配對、確認回執（ACK）、市場數據及結算的 PTP 硬體時間戳記，為合規稽核與跨交易場所套利提供統一的時間基準。

配對引擎不再僅是「一個軟體工程問題」——它是一款機構級、以 P99/P99.9 為優先、內嵌合規功能且具備時間戳意識的訂單路徑產品。 任何追求下一輪機構客戶導入的白標交易所，都必須將其配對引擎的路線圖提前 12 至 18 個月鎖定。

常見問題

Q1：每家中心化交易所（CEX）都需要 FPGA 嗎？

A1：不——對大多數情況而言，核心繞過（kernel bypass）加上無鎖佇列（lock-free queues）已足夠；FPGA 僅適用於極低延遲（P99 < 100 µs）的情境，或當需要預匹配過濾／硬體時間戳記時。純粹使用 CPU 即可實現低於 300 µs 的 P99 延遲。

Q2：核心繞過技術的顛覆性有多大？

A2：影響程度中等——DPDK／io_uring 適配器可將業務程式碼變更幅度控制在 10–15%，但效能／可觀察性堆疊需要重建；預計工程團隊需 6–8 週時間來掌握新的使用者空間堆疊。

Q3：如何消除 P99 抖動？

A3：從七個面向著手——垃圾回收暫停、記憶體分配、執行上下文切換、NUMA 跨插槽、C-state、TLB 缺失、HugePage——再加上 SoonTech 基於 eBPF 的調校工具鏈。

Q4：分片匹配會影響一致性嗎？

A4：分片是按符號進行的；透過 SPSC 佇列排序確保符號內的強一致性；並在各分片之間進行非同步對帳。帳戶層級的狀態會維持強一致性，以防止跨符號的損益（PnL）穿透。

Q5：快照恢復會影響可用性嗎？

A5：主備系統 + 增量快照 — 1 秒內完成故障轉移；可用性 >99.99%。每月完整快照 + 災難復原演練均納入機構級 SLA 規範。

Q6：機構級 SLA 報告的內容為何？

A6：每月報告包含 P99 / P99.9 / P99.99 百分位數延遲、訂單至確認（Order-to-ACK）時程、抖動熱點分析、故障轉移記錄及時鐘漂移；以 CSV + PDF 格式提供，供市場營運商（MM）合規歸檔之用。

Q7：是否必須採用機房託管？

A7：對於高頻交易（HFT）市場造市商（MM）而言，是的。在 P99 < 200 µs 的目標下，跳線長度、光纖衰減及交換機跳數都會影響延遲；採用機房共置可將網路延遲從毫秒級降至數十微秒級。

結論

下一輪交易所（CEX）匹配引擎的競爭，將聚焦於機構級 P99 / P99.9 指標。 SoonTech 的低延遲匹配技術，將核心繞過、無鎖佇列、NUMA 親和性、FPGA 加速、尾部延遲消除、快速快照恢復以及機構級 SLA 報告整合為單一可承諾的機構級訂單路徑產品。 任何計劃進軍機構市場的白標交易所，都應在合規、清算或市場造市者（MM）激勵措施之前，先確定其交易匹配引擎的路線圖——因為一旦市場造市者在評估階段拒絕您，下游的所有產品都將失去機會。

🌐 與 SoonTech 攜手打造安全且可擴展的 Web3 平台。

探索我們針對白標加密貨幣交易所、預測市場、MPC 錢包、配對引擎、流動性整合及合規性的解決方案。