集中式交易所的核心競爭力可歸納為三個關鍵詞：深度、速度與確定性。深度源自做市商與真實用戶的報價密度；速度源自配對引擎與網路路徑；確定性則源自透明的配對規則與可驗證的故障轉移機制。 無論投入多少行銷預算，若交易所能在牛市期間發生系統當機、在閃崩時導致訂單簿混亂，或在新上市後產生重複成交紀錄，都無法留住專業用戶。SoonTech 白標中心化交易所（CEX）的配對引擎與訂單簿子系統，將這三項特性轉化為可量化的工程指標： 每對交易對的穩態匹配延遲以微秒計、端到端往返時間在低毫秒級，以及主備機切換僅需數秒，且不會造成訂單遺失或重複。 本文將完整詳述匹配原理、訂單類型、訂單簿結構、內存匹配、持久化與恢復、市場數據串流、自交易防範、效能基準測試、災難復原、機構級存取權限，以及營運建議。

1. 為何配對引擎是中心化交易所（CEX）的核心

若將交易所比作一棟建築，則配對引擎便是其核心交易大廳。 每筆買單與賣單皆進入此處進行配對；每項價格、成交量及深度層級皆由此產生；每項清算、交割及風險決策皆取決於其產出的執行報告。當配對引擎暫停運作時，整個交易所便隨之停擺；當其產生錯誤結果時，下游的清算、交割、風險控制及市場數據顯示皆會受到影響。

中心化交易所（CEX）與去中心化交易所（DEX）之間最根本的差異，正體現在此。DEX 將配對規則編碼於智慧合約中，由礦工或驗證者依照共識順序執行，這使得規則可被審計，卻也帶來高延遲、高成本，且可支援的訂單類型受限。 中心化交易所（CEX）則在交易所自行營運的高效能伺服器上執行配對，這雖能提供低延遲與豐富的訂單類型，但迫使營運商必須透過嚴謹的工程設計與獨立稽核，來彌補集中式信任帶來的風險。

對於白標中心化交易所（CEX）營運商而言，配對引擎也決定了其能服務哪些客戶群。散戶用戶對數十甚至數百毫秒的延遲並不敏感。 做市商、高頻交易部門及套利公司則極為敏感。他們會運行自己的延遲探測工具來測量往返時間、市場資料更新間隔以及取消確認延遲，並根據這些數值決定是否連線以及報價的規模。 若配對引擎未經效能調校，便無法吸引嚴謹的流動性提供者，交易所將陷入深度不足、用戶流失，進而導致深度更為匱乏的惡性循環。

2. 撮合原則：價格-時間優先原則

現代的訂單簿市場普遍採用「價格-時間優先」原則。 此規則包含兩層含義。首先，較高的買價優先於較低的買價，較低的賣價優先於較高的賣價，因為最佳價格對交易對手最為有利。其次，當多個訂單停留在相同價格時，最先到達的訂單將優先成交。

價格優先原則確保了高效的價格發現；時間優先原則則確保了「先到先得」的公平性。兩者結合產生了確定性的配對順序：一旦知曉訂單簿狀態，便能精確推導出某筆訂單是否成交、以何種價格成交，以及與誰成交。 這種確定性對專業使用者至關重要，因為他們的策略是基於對掛單何時被觸發的預期而建立的。若配對結果不透明，他們便無法進行回測，也不會提供持續的流動性。

SoonTech 的配對引擎嚴格執行價格-時間優先原則。當訂單進入配對核心時，會附加兩個時間戳記：一個記錄於閘道接收訂單時，用於風險控制與稽核；另一個記錄於訂單實際進入配對佇列時，用於訂單簿排序。 這兩組時間戳記均具備微秒級解析度，並永久保存於交易日誌中。一旦發生爭議，營運商可重現從接收至執行的完整生命週期，而非僅憑零散的日誌進行推測。

部分交易所會悄悄給予做市商或 VIP 訂單隱藏優先權。此舉雖能在短期內取悅特定客戶，卻會侵蝕市場對公平性的認知，並在市場波動時期引發信任危機。SoonTech 預設不會為任何帳戶實施隱藏優先權。做市商應透過更緊密的報價與更快速的取消訂單來贏得優勢，而非透過規則層面的偏袒。

3. 訂單類型：限價單、市價單與進階訂單

配對引擎的表現力體現在其支援的訂單類型上。兩大基礎類型為限價單與市價單。限價單必須以指定價格或更優價格成交，未成交部分則保留在訂單簿中；市價單則要求以任何可用價格立即成交，並從最佳價格水準向下掃盤。

除了這兩種基本類型外，專業交易還需要一系列進階訂單類型來控制執行成本與風險。SoonTech 支援以下常見類型：

首先，立即成交或取消（IOC）。此訂單一經送達即嘗試配對，任何未成交部分將立即取消，而非保留在訂單簿中。IOC 適合希望快速成交，但又不希望保留訂單而暴露交易意圖的交易者。

其次，立即全數成交或取消（FOK）。此訂單要麼立即全數成交，要麼全數取消；不允許部分成交。FOK 適用於大額交易，因為部分成交會暴露策略意圖。

第三，僅掛單（Post-Only）。若新進單據會立即與掛單配對，則會自動取消。僅掛單模式可確保做市商身分及相關的做市回饋，因此被市場做市商廣泛採用。

第四，止損單。使用者設定觸發價格。當市場觸及該價格時，交易引擎會將止損單轉換為市價單或限價單，並將其注入撮合系統。止損單不會顯示在報價簿上，而是存放在獨立的觸發佇列中。

第五，冰山單。大額訂單僅在訂單簿上顯示少量可見數量，其餘部分則隱藏。當可見部分成交後，另一筆同等規模的訂單將從隱藏部分釋出。冰山單讓大型交易者能在不衝擊訂單簿的情況下建立或減持部位。

第六，TWAP 與 VWAP 演算法訂單。這些訂單由演算法執行模組處理，該模組會根據時間窗口或成交量參與時程表，將母訂單拆分為子訂單，進一步降低市場衝擊。

所有訂單類型均通過相同的配對迴圈運行，但會銜接不同的生命週期事件：下單前、配對中及配對後。將進階訂單類型設計為可插拔式，而非將其硬編碼至配對迴圈中，正是該引擎持續演進的關鍵。

4. 訂單簿結構：層級與索引

報價簿是所有未配對限價單的集合，並按價格層級組織。每個價格層級包含停留在該價格的訂單，並依到達順序排隊。當有市價單或可成交限價單送達時，引擎會從最佳層級開始掃描，直到數量滿足或報價簿耗盡為止。

委託簿的效能取決於三項操作：插入委託、取消委託，以及在成交過程中移除委託。雖然簡單的陣列實作在功能上可行，但在每秒數萬至數十萬次操作下，便會成為效能瓶頸。SoonTech 採用了多項結構性優化。

首先，買價與賣價層級採用無鎖跳躍表或陣列索引價格區間進行組織。 對於具有固定價差的交易標的，陣列索引速度最快；對於可變價差的標的，跳躍表或紅黑樹可在 O(log n) 時間內定位價格層級。在每個層級內，訂單存放在雙向連結列表中，該列表能保留時間順序，並允許在取消時以 O(1) 時間複雜度移除訂單。

其次，每筆訂單皆擁有全域唯一的訂單 ID，且透過哈希表將該 ID 直接映射至記憶體中的訂單物件。 取消訂單可透過 ID 在 O(1) 時間內定位該訂單，且訂單物件持有指向其價格層級與連結清單節點的反向指標，因此移除操作同樣為 O(1)。若無此設計，高頻率取消訂單將退化為對整個訂單簿的全面掃描。

第三，引擎維持一個記憶體內的快照視圖，該視圖會在每次配對後增量更新。市場資料模組會從此快照中產生深度、訂單簿頂價及中價，而非每次都重新掃描訂單簿。該快照與配對狀態嚴格一致，因此交易平台絕不會出現「兩個真理來源」的情況。

5. 具備持久化的記憶體內配對

匹配引擎的極致效能取決於一個簡單事實：記憶體操作的速度比磁碟操作快數個數量級。若訂單簿存放在磁碟資料庫中，每次匹配都會產生毫秒級的 I/O 操作，而這點是任何硬體都無法彌補的。因此，每個嚴謹的匹配引擎都會採用內存匹配，並搭配預寫日誌與定期快照機制。

記憶體內配對意味著訂單簿、訂單物件及成交紀錄全都存放在程序記憶體中。配對迴圈是純粹的 CPU 運算，不涉及任何磁碟或網路，而一筆訂單通常在不到十微秒內即可完成在訂單簿中的處理流程。

然而，記憶體具有易失性。若無持久化機制，系統當機或斷電將導致狀態遺失。因此，交易引擎會在每次狀態變更時，將記錄追加至預寫日誌中。順序追加屬於最快的磁碟 I/O 模式之一，因為無需尋道，且作業系統與磁碟可批次處理大型連續寫入作業。 結合將多項狀態變更整合為單次寫入的群組提交機制後，每筆訂單的持久化成本降至不到一微秒。

僅靠日誌並不足夠。日誌會無限制地增長，且從頭重播日誌以重新啟動系統的速度很慢。引擎會定期將完整的訂單簿快照儲存至磁碟。重新啟動時，系統會載入最新的快照，並重播快照之後的日誌，將狀態還原至最後一項已確認的操作。 SoonTech 每秒或每完成數萬筆成交時觸發一次快照，並將快照與日誌儲存於不同的實體磁碟或可用區域，以避免相關性資料遺失。

資料持久化也涉及工程上的權衡取捨。若在每次配對後強制執行 fsync，將嚴重影響吞吐量；若跳過 fsync，則在斷電時可能遺失最後幾筆記錄。 SoonTech 採用具時間限制的群組提交機制：日誌記錄進入頁面快取後，背景執行緒會每五十毫秒執行一次 fsync，或在達到特定位元組閾值時觸發。 若在此時間窗內發生系統當機，可能會遺失最新尚未刷入的記錄，但這些訂單仍存在於閘道器中，並可在恢復後重播，因此用戶餘額絕不會出現偏差。

6. 市場數據生成與串流

配對引擎產出的不僅是成交結果。它還會發送一套完整的市場數據集：最新成交價、日內最高價與最低價、24 小時成交量、訂單簿頂價、多層級深度及K線圖。這些數據用於驅動交易介面、做市商報價及量化策略，因此必須兼具速度與穩定性。

市場數據的生成採用事件驅動模式。訂單簿中的每次狀態變更或成交，都會觸發一個內部事件，市場數據模組透過接收該事件來增量更新其視圖。採用增量更新而非全量重新計算，使模組在每秒數萬筆交易的情況下仍能保持響應能力。

資料流會傳送給三類使用者。公開市場資料（如最新價格和K線）會傳送給所有訂閱者；私有資料（如訂單狀態、成交紀錄和餘額）則僅傳送給相關帳戶。深度層級的資料流會根據權限而有所不同：免費使用者可能只能看到委託簿頂端，而付費或機構使用者則可看到 20 層或完整深度。

傳輸採用 WebSocket 長連接，並搭配 Protobuf 或 MessagePack 編碼，以降低頻寬與解析成本。 SoonTech 的市場數據閘道器採用了多項協定優化措施：連線多工技術，使多個訂閱共用一個套接字；增量壓縮，避免重新傳輸未變更的欄位；心跳機制，用於偵測斷線；以及背壓機制，確保速度較慢的消費者會被斷開連線，而非拖慢整個叢集的運作速度。

最常見的串流事件並非速度緩慢，而是資料順序錯亂。由於網路抖動，一則成交報告可能在訂單狀態更新之前產生，卻在更新之後才送達，導致客戶端處於不一致的狀態。SoonTech 會為每則訊息標記兩個序號：一個是每條連線內單調遞增的序列號，另一個則是來自對應日誌的全域事件序列號。 客戶端使用全域序列號來偵測訊息缺口，並利用每連線序列號來偵測訊息重新排序；一旦發現任何異常，便會擷取完整的 REST 快照以重新同步。

7. 防止自交易與市場公平性

當來自同一帳戶或相關帳戶的買單與賣單相互配對時，即發生自交易。 自交易可能是意外的策略衝突（例如套利程式中的兩筆交易在相同價格成交），也可能是旨在虛增成交量、操縱收盤價或誤導市場的惡意行為。成熟的交易平台會在配對核心層級透過「自交易預防」（STP）機制來處理此問題。

SoonTech 支援多種 STP 政策。其中最嚴格的是「取消最新訂單（Cancel Newest）」：若新進訂單將與同一 STP 群組內的靜置訂單配對，則新訂單將被取消。 「取消最舊訂單」則會取消該待執行反向訂單，並允許新訂單繼續與其他流動性進行交易。「取消雙方」會同時取消雙方訂單。「減量取消」僅取消重疊的數量，並讓剩餘部分保持待執行狀態或繼續交易。

STP 群組在帳戶層級上具有靈活性。預設情況下，主帳戶及其子帳戶屬於同一個群組，但機構客戶可為不同的策略子帳戶申請獨立群組，以確保無關的策略不會相互取消。每項 STP 操作都會寫入日誌，供風險與合規部門進行審查。

除了 STP 之外，交易引擎還必須處理其他公平性問題。虛假報價（Spoofing）是指下達大額訂單後迅速取消，以製造虛假的市場深度；分層下單（Layering）則是在多個價格層級下單，以誘導價格波動。 動量點火策略會採取激進交易以觸發其他演算法。僅靠配對規則無法防止此類行為；必須透過交易日誌將資料饋送至風險與監控模型，由其標記異常的「取消與下單比率」、短期價格衝擊及相關模式，並通報給合規團隊。

8. 效能基準與延遲測量

僅以峰值 TPS 來討論配對效能是具有誤導性的，因為 TPS 取決於訂單組合、訂單深度及取消比率。一個僅進行配對、未串流市場數據或執行風險檢查的示範系統，其 TPS 可能達到一百萬；但一個在滿載狀態下仍能維持數萬 TPS 的生產級引擎，才堪稱業界領先。 SoonTech 還測量另外四項更具實質意義的指標。

首先是配對延遲，即從訂單輸入到配對核心內生成成交報告所耗費的純 CPU 時間。這是引擎的內在延遲，通常為 5 至 20 微秒。

其次，往返時間，即從使用者發送訂單到收到成交報告所需的時間，包含網路存取、身份驗證、風險檢查、序列化、配對、資料持久化及串流傳輸。若採用同地部署，此時間為 1 至 5 毫秒；遠端使用者則受物理距離限制。

第三，持續吞吐量，即引擎在不產生佇列、超時或延遲惡化的情況下，能持續處理的每秒訂單數量。單一交易對可維持每秒數萬筆訂單，而叢集的水平擴展會隨著交易對數量的增加而提升總吞吐量。

第四，尾部延遲。對做市策略而言，關鍵不在於平均值，而在於 P99 和 P999。運作正常的引擎應將 P99 控制在數十微秒內；若出現突發性飆升，通常指向垃圾回收暫停、中斷風暴、NUMA 跨節點存取或日誌沖洗阻塞，必須立即進行調查。

延遲必須在生產環境中持續監測，而不僅限於系統上線時。 每個 SoonTech 部署都內嵌一個探測帳戶，該帳戶會以固定速率在真實交易對上發送微量的人工訂單，並記錄端到端延遲。探測結果會傳送至儀表板，並在 P99 超過閾值時觸發警報。這種自我健康檢查機制能在外部監控系統察覺之前，就先發現效能退化。

9. 災難復原與多活躍叢集

配對引擎是最後可能發生故障的組件，但每台機器都可能發生故障。災難復原設計需回答一個核心問題：當一台機器、機架、可用區域或整個區域發生故障時，如何在數秒內恢復配對，且不丟失訂單、不產生重複訂單，並避免「腦裂」現象？

基礎架構採用主動-備援模式。主節點正常進行配對，並將其日誌串流傳送至備援節點，後者會持續重播日誌並保持近乎同步。當主節點發生故障時，監控系統會在數秒內偵測到心跳訊號中斷，隨即提升備援節點為主節點，並將閘道流量切換至新主節點。 主動-備援架構的關鍵在於故障轉移時的一致性：舊的主機必須被隔離，以防止其在恢復後重新加入並造成兩個主節點並存；而新主機的狀態落後程度，不得超過最後一個已確認的狀態。

更進階的架構是主動-主動（active-active）或多主動（multi-active）。針對同一對的匹配運算會在多個節點上冗餘執行，這些節點透過 Raft 或 Paxos 等共識協定就順序和結果達成一致，而客戶端可連線至任何節點。 多主架構原則上可實現零停機時間的故障轉移，但會增加幾百微秒至一毫秒的共識延遲，並大幅提升工程複雜度。對延遲要求極高的配對仍傾向採用主備模式；能容忍額外延遲的配對則採用多主架構以獲得更高可用性。

SoonTech 預設採用跨可用區域的強同步主動-備用架構。主節點與至少一個備用節點位於同一資料中心的不同機架中，以實現毫秒級的複製；此外，還設有位於遠端區域的災難復原節點，透過異步複製來應對站點級別的故障。 由獨立的領導者選舉器協調故障轉移，以防止「腦裂」現象。每季的「演練日」會刻意終止主節點運作、斷開閘道連線，並注入網路分割情境，以驗證 RTO 目標在實際運作中能否達成。

10. 機構級存取與 FIX 閘道

專業機構不會透過網頁介面進行交易。它們運行自己的交易系統、訂單管理系統（OMS）／執行管理系統（EMS）以及風險閘道，並需要標準化的連線能力。 金融市場的主流標準是 FIX（Financial Information eXchange）協定，這是一種基於會話的文字或二進位編碼協定，涵蓋訂單輸入、取消、成交報告、持倉查詢及風險控制。

SoonTech 為機構提供專用的 FIX 閘道，相容於 FIX 4.4 欄位規範，並支援會話恢復、序列重新同步、對稱與非對稱加密、來源 IP 白名單，以及客戶端憑證。該 FIX 閘道本身不進行配對；其功能在於將 FIX 訊息轉換為內部訂單事件，並將成交報告轉譯回 FIX 格式。

機構通常還需要透過 FIX 或專有協定實現跨市場主要經紀商連線、將其設備部署於匹配引擎旁以實現最低物理延遲的共置託管服務、與零售客戶不同的專用 API 速率限制，以及粒度更細的專用深度流。SoonTech 將這些功能整合為機構級服務，營運商可針對每位客戶啟用。

一個常被忽略的細節是：沙盒環境與生產環境在結構上必須完全一致。機構在沙盒環境中完成開發後，面臨的最大問題並非 API 不匹配，而是會遇到僅存在於生產環境中的錯誤代碼、速率限制或風險規則。 SoonTech 的沙盒環境運行與生產環境相同的配對程式碼和配置模型，僅在資料層進行隔離，因此從沙盒環境遷移至生產環境的過程能盡可能順暢無阻。

11. 上線與擴展建議

匹配引擎的真正考驗始於上線之後。基於為多家白標客戶進行部署的經驗，我們提出幾項實用建議。

首先，應分階段推出交易對。若在上線時一次性開放數十個交易對，將導致做市商資源分散，並造成各處訂單深度不足。建議先從幾個已有流動性承諾且信心度高的交易對開始，待訂單深度與使用者體驗趨於穩定後再逐步擴展。

其次，在正式上線前先引進做市商。公開上線前，應引入至少兩至三家做市商以提供基礎深度，避免開盤時點差過寬。報價義務、最大點差及最低靜態持倉量應以合約形式載明，並持續對照交易日誌進行驗證。

第三，預留擴展空間。在正常情況下，匹配伺服器的 CPU 使用率應低於 30%，記憶體使用率應低於 50%，以應對市場波動時三至五倍的流量激增。容量規劃應以昨日峰值的 3 至 5 倍為目標，而非平均值。

第四，建立全面的可觀察性。匹配延遲、日誌滯後、市場數據扇出滯後、備援複製滯後、日誌佇列深度、連線數、取消比率以及 STP 觸發條件，都應顯示在具備警示功能的即時儀表板上。監控是營運的雙眼；若缺乏監控，系統運作便如同盲飛。

第五，反覆演練、反覆演練、再反覆演練。每次故障轉移、每次升級以及每次參數變更，都應先在沙盒和預備環境中進行端到端的演練，並制定回滾計畫。唯有在生產環境之外反覆經歷混亂，才能在生產環境中保持沉著。

結論

匹配引擎並非單純購買的模組；它是交易所核心競爭力的長期載體。其效能、穩定性與公平性共同決定了用戶是否願意將資產與策略託付給該平台。SoonTech 的白標中心化交易所（CEX）匹配引擎與訂單簿，在價格-時間優先級、 內存架構、訂單類型表達能力、市場數據串流、自營交易防範、災難復原及機構級存取等領域進行系統性投資，讓營運商能從第一天起便擁有經生產環境驗證的堅實基礎架構，並將精力專注於做市商關係、用戶增長及牌照申請。工程深度的累積，終將轉化為業務深度的提升。

常見問題

Q1：匹配延遲實際上能降到多低？

A：在同一資料中心的裸機或低延遲虛擬機器上，從下單到成交報告的純配對延遲通常為 5 至 20 微秒。 使用者可見的往返時間包含網路傳輸、身份驗證、風險檢查、序列化、資料持久化及扇出處理，若位於同一機房則為 1 至 5 毫秒；跨區域時則會因物理距離而更高。

Q2：做市商能否利用高頻率取消訂單來濫用價格-時間優先權？

A：價格-時間優先原則僅決定訂單配對順序，本身無法防止虛假報價或分層操作。SoonTech 在此基礎上疊加了自營交易防範、異常「取消轉成交」監控，以及短期價格衝擊偵測機制，並將可疑的交易日誌模式標記並通報給合規團隊。市場操縱主要屬於監管違規行為，應透過監控與稽核來處理。

Q3：內存匹配會遺失訂單嗎？

A：每次狀態變更都會寫入具備群組提交（group commit）與時間限定沖洗（time-bounded flush）功能的預寫日誌（write-ahead log）。在最極端的情況下，即使最新尚未沖洗的記錄遺失，這些訂單仍存在於閘道器中，並會在恢復時重新執行，因此餘額絕不會出現偏差。透過定期快照，重新啟動恢復僅需數十秒。

Q4：主動-備用模式的故障轉移需要多長時間？成交紀錄會遺失嗎？

A：在標準的強同步部署中，複製延遲介於亞毫秒至數毫秒之間，而故障偵測與主備切換可在數秒內完成。由於備用伺服器會鏡像主伺服器的狀態，已確認的填補資料不會遺失；切換期間抵達的訂單會在閘道器中排入佇列或重新嘗試處理，且不會產生重複的填補資料。

Q5：是否支援冰山單與演算法單？

A：是的。「冰山單」已實作於配對核心中，僅可見數量會顯示於報價簿上，隱藏部分則會在可見部分成交後釋出。TWAP 和 VWAP 則由獨立的演算法執行模組處理，該模組會將父單拆分為子單，並依照相同的價格-時間優先級規則進行配對。

Q6：機構除 REST 和 WebSocket 之外，還有哪些連接方式？

A：SoonTech 提供具備標準會話管理、序列重新同步、憑證驗證及 IP 白名單功能的 FIX 4.4 閘道。對延遲敏感的做市商可額外申請同地託管及專用市場數據通道，將其設備部署於與匹配引擎相同的数据中心，以將物理延遲降至最低。

🌐 透過 SoonTech 打造安全且可擴展的 Web3 平台。

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