圖片來源：pexels.com

作者：梁鑫（資深架構師，多年云原生，微服務架構經驗，開源 SIA 系列產品 owner）

1

? ?

引子

上次文章《重構 - 在美股行情系統的實踐》分享自己今年在重構美股行情系統的一些心得。接下來要面臨的就是處理股票交易，股票交易一般都是通過證券交易所來完成，業務系統只需要將客戶的買賣動作在正確的觸發機制下，以最快的速度傳遞給證券交易所。

股票交易就是股票的買賣。股票交易主要有兩種形式：

• 一種是通過證券交易所買賣股票，稱為場內交易；

• 另一種是不通過證券交易所買賣股票，稱為場外交易。

我們處理的都是場內交易。

2

? ?

交易系統需要解決的問題

2.1

? ?

如何接收不斷變化的行情數據

在我們重構美股行情系統之后，股票行情系統已經能夠滿足客戶的需求，跟競品相比，從時效性上已經幾乎沒有任何的差距。等接下來采用 MQTT 服務往 APP 端推消息以后，將徹底彌補這個差距。

讀過我上篇文章的朋友知道，我們應對海量實時交易的行情信息，使用的 kafka 消息服務器。如何讓交易信息獲取行情信息呢？最好的辦法是交易系統也從 kafka 訂閱，才能拿到最及時的信息，但這樣直接吧行情系統使用的 kafka 暴露給交易系統。這樣會導致不同的功能模組之間的耦合過度緊密，我們更希望系統之間能層次分明，分類清晰。最好不要給將來的運維工作造成太多的難度和工作量。

因此，最合適的方式肯定是封裝一個 client 包把具體實現影藏起來，這個 client 由行情系統提供，以后凡是交易模式之間需要最實時的行情信息，都可以通過引入這個 client 來實現。而獲取方只需要實現接口的方式即可。

2.2

? ?

交易訂單流程設計

股票交易訂單有很多種類。有限價單，市價單，止損限價單，止損市價單，觸及限價單，觸及市價單等等。又分著買入和賣出兩種交易類型。我們的交易訂單處理的簡單流程圖如下：

當提交股票訂單在股票交易時間內，首先進行成交處理（調用證券交易公司的成交接口），如果成功，流程結束。如果不成功，則進入待成交訂單數據中。待成交訂單的數據會根據不斷變化的行情信息進行判斷，如果滿足成交條件，立即調用成交處理。

2.3

? ?

待成交訂單池

大量的待成交訂單信息保存到哪里? 最好的方式肯定是 redis。redis 性能極高，并且支持豐富的數據類型，并且 redis 所有的操作都原子的。直接規避了我們大量的事務問題。我們把待成交訂單的數據結構分成幾部分。

首先，每只股票都有一個買入訂單的 set 和賣出訂單的 set。這兩個 set 存儲的都是排序好的交易訂單的價格。買入訂單從高到底排列，賣出訂單訂單從低到高排列。

其次，我們用兩個 map 來保存買入賣出的訂單信息，map 的 key 是價格，value 是一個 List，用來保存該價格的所有訂單信息。

2.4

? ?

待成交訂單的觸發機制

針對大量的待成交訂單處理，需要特別考慮幾個問題。

根據海量的行情吞吐信息進行是否可以進行成交處理判斷，考慮系統可以承受的性能壓力和水平擴展模式。

集群模式下待成交訂單的多進程處理。

采用 Redis 保存待成交訂單后的，條件判斷性能問題。

其實這三個問題很好解決，特別是當你的用戶數據還不算多的時候。

• 系統一定要支持集群，可以水平擴展。當系統壓力較大時就可以通過增加節點來解決。

• 利用 redis 的原子操作和數據庫，基本可以解決多進程問題。

• 最后使用 redis 數據中 range 操作。并把每只股票賣出的最低價格和買入的最高價格單獨保存和更新，大量的行情信息其實根本不會觸發待成交訂單的成交操作。

自然大大提高了系統的性能。

2.5

? ?

美股交易系統架構圖

3

? ?

總結

接連完成了美股行情系統的重構交易系統建設，下一步需要著手處理 MQTT 的工作了。（未完待續）

往期推薦

王啟軍：云原生架構下如何拆分微服務？

原創精華：剖析億級請求下的多級緩存

梁鑫：重構 - 在美股行情系統的實踐

淺談架構：架構的緣起與目標

Jartto: 如何成為一名合格的技術面試官？

Francisco: 構建前瞻性應用架構的優秀實踐

滕云：DDD實現之路

天鼎：一個技術人在世界讀書日的遐想

總結

以上是生活随笔為你收集整理的梁鑫：美股交易架构实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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