交易系統(tǒng)架構設計——挑戰(zhàn)與實施

1、挑戰(zhàn)與實踐證券交易系統(tǒng)架構設計參上交所交易系統(tǒng)介紹0交易系統(tǒng)技術架構0挑戰(zhàn)及解決之道0交易系統(tǒng)的未來上交所交易系統(tǒng)介紹發(fā)展歷史1990年笛月26日成立，同年12月19日正式營業(yè)。發(fā)展歷史上交所1990.12.19開業(yè)第-夭即采用電子撮令系統(tǒng)每秒處幾3筆,月處猊2萬筆1993.1 采用衛(wèi)里廣揄 雙向衛(wèi)里按收訂單1992.12系統(tǒng)升級，采用UNIX小型機專秒200筆，n處理200萬筆1997,1999系統(tǒng)兩次升圾，枚能提升至琴秒2萬筆，n處幾800萬開業(yè)的第一天就采用電子撮合系統(tǒng)進行交易撮合基-J-Novell服務器的局域網(wǎng)絡每秒處理3筆業(yè)務，月處理成交2萬筆市場的委托、行情、成交回報等環(huán)節(jié)仍需要

2、手工完成1992年12月，系統(tǒng)升級Novell主機更換為基于惠普小型機UNIX操作系統(tǒng)每秒200筆，日處理能力200萬筆1993年，采用單向衛(wèi)星廣播行情，雙向衛(wèi)星接收報單1997年和1999年進行了兩次設備和應用的重大升級系統(tǒng)處理能力提高到每秒2萬筆，日處理能力800萬筆后隨著不斷的擴容和改造，性能和容量不斷被刷新上交所2009.11.23新一代交易系統(tǒng)上線使用多主機并最離支持10萬筆為秒全天容億筆訂單賬戶容殳1億新一代交易系統(tǒng)的上線2009年11月23日，新一代交易系統(tǒng)上線使用多主機并行撮合最高支持10萬筆每秒全天容量1億筆訂單帳戶容量1億2014.11.17滬港道如務上基于新一代交易系統(tǒng)，

3、2014年們月17日滬港通業(yè)務上線市場結(jié)構圖市場參與者券商基金公司上市公司行情商指數(shù)公司QDII投資者香港投資者ftff麗菽資和|QFII|RQ冋fRQ冋I|QFLP海外市場系統(tǒng)結(jié)構圖核心交易系統(tǒng)內(nèi)部結(jié)構交易系統(tǒng)技術架構交易層心交易層1統(tǒng)的三層式劃分交易系統(tǒng)技術架構>疋序?qū)?定序器1I定序器2撮合器2分配股票（制作業(yè)、零隹）分配債券接入點A接入點B接入點C券商基金公司資管公司滬港通功能執(zhí)行交易業(yè)務邏輯實現(xiàn)模式同組交易主機為接收單一輸入序列的狀態(tài)機從一系列獨立運作的交易主機節(jié)點中自動選舉產(chǎn)生主節(jié)點可利用集群鎖服務來選舉主節(jié)點備機可選擇“重演”或者“重放”模式交易層集群鎖管理模式基于Open

4、VMS的Lock機制，實現(xiàn)了一套用于集群(Group)管理，集群內(nèi)各主機同步、通信的工具庫接入層功能點對點的路由轉(zhuǎn)發(fā)將券商端的訂單提交給定序?qū)訉嵗峁┮唤M彼此對等的實例同時提供對外實現(xiàn)模式服務不需要考慮主從劃分和失效接管定序?qū)庸δ芨呖捎迷O計的關鍵、確定全序持久化及保持動態(tài)一致性多播通信機制實現(xiàn)模式Paxos算法.虛同步自主研發(fā)、商業(yè)軟件、開源軟件邏輯概念，可采用單獨排隊機定序或者主撮合定序挑戰(zhàn)及解決之道交易系統(tǒng)面臨的挑戰(zhàn)交易系統(tǒng)在設計之初就要考慮到如何滿足和平衡各方面的技術需求交易系統(tǒng)高性能衡量交易系統(tǒng)性能主要指標A吞吐量訂單時延A系統(tǒng)容量高性能1.流水線化內(nèi)存撮合高性能3.數(shù)據(jù)打包處理精簡的

5、進程間通信消息消息body通過內(nèi)存緩存；進程間傳遞短小的消息header；進程通過header信息，訪問內(nèi)存獲取消息實體;消息的打包處理請求消息通過用header表示后很短小，支持多條打包模式；申請新的共享內(nèi)存消息，消息體中包含多個請求實體的header；實際消息通信中傳遞打包消息的消息header即可；進程接收消息后，根據(jù)打包消息body中的多個實際消息header,逐一高性能4多線程異步IO應用異步IO提升性能的典型案例調(diào)用進程通過異步IO連續(xù)的拋出一組IO請求，RMS可以并行地處理這些請求，成倍地提升IO吞吐量；連續(xù)發(fā)出的請求應當有一定限制，當未完成的請求數(shù)量達到限制時，調(diào)用進程可以主動

6、將自己阻塞。-1'高性能5.多機并行高可用衡量交易系統(tǒng)可用性主要指標A恢復時間目標RTO(RecoveryTimeObjectives)A恢復點目標RPO(RecoveryPointObjectives)人工偵測故障OR應對單點故障OR同城災備同步復制OR高可用技術抉擇的難題應用程序自動偵測故障？應對雙點故障？異步復制？高可用1.站點備份站點A主機網(wǎng)站點B主機主機H1H2站點間連接主機主機H3H4交換機交換機磁盤磁盤D1D2磁盤磁盤D3D4高可用2.主機備份高可用4.消息重發(fā)/防重處理進程的恢復機制事務/請求數(shù)據(jù)帶事務的文件存儲，包含相應的狀態(tài)位；任何一個進程異常，根據(jù)事務文件中數(shù)據(jù)狀

7、態(tài)重演恢復;無法應對程序本身邏輯錯誤系統(tǒng)發(fā)生主備切換切換完成后的自動通知機制未響應消息重新路曲機制消息防重復處理機制前臺OES抿單機中臺CSUD、CSHD前癥蘇接后臺連接k61XVHCCMHHCM4HHCMHHCMMSRTGSRTGSRTGSRTMatcherMatcher主機備機AppApp易擴展流量/負載控制：/系統(tǒng)必須提供自保護機制來處理異常的大量或者突發(fā)交易量/包括主動控制和被動控制主動控制：/主動控制實現(xiàn)于前端（請求源端）會員，根據(jù)尚未響應的訂單數(shù)量控制請求發(fā)送速度/系統(tǒng)可配置成會員端總體的請求數(shù)量不超過后臺的處理能力，因此從源端控制整個系統(tǒng)的負載被動控制：/路由架構內(nèi)置的自我保護機

8、制/每個路由架構組件跟蹤其輸入/輸出差異，并且根據(jù)監(jiān)測的差異觸發(fā)自我保護機制來或者阻塞消息流，或者彈回新的請求主要指標A擴展性衡量系統(tǒng)適應業(yè)務發(fā)展與變更的能力，既包括業(yè)務容量的擴展又包括業(yè)務模式的擴展應對方案A高擴展性需要在內(nèi)部核心數(shù)據(jù)結(jié)構和接口定汶預留足夠的擴展空間。A系統(tǒng)內(nèi)部結(jié)構上，通過分層抽象服務使得某一個層次的升級更新不彩響到全局架構，通過模塊化設計使得某一個模塊的變更不影響到整體穩(wěn)定。WAN后臺的擴展交易層中的各個平臺，町以平行擴展設備，支持業(yè)務的容萸和品種的發(fā)展接入層中，節(jié)以根據(jù)網(wǎng)段規(guī)模和接入點無縫第進行平行擴展；每個接入點屬于無狀態(tài)設備LAN1.系統(tǒng)架構的擴展HostTierBa

9、ckEndcscscscsTier*前臺的擴展對于市場參與者的接入,既提供客戶端的模式，也支持消息協(xié)議和API的模式擴展交易所提供的接入端巧以無差并的多地不少和彼此備份、分流業(yè)務數(shù)擴等orLANLANStepOESOESBinaryvaluesProtocolTierFrontEndOESOESTier易擴展基于產(chǎn)胎的不同類別配置，可根據(jù)負載均衡的原則，重新進行劃分或擴展銀行股銀行股A銀行股B2應用配置的擴展訂單量200w單一類別的處理容量可以通過配置參數(shù)進行調(diào)整。調(diào)整后的容量在系統(tǒng)重啟后自動生效醫(yī)藥板塊訂單量200w零售板塊醫(yī)藥板塊訂單量500w零售板塊訂單量150w易擴展3設計模式的分層設

10、計業(yè)務應用系統(tǒng)PattenLayer批處理架構BATArch消息通訊架構MSGArch應用進程架構SHLArch監(jiān)控架構MONArch操作架構OPTArch高可用架構HArch錯誤傳迷FunctionLayer共享內(nèi)存庫SHMLib日志庫LOGLib同步IO庫SIOLib井步IO庫AIOLib配置信息庫CFGLib數(shù)據(jù)算法庫DSMLib應用鎖庫LCKLib數(shù)據(jù)類型WrapperLayerOSWrapper3ndPartyLibWrapperC99標準POSIX標準OSFeatureGLIBLog4c框架配近OS操作系統(tǒng)（Linux,UNIX,FreeBSD等支持POSIX接口的操作系統(tǒng)）交易系統(tǒng)的未來交易系統(tǒng)的未來輕量化的技術