在證券交易系統設計與開發一文中，我們簡單討論了交易系統的核心架構設計，并給出了一個基本的代碼框架。

有小伙伴說代碼給得太簡單，自己實現起來毫無頭緒，能不能詳細地說說架構設計。

本文的目的就是詳細講講交易系統的核心架構設計。

從交易訂單的角度看，一個訂單的處理主要經過定序、撮合和清算三大步驟：

│▼ ┌─────────┐ │Sequence │ └─────────┘│▼ ┌─────────┐ │ Match │ └─────────┘│▼ ┌─────────┐ │Clearing │ └─────────┘│▼

交易系統因為涉及到金錢的計算，要求100%準確可靠，因此，存儲只能選擇支持事務的SQL數據庫。所有NoSQL數據庫，都不在考慮范圍內。

第一代：基于數據庫的設計模型

如果把訂單全部存入數據庫，并且，每次撮合都基于數據庫的訂單進行排序，這種完全基于數據庫操作，并通過數據庫事務保證數據一致性的交易系統，顯然性能有限，并且，對數據庫的硬件配置有非常高的要求。實際上，這種交易系統的處理能力每秒在100左右，提升系統性能完全依靠數據庫服務器的硬件升級，成本高昂。

第二代：基于內存撮合的設計模型

基于數據庫對訂單進行撮合，性能很低的原因在于，交易系統訂單簿的買賣盤實際上是兩個有序表，按照價格優先、時間優先的原則進行排序。如果每次撮合，都依賴數據庫的查詢排序，顯然性能永遠上不去。

如果把訂單從數據庫轉移到內存中，那么，在內存中維護兩個有序表就非常快，因為每次撮合，系統只需要取有序表的前面若干條符合條件的訂單，顯然，撮合速度有數量級的提升。

使用內存撮合的訂單處理速度每秒可高達100萬，因此，撮合引擎不再是系統瓶頸。然而，撮合雖然移到了內存，但清算仍然是基于數據庫事務，因此，整個系統的訂單處理能力大約能提升到每秒1000單，比全部基于數據庫處理的第一代設計提高10倍左右。

有些交易系統非常雞賊地聲稱自己每秒撮合百萬單，但實際上，因為清算系統拖了后腿，整個系統的處理能力仍然不會超過每秒1千的水平。這就好比高速修了100車道，但收費站只有幾個口，最終決定系統整體處理能力上限的仍然是清算系統的處理速度。

第三代：基于內存撮合清算的設計模型

既然基于數據庫清算嚴重制約了系統的訂單處理速度，如果我們把清算系統也放到內存里，讓訂單在內存中完成撮合、清算的全部交易流程，那么，整個系統的處理速度可提高到每秒10萬訂單！

全內存模型和前面兩種設計模型有個很大的區別，就是并不需要多線程并發處理，而是依賴單線程無鎖模型，讓所有計算全部在內存中完成，反而可以輕松獲得10萬+的量級。

使用全內存模型的好處除了極高的處理速度外，另一個好處是硬件成本很低，原因是內存非常便宜，單機32G內存就可以輕松實現每秒10萬的訂單處理速度。注意這里的每秒10萬訂單是指用戶下單到訂單撮合、清算全部完畢的整個流程，而不是單獨指某個模塊的處理速度。

使用全內存模型的缺點是由于內存的易失性，因為不再通過數據庫事務保證數據一致性，如果遭遇宕機、斷電等系統故障，交易系統必須能可靠地恢復整個系統的狀態，這對系統的可靠性提出了非常高的設計要求。

總結

對交易系統來說，傳統的多線程模型對提升系統處理能力作用很小，使用無鎖的單線程全內存設計可以極大地提升系統處理能力，LMAX Disruptor和Redis的單線程模型都證明了全內存無鎖計算的高效率。

讀后有收獲可以支付寶請作者喝咖啡：

還可以分享給朋友：

?分享到微博

總結

以上是生活随笔為你收集整理的高性能交易系统设计原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。