證券內(nèi)存交易系統(tǒng)的架構(gòu)設(shè)計與評價

楊重陽

摘要：隨著大數(shù)據(jù)時代的來臨，證券行業(yè)這種數(shù)據(jù)密集型產(chǎn)業(yè)對數(shù)據(jù)處理的性能有著愈發(fā)急切的需求。傳統(tǒng)的磁盤-數(shù)據(jù)庫模式的處理速度愈發(fā)不能滿足需要。文中采取內(nèi)存計算方式給出了該問題的一個解決方向。首先結(jié)合目前研究現(xiàn)狀簡要說明內(nèi)存計算的概念，并總結(jié)出內(nèi)存計算的特點(diǎn)。然后從單節(jié)點(diǎn)和多節(jié)點(diǎn)兩個方向結(jié)合證券行業(yè)不同的業(yè)務(wù)場景給出對應(yīng)的系統(tǒng)架構(gòu)，并指出相關(guān)條件下需要關(guān)注的問題和解決方向。

關(guān)鍵詞： 內(nèi)存計算；證券；單節(jié)點(diǎn)；多節(jié)點(diǎn)；架構(gòu)設(shè)計

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2018）04-0056-03

The Architecture Design and Evaluation of the Securities in Memory Trading System

YANG Chong-yang

（Department of Computer Science and Technology， Tongji University，Shanghai 200092，China）

Abstract：With the advent of the era of big data， there is urgent need for massive data processing performance in the data intensive industries， Such as securities. The speed of processing in traditional disk - database schema is increasingly unable to meet the requirement.In this paper， one solution of this problem has been given by using in-memory technology. At first， with the present situation of the in-memory technology study， briefly explain its concept and summarize the characteristics. then， combining the business scene of the securities industry，the corresponding system architecture is presented from different business scenarios ，single node and multi-node. Finally， point out the relevant issues and the solutions.

Key words： in-memory technology；securities；single node； multi-node；architecture

1 總述

隨著大數(shù)據(jù)時代的來臨，證券行業(yè)的發(fā)展日新月異，交易數(shù)據(jù)量越來越大，日交易額已經(jīng)步入千億級別，2016年雖然A股市場較為低迷，以震蕩為主，但是已有統(tǒng)計數(shù)據(jù)表明，截止2016年末，僅滬深兩市場的日交易額均已達(dá)億元級別。近幾年隨著交易所融資融券，股票質(zhì)押，券商投行，再融資，并購重組等新業(yè)務(wù)推進(jìn)步伐的加快，基金公司、券商、私募等機(jī)構(gòu)投資者也對量化交易、策略交易、做市、程序化交易等有著愈發(fā)迫切的需求。滬港深市場交易種類繁多，交易數(shù)據(jù)的快速增長，大規(guī)模數(shù)據(jù)和業(yè)務(wù)場景的高時效性要求與傳統(tǒng)的內(nèi)存-磁盤訪問模式產(chǎn)生了巨大矛盾，隨著數(shù)據(jù)量的激增，在傳統(tǒng)計算模型中的諸多問題逐漸顯現(xiàn)出來， 如內(nèi)存容量的大小，原始數(shù)據(jù)緩存的尋址命中率，磁盤的I/O瓶頸（輸入/輸出），數(shù)據(jù)處理效率等問題，基于底層數(shù)據(jù)查詢方式的局限，目前這些問題在現(xiàn)有的架構(gòu)上都只能在軟件或者硬件上初步緩解，如更新系統(tǒng)架構(gòu)，更換更好的CPU，服務(wù)器等硬件設(shè)施，但是并不能從根本上解決這些問題。

內(nèi)存計算的出現(xiàn)給這種數(shù)據(jù)密集型訪問的處理方式提供了一個較好的解決方案。以內(nèi)存計算為基礎(chǔ)的內(nèi)存數(shù)據(jù)庫可以從很大程度上緩解目前的性能瓶頸。其支持?jǐn)?shù)據(jù)直接訪問的高處理效率很好的貼合了當(dāng)前證券行業(yè)的業(yè)務(wù)現(xiàn)狀。內(nèi)存數(shù)據(jù)庫系統(tǒng)帶來的優(yōu)越性能不僅僅在于對內(nèi)存讀寫比對磁盤讀寫快上，更重要的是，從根本上拋棄了許多傳統(tǒng)的磁盤數(shù)據(jù)管理方式，并基于全部內(nèi)存數(shù)據(jù)的管理進(jìn)行了新的體系結(jié)構(gòu)的設(shè)計，并且在數(shù)據(jù)緩存、快速算法、并行操作等方面有相應(yīng)的改進(jìn)，故相比于傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)處理速度來說有極大的提高。

本文第2節(jié)介紹內(nèi)存計算的相關(guān)特點(diǎn)及當(dāng)前的發(fā)展?fàn)顩r，并根據(jù)系統(tǒng)硬件架構(gòu)的不同概述對應(yīng)的設(shè)計要點(diǎn)。第3節(jié)針對于單節(jié)點(diǎn)系統(tǒng)框架，重點(diǎn)從性能，并發(fā)的角度設(shè)計系統(tǒng)架構(gòu)；第3節(jié)針對于多節(jié)點(diǎn)系統(tǒng)框架，重點(diǎn)從網(wǎng)絡(luò)，多節(jié)點(diǎn)間通信的角度分析系統(tǒng)；第5節(jié)總結(jié)內(nèi)存計算架構(gòu)并給出進(jìn)一步研究方向。

2 內(nèi)存計算概述

內(nèi)存計算的概念早在20世紀(jì)90年代的時候就已經(jīng)有人提出并付諸實(shí)驗(yàn)，只是局限于當(dāng)時的技術(shù)水平等條件， 研究的步伐沒有現(xiàn)在這么快。目前較權(quán)威的機(jī)構(gòu)，如IBM對其說明為：針對數(shù)據(jù)訪問密集型應(yīng)用，為了提高數(shù)據(jù)處理效率，將數(shù)據(jù)全部或部分放置于內(nèi)存，利用內(nèi)存的高讀取速度來提高處理速度，結(jié)合具體業(yè)務(wù)場景來看，內(nèi)存計算還需要另外專門設(shè)計搭配的軟件體系架構(gòu)、軟件接口等[1]。據(jù)此，內(nèi)存計算應(yīng)包含如下幾個特性：

1） 大容量內(nèi)存（單節(jié)點(diǎn)或者多節(jié)點(diǎn)），可將待處理的數(shù)據(jù)全部或者主要的部分存放于內(nèi)存中；

2） 良好的業(yè)務(wù)處理模型和接口；

3） 數(shù)據(jù)規(guī)模大，較高的時效性要求；

4） 支持業(yè)務(wù)的并行處理。

綜上，內(nèi)存計算是在大數(shù)據(jù)環(huán)境下，憑借計算機(jī)軟硬件的快速發(fā)展，并通過體系架構(gòu)和編程模型的重大革新，將數(shù)據(jù)的處理主要放在內(nèi)存中完成，取代原來數(shù)據(jù)傳統(tǒng)操作的新型的并發(fā)計算架構(gòu)。

目前國內(nèi)證券行業(yè)的蓬勃發(fā)展，大券商實(shí)力較為雄厚，經(jīng)過多年的積淀，對性能，規(guī)模，災(zāi)備，監(jiān)控等都有著較高的要求，分布式多節(jié)點(diǎn)部署可以較好的切合需要。 相比較而言，小型券商也有類似的需求，只是受限于自身的發(fā)展情況，單節(jié)點(diǎn)已經(jīng)能滿足大部分需要。

1） 單節(jié)點(diǎn)

單節(jié)點(diǎn)內(nèi)存計算系統(tǒng)是指運(yùn)行于單個物理節(jié)點(diǎn)上，擁有一個或多個處理器和共享內(nèi)存（集中式共享內(nèi)存，或非一致性共享內(nèi)存（non-uniform memory access，NUMA））單節(jié)點(diǎn)上的內(nèi)存計算主要是壓榨CPU的性能，同時優(yōu)化軟件處理流程，磁盤讀取方式和業(yè)務(wù)處理邏輯，同步采用新型計算架構(gòu)，采用大內(nèi)存和多線程并行，以達(dá)到充分發(fā)揮內(nèi)存和 CPU 的 cache的緩存處理能力，提高處理性能的目的。

2） 多節(jié)點(diǎn)

單節(jié)點(diǎn)內(nèi)存計算因局限于硬件資源，在處理更大規(guī)模數(shù)據(jù)的時候，由于先天架構(gòu)的局限，在硬件的橫向擴(kuò)展方面的問題并不一定完全兼容。故分布式系統(tǒng)的內(nèi)存計算開發(fā)和應(yīng)用也逐漸豐富起來。比如以MapReduce 為代表的大規(guī)模分布式內(nèi)存處理技術(shù)。這種內(nèi)存計算處理方式充分考慮了硬件的擴(kuò)展性，天然支持多個節(jié)點(diǎn)（計算機(jī)/服務(wù)器）構(gòu)成的集群來構(gòu)建分布式內(nèi)存，并通過統(tǒng)一的資源調(diào)度，使待處理數(shù)據(jù)有序的存儲于對應(yīng)分布式內(nèi)存中，并根據(jù)一定的規(guī)則實(shí)現(xiàn)大規(guī)模數(shù)據(jù)的快速訪問和并行處理。

3 單節(jié)點(diǎn)系統(tǒng)設(shè)計要點(diǎn)

在該業(yè)務(wù)場景下，因其不涉及與外部的交互，所有的業(yè)務(wù)均是由券商自己單節(jié)點(diǎn)內(nèi)部完成，故技術(shù)上著重考慮的是單機(jī)性能方面的問題。如系統(tǒng)內(nèi)高并發(fā)的解決，復(fù)雜業(yè)務(wù)的接口設(shè)計，業(yè)務(wù)流程的優(yōu)化等。

簡要的系統(tǒng)框架圖如下：

在簡單的網(wǎng)絡(luò)環(huán)境下，（暫不考慮行情等其他輔助插件），性能的提升需緊密結(jié)合業(yè)務(wù)流程，精簡不需要的冗余步驟，圍繞多線程并發(fā)開展業(yè)務(wù)流程設(shè)計。打好系統(tǒng)的底層基礎(chǔ)架構(gòu)，充分考慮后續(xù)的延展性和健壯性。

在具體的數(shù)據(jù)處理上，現(xiàn)也有給出較好解決方案的處理框架，如Grace[2]，Ligra[3]，GRACE[4]和 GraphLab[5]。大體思路都是一樣，都利用多核 CPU 和大內(nèi)存，結(jié)合多線程并行技術(shù)，達(dá)到充分利用內(nèi)存和 CPU的目的，只是三者的處理機(jī)制和側(cè)重點(diǎn)有所區(qū)別。Grace 提出的是一種聚集圖更新策略，針對于圖劃分間（線程間）進(jìn)行了通信和負(fù)載均衡優(yōu)化，以此提高圖處理效率；Ligra的計算方式則是以圖為中心，提出了一種輕量級的圖處理架構(gòu)，重點(diǎn)在于更容易實(shí)現(xiàn)對應(yīng)的圖遍歷算法；GRACE 重點(diǎn)針對的是同步/異步模式，提出了一種可以根據(jù)具體需求場景，由用戶自行決定或者切換同步/異步執(zhí)行的并行圖處理結(jié)構(gòu)。最后， GraphLab 是一種基于圖模型處理的機(jī)器學(xué)習(xí)算法，其并行框架是異步的。

在數(shù)據(jù)存貯上，內(nèi)存數(shù)據(jù)庫起步很早，如MMDB[6-7]（main-memory database），在數(shù)據(jù)訪問，主存和磁盤的尋址映射，內(nèi)存索引結(jié)構(gòu)的優(yōu)化，查詢的優(yōu)化，日志記錄和優(yōu)化上都有相應(yīng)的提高，現(xiàn)也得到了較好的效果，近幾年已有商業(yè)化的解決方案出現(xiàn)。類似的解決方案還有，hyper和hekaton， Hyper[8]是一種混合 OLTP和 OLAP的高性能內(nèi)存數(shù)據(jù)庫；Hekaton[9]是一個基于行，針對事務(wù)處理（TP）的的內(nèi)存數(shù)據(jù)管理系統(tǒng)，其優(yōu)化過的應(yīng)用可提升 50 倍的速度，并且完全集成了 SQLServer。

雖然在底層上對數(shù)據(jù)的訪問有了極大的改進(jìn)， 但是在業(yè)務(wù)設(shè)計上也不能忽視數(shù)據(jù)的訪問成本，流程的設(shè)計也需要兼顧數(shù)據(jù)的增刪改查邏輯，避免無謂的資源消耗。

4 多節(jié)點(diǎn)系統(tǒng)設(shè)計要點(diǎn)

在多節(jié)點(diǎn)的環(huán)境下，相對于內(nèi)存讀取的速度，網(wǎng)絡(luò)間通信的讀寫至少要慢上兩個數(shù)量級。如何解決網(wǎng)絡(luò)內(nèi)節(jié)點(diǎn)間通信，數(shù)據(jù)傳輸，節(jié)點(diǎn)間同步，安全問題和節(jié)點(diǎn)宕機(jī)的災(zāi)備恢復(fù)等則是需要考慮的重點(diǎn)。

簡要的系統(tǒng)框架圖如下：

在該多節(jié)點(diǎn)的網(wǎng)絡(luò)環(huán)境下，（暫不考慮行情等其他輔助插件），底層需要加入仲裁機(jī)這個角色，承擔(dān)負(fù)載均衡，排隊等職責(zé)，用來均衡多系統(tǒng)核心的負(fù)載，并對數(shù)據(jù)包進(jìn)行去重，排序來保持業(yè)務(wù)處理的可靠性。網(wǎng)絡(luò)節(jié)點(diǎn)的布置中還需要用相應(yīng)的網(wǎng)絡(luò)協(xié)議和對應(yīng)的鏈路訪問機(jī)制來維護(hù)節(jié)點(diǎn)間的路由狀態(tài)和鏈路暢通，最常用的如OSPF（Open Shortest Path First開放式最短路徑優(yōu)先），RIP（Routing Information Protocol路由信息協(xié)議），BGP/BGP4（Border Gateway Protocol，邊界網(wǎng)關(guān)協(xié)議）等。

節(jié)點(diǎn)間通信除了上述開銷之外，還需要加入容錯，災(zāi)備，節(jié)點(diǎn)間同步等處理機(jī)制，用來保證業(yè)務(wù)狀態(tài)的正確性和唯一性。 由于內(nèi)存數(shù)據(jù)的易失性的影響，相應(yīng)數(shù)據(jù)的災(zāi)備，恢復(fù)等異常處理機(jī)制是至關(guān)重要的。重載是最容易想到也是實(shí)現(xiàn)起來最方便的，如MapReduce， 其容錯機(jī)制主要通過定期檢查鏈路中的各個父子節(jié)點(diǎn)，對于故障的子節(jié)點(diǎn)， 及時從其他子節(jié)點(diǎn)中獲取對應(yīng)的任務(wù)列表并重復(fù)執(zhí)行，恢復(fù)到故障前的狀態(tài)，而對于出現(xiàn)故障的父節(jié)點(diǎn)，則通過從集群中的其他父節(jié)點(diǎn)上復(fù)制數(shù)據(jù)備份并傳輸?shù)奖镜睾笾匦录虞d的方法來解決。需要在原有的業(yè)務(wù)處理邏輯上加入對應(yīng)網(wǎng)絡(luò)機(jī)結(jié)構(gòu)的改造，需要整合多核心情況下的業(yè)務(wù)流程，確保多個核心可以充分發(fā)揮各自的能力，提高處理性能和CPU的利用率，解決負(fù)荷偏載，死鎖等問題。

5 結(jié)束語

本文首先初步分析了內(nèi)存計算特點(diǎn)和發(fā)展情況，結(jié)合目前證券行業(yè)的現(xiàn)狀，進(jìn)一步闡述了證券行業(yè)面臨的挑戰(zhàn)和問題；并從內(nèi)存計算的兩種不同架構(gòu)，機(jī)制以及模型等方面對內(nèi)存計算技術(shù)的應(yīng)用進(jìn)行了簡要的說明，并對現(xiàn)有的一些較好的科研成果進(jìn)行了總結(jié)。當(dāng)然，內(nèi)存計算的研究問題還有很多需要進(jìn)一步深入研究才能解決。比如，目前的多節(jié)點(diǎn)內(nèi)存計算系統(tǒng)中的重演機(jī)制帶來的存儲開銷問題，分布式共享內(nèi)存[10]、內(nèi)存數(shù)據(jù)庫等，節(jié)點(diǎn)的容錯方式均是通過接口來移動和復(fù)制其他節(jié)點(diǎn)的數(shù)據(jù)，或以記錄日志重演的方式更新集群間各個節(jié)點(diǎn)。而這兩種方法對于數(shù)據(jù)密集型的應(yīng)用來說，開銷和負(fù)荷太大，集群節(jié)點(diǎn)之間大量數(shù)據(jù)的復(fù)制帶來的硬件存儲的開銷以及遠(yuǎn)小于內(nèi)存帶寬的網(wǎng)絡(luò)傳輸帶寬帶來的漫長耗時，這都是后續(xù)需要分析和研究的問題。

參考文獻(xiàn)：

[1] In memory database： HANA， exadata X3 and flash memory.2012[EB/OL].http：//flashdba.com/2012/10/10/in-memory-databases-part2/.

[2] Shun J， Blelloch G E. Ligra： A lightweight graph processing framework for shared memory[C]. In： Proc. of the 18th ACM SIGPLANSymp. on Principles and Practice of Parallel Programming. ACM Press， 2013：135-146.

[3] Prabhakaran V， Wu M， Weng X， et al.Managing large graphs on multi-cores with graph awareness[C].In： Proc. of the Presented as Part of the 2012 USENIX Annual Technical Conf. （USENIX ATC 2012）. 2012： 41-52.

[4] Wang G， Xie W， Demers A， Gehrke J.Asynchronous large-scale graph processing made easy[C]. In： Proc. of the 6th Biennial Conf. onInnovative Data Systems Research （CIDR 2013）. Asilomar， 2013.

[5] Low Y， Gonzalez J， Kyrola A， et al. Graphlab： A new parallel framework for machine learning[D].arXiv preprint arXiv：1006.4990， 2010.

[6] Garcia-Molina H， Salem K. Main memory database systems： An overview[J]. IEEE Trans. on Knowledge and Data Engineering， 1992，4（6）：509-516.

[7] DeWitt D， Katz RH， Olken F， Shapiro LD， Stonebraker MR， Wood DA. Implementation techniques for main memory database systems[J]. In： Proc. of the SIGMOD. 1984，14（2）：1-8.

[8] Kemper A， Neumann T. HyPer： A hybrid OLTP & OLAP main memory database system Based on virtual memory snapshots[J]. In：Proc. of IEEE the 27th Intl Conf. on Data Engineering. Hannover， 2011： 195-206.

[9] Diaconu C， Freedman C， Ismert E， Larson PA， Mittal P， Stonecipher R， Verma N， Zwilling M.Hekaton： SQL servers memoryoptimized OLTP engine[J]. In： Proc. of the 2013 ACM SIGMOD Intl Conf. on Management of Data. ACM Press， 2013：1243-1254.

[10] Nitzberg B， Lo V.Distributed shared memory： A survey of issues and algorithms[J].Computer， 1991，24（8）：52?60.