從頂層流圖來看，交易系統有市場則的指令和數據，以及有用戶則的指令和數據，任意一則或兩則發起的內容都是流入到實時交易系統中進行路由及處理。但是在低延時實時交易系統內部是一個很復雜的生態系統，本文只抽取描述部分關鍵的技術架構進行描繪。
定義交易系統核心功能為：
1， 買方和賣方的交易操作（買入，賣出，掛牌，出價，追單，撤單，拆單，合單）。
2， 實時行情廣播，實時交易，機構批量交易，高頻率交易。
3， 市場資訊。
4， 歷史交易，賬單。
5， 賬號管理，資金管理。
6， 金融機構接口。
7， 實時交易風險管理。
服務器節點性能要求：
交易系統需要使用內存計算架構，交易系統開市過程中響應時間設計的標准為平緩的響應曲線，即不以交易量的線性增長形成與延長響應時間之間的線性關系，都應以20ms左右的響應時間作為同時間段的目標性能，為如下圖所示：
低延時交易操作：5ms—20ms/單。
2000+TPS。
20000+在線網絡連接。
高可靠事務控制，單一訂單不重復處理，不能丟失交易單及交易請求。
內存計算：
對於低延遲系統，如果交易響應遲緩，幾乎是立即出局，所以，交易數據的處理必須全部在內存中完成計算和處理，下表列舉出各種內存的響應時間，要滿足性能要求，必須在計算機主內存完成計算任務。
| 內存 |
延遲 |
| L1 Cache |
1ns |
| L2 Cache |
3ns |
| L3 Cache |
12ns |
| Remote NUMA Node |
40ns |
| Main Memory (DDR DIMM) |
100ns |
| Intel Optane DC Persistent Memory |
350us |
| Intel Optane DC SSD I/O |
<10us |
| NVMe SSD I/O |
25us |
| Random SSD Read 4K |
50-150us |
| Data Center Read |
500us |
| Mechanical Disk Seek |
10ms |
| Data Center Read |
500us |
以登錄后的用戶為單位，形成的每事務單中，交易單需要的數據，狀態全部會在系統運行后在子系統裝載，保證交易過程中訂單數據和狀態的流動不中斷不停留。如果內存資源緊張，用戶退出系統后或超過會話周期，可以把無活動的用戶清理出內存區。
內存計算采用商用方案領域或開源免費方案，根據項目的預算選擇，常見SAP HANA, Apache Ignite都是很好的選擇如果是企業級商用場景，需要同時考慮以下開源類產品沒有的5個功能：數據快照，數據恢復，監控，審計，數據中心復制。
下表中列出方案選項的考慮因素：
|
|
內存數據庫(網格類) |
內存數據庫 |
| 產品 |
Apache Ignite， Apache Geode, Hazelcast, SAP HANA, Oracle Coherence |
MemSQL VoltDB |
| 主要功能
|
高吞吐量，低延時 |
高吞吐量，低延時 |
| 事務控制 |
|
|
| 分布式運算, 支持1000節點，TB級存儲 |
|
|
| 數據查詢分析功能 |
支持SQL，通過API操作 |
|
| 數據持久化，數據庫同步 |
數據持久化，但只是內存的快照 |
交易指令路由：
為保證低延時實時高並發的業務特性，應將交易區分出不同類別的指令，如有買，賣，追，撤，合，拆等動作。同時交易的商品也應該區分出各類科目/種類的商品，一一對應到分門別類的商品隊列緩存中，交易單中會根據商品和指令動作會分別落入對應的隊列緩存中。
訂單匹配：
匹配原則采用價格優先和時間優先原則，買方按設定的價格和數量掛牌，賣方也按設定的價格和數量掛牌，系統統計不同價格段內買賣雙方的匯總數量，買賣訂單匹配成功的話，便滿足交易條件，系統則進行買賣雙方的交易操作。如果買賣雙方沒有匹配成功，買入訂單會掛在商品隊列中，賣出訂單同樣會掛在商品隊列中，繼續累積和等待。
|
|
成交價格 |
|
訂單數量 |
| 賣⑤ |
5.57 |
|
848 |
| 賣④ |
5.56 |
|
1043 |
| 賣③ |
5.55 |
|
1126 |
| 賣② |
5.54 |
|
987 |
| 賣① |
5.53 |
|
207 |
| 成交 |
5.53 |
現手交換， 成功買入63, 成功賣出207 |
270 |
| 買① |
5.52 |
|
955 |
| 買② |
5.51 |
|
660 |
| 買③ |
5.5 |
|
1860 |
| 買④ |
5.49 |
|
1819 |
| 買⑤ |
5.48 |
|
1329 |
匹配引擎：
按一定周期從買賣訂單消息隊列中提取出買方和賣方的訂單，按訂單價格匯總出掛單數量，放入Redis作為緩存，同時作為用戶端排行數據的源。如果是撤銷指令，則在相應的價格牌中去除。成功匹配的買賣雙方，生成最終的交易單，放入交易單消息隊列，將由最后的核心業務系統對買賣又雙方的賬戶進行交易操作。
API網關：
交易系統通過API提供交互，在系統內部，所有數據訪問都先經過API網關。API網關應有以下功能：
定義APIs：SOAP APIs，REST APIs， WebSocket APIs。
執行設定好的服務級別或全局的策略：
安全策略：
- IP地址黑白名單。
- 設備規則，應用程序規則。
- 消息過濾，SQL注入，JSON線程保護。
- OATH 2.0 , API密鑰機制。
消息傳輸策略：
- SOAP到REST的轉換。
- 預處理及后處理。
流量策略：
- 路由。
- 負載均衡。
- 服務治理（限流，熔斷，容錯）。
- 日志監控。
- SLAs監控。
- 緩存服務監控。
行情廣播：
客戶端到服務端或者是反向的雙向數據傳輸，第一種情況為：從客戶端登錄用戶或匿名用戶在軟件終端發起，到服務端拉取行情數據，行情廣播自身緩存即時行情數據，對於每一個軟件端廣播即時的價格信息及市場信息。第二種情況為：服務端主動發送行情數據到軟件終端，服務端記錄登錄的客戶軟件端，逐一點對點發送市場信息。設置一個ClientPool列表，對列表中的IP進行傳輸。
行情數據源的對接，使用提供方的數據API獲取行情資訊，數據到本地系統后，按證券或貨幣的種類進行划分，放置到緩存系統中提供給下游數據客戶，同時數據快照以K線周期寫入時序DB中。
風險管理系統：
風險規則，安全規范的規則庫，發起交易的訂單流經過程會核對交易訂單的內容是否合規，能對系統形成第一道保護屏障。
關於風險控制和分析系統所使用的數據，有很大部分為歷史數據，和事務型系統使用的數據，列出下表作對比：
| 事務型系統 |
分析型系統 |
| 大部分情況為OLTP |
大部分情況為OLAP |
| 相對較少的操作數據集 |
完整的歷史數據集 |
| 事務高吞吐 TPS/OPS |
只讀 |
| 響應低延遲 |
吞吐量相對次要 |
| 一致性，要求有事務控制 |
高頻執行查詢，要求查詢低延遲 |
|
|
交互分析查詢，動態查詢 |
個人用戶交易操作界面：
支持查看行情，分析及市場資訊，發起交易，賬單，資金管理，賬號管理，提供手機APP，WEB，Desktop應用。
機構交易操作界面：
參考成交量規模額外具備高頻交易，批量交易。
整體構架圖
數據方向：
1． 個人用戶發起系統訪問，使用APP，Desktop應用可以瀏覽證券行情，發起證券交易，管理資金資產。發起買入或賣出時，數據流向負載均衡器，通過API網關。
2． API網關把交易請求發送到訂單序列服務中累積並形成買賣交易單。
3． 風險管理系統分析和評估當前交易請求是否合規，滿足后交易請求會通過匹配路由進入各自商品的交易隊列。
4． 匹配引擎獲取各個商品隊列的訂單，訂單在各個價格區間，交易數量累積的數據會被匹配引擎進行交易匹配，在當前價格滿足的買賣雙方的訂單則轉入下一環節，通過交易路由把訂單轉入對應的交易訂單隊列當中。
5． 核心業務處理買賣雙方的交易單，對授權賬戶進行商品持有量及金額更新，對商品交易的庫存進行更新。生成交易形成的對賬單，保存在RDBMS中。
6． 交易單風控對最終進入交易的訂單進行風險控制，如果滿足則通過。
7． 更新后商品庫存及即時價格信息寫入時序DB中，終端應用APP可以實時使用時序數據觀察到市場交易情況，同時為商品交易趨勢K線圖提供展現數據。
8． CDN為異地終端客戶提供及時的數據內容分流服務。
9. 機構具有批量交易、高頻交易、實時數據分析等高階功能，從硬件資源方面實際會按功能模塊獨立部署。