交易系統更新與跨越

2018/01/05 閱讀筆記 共 4600 字,約 14 分鐘

在金融業裡大多數採用封閉式系統作為伺服器,且年代幾乎跨越十年二十年之久,而電腦技術先進和開源資源豐富的現在, 透過軟體達成以往大型主機的功能也並非不可能,從Google、Facebook的崛起就可以知道分散式系統再也不是遙不可及的, 在摸索交易系統歷史的脈絡中,一個中國的blog給我很多關鍵字和引導,博主是一位上海證交所的技術主管。 作為一個不到30歲而無幸參與的年輕人來說,真是由衷感謝。

這個blog的內容後來似乎集結成書,書名為「交易系统更新与跨越」武剑锋著,年代為2010年。

趁著這個周末把一些相關重點整理起來。


效能約達80k筆訂單/秒,日成交1.2億筆

對外傳輸協定 FIX Protocol

http://fixglobal.com/home/china-market-on-forward/

上海证券交易所(上交所)白硕总工程师介绍STEP协议的重要性及其在中国的发展

Bai Shuo, Shanghai Stock ExchangeSTEP协议是如何开始的,它是由哪些组织最早开发的?

早在2003年,在开始筹备新一代交易系统(该系统于2009年11月23日上线)项目时,上交所就已决定引进一套基于消息的交易所与券商之间的协议 ,该协议被广泛认可为金融信息交换协议(FIX)。这一开创性的工程获得了中国证券监督管理委员会(证监会)的支持。在全国标准化的框架下,该协议成为证券行业的八大标准之一。WG01工作组负责在证监会的指导下起草该协议。WG01工作组的成员包括:上交所、深交所、上期所以及国信证券等证券公司。该协议被正式命名为《证券交易数据交换协议》,简称STEP协议(非正式名称为中国的FIX,或CFIX),它的推出被视为建立一流证券市场的第一步。STEP 1.0版编写于2004年,并于2005年发布。2006年,STEP被修订为1.1版。

STEP是如何适应中国金融界的总体标准应用的?

虽然FIX是证券行业的全球标准,但STEP更适合中国市场,因为STEP引入了许多本国业务,并对若干消息与字段增加了本地定义。比如,国内证券交易需要控制到投资者账户,这一信息被纳入Parties组件。同时,在8500到8540区间为中国分配了41个字段,用于行情揭示以及各种基金、权证、投票业务。对现有字段取值扩展定义的有:订单类型(tag40)、订单拒绝原因(tag103)、行情条目类别(tag269)、交易状态(tag326)等。

STEP的应用范围如何?其涉及交易周期的哪些部分?适用于哪些资产类别?

STEP涉及交易周期的交易前及交易部分以及一些特定的注册指令。STEP适用于股票、基金、债券、权证、交易所交易基金以及许多特色非交易业务,如首次公开发行、股票增发、基金申购及赎回、权证行权、债券出入库、股东投票等。

较早采用STEP的组织有哪些?有哪些组织目前正在使用STEP?为什么?

上交所已经把STEP用于Level 2行情信息服务,业内相关的信息服务商同期启用了STEP协议。原因是,对于这类创新型的技术服务,采用STEP可以利用其容易扩展和便于维护的特性,且没有兼容遗留接口的负担。

STEP的下一个发展阶段是什么?近期内STEP采用率增长最明显的领域是什么?STEP有新的目标或应用吗?

由于过去五年中许多新业务的推出,STEP正在进行修订。STEP/FAST近期将用于上交所Level 1行情分发。上交所综合业务平台(ATP)上的大宗交易业务、报价回购业务以及约定购回业务、转融通业务也将在近期采用STEP作为业务记录标准格式。在未来,待在创新型业务上积累了更多的经验后,我们将逐步地在传统的核心业务上应用STEP协议方式来作为接口。

系統規模約100萬行 (除了系統基礎架構外應該還包含業務層)

交易系統在此指稱作為證券交易所的交易撮合系統

交易系統的設計可分為兩個面向:交易機制、架構設計

架構上須滿足六項需求

  1. 交易訂單的傳輸到系統中
  2. 訂單的正確性 有效性 完整性 不可否認性等等
  3. 依照業務邏輯的訂單撮合
  4. 訂單執行結果返回使用者手中
  5. 成交情況轉交給結算系統
  6. 公開市場行情

以及系統的特性須滿足

  1. 訂單的Exactly once
  2. 事務的ACID
  3. 恢復時間指標RTO 恢復點指標RPO
  4. 容量和性能滿足業務需求
  5. 靈活高效能的對外接口

為何系統需持續更新與推進

  1. 硬體的效能進步
  2. 開源軟體的版本更新
  3. 業務需求的增加

全球著名交易系統survey

技術面對於交易系統主要關注

  • 可用性
  • 擴展性
  • 性能
    • 低延遲
    • 吞吐量 (反而對於高併發需求較低)
  • 可維護性

總之,面對軟硬體破壞、request壓力、業務變更下,交易系統能安全運行

X.25 Protocol

紐約證交所的三層式架構

主機層使用Tandem Nonstop設備 SuperDOT 中間層(通訊主機) HP的K系列 訊息交換 第三層 用戶端

NASDAQ

兩個資料中心 Tandem S系列 K系列 55個node 700個CPU UNISYS主機 - 數據廣播 排隊 報價更新 資料庫 數據交換用乙太網 FDDI互備

泛歐證券交易所

NSC Nouveau Systeme de Cotation 四層式架構

  • 交易主機層 NSC/VE NSC/VF 撮合
    • 採用Tandem Himalaya K2000
    • Tandem Pathway Transaction Monitor 負載均衡
  • 消息路由層 HUB/DIFF 處理接收訂單或成交訊息發送
    • DEC Alpha Server
  • 訪問層 CAP/MAP
    • 專有協議 MMTP (Market Message Transfer Protocol)
    • FIX
  • 市場參與者層

LIFFE 三層式架構

  • 接口服務層
  • 交易所通信層
  • 交易主機層 Sun系列, Active-Standby, In-memory system

德國交易所

Eurex 和 Xetra 四層式

  • 交易主機層 4台HP Server
  • 通信服務層
  • 會員集成層
  • 交易商系統層

北歐

SAXESS

  • 交易主機 Sun主機
  • 信息發布機
  • 前端服務機

1+1 Active-Standby 部署

上海交易所的過去系統技術選型

第一代 386 PC/Novell 第二代 PA-RISC/HP UX

世界主流平台HP NonStop, HP OpenVMS, Sun Solaris

2003年的Benchmark 選擇幾個歷史交易日作為input 比較撮合能力、延遲時間、容量支援、行情發布

Tandem的NonStop機器

特殊設計的硬體支持單點故障的快速回復

1997年開始使用Intel Itanium處理器 NonStop OS 支持Java

(NonStop機器有其特殊的開發環境存在,非一般的X86?)

Linux關注

DRBD(Distributed Replicated Block Device)

DLM(Distributed Lock Manager)

系統開發上仿照HAL的概念,把應用系統和操作系統隔離,減低移植困難度

系統設計要點

新系統設計

  • 提高吞吐量
    • 訂單打包
  • 策略調整
    • 廣播 (pull vs push)
  • 高可用性策略
    • 允餘
    • 持久化 (持久化後發出確認訊息 RPO = 0)
  • 數據離線備份
  • 從離線數據恢復
  • 可擴展性
    • 功能劃分模組 (SOA)
    • 負載劃分
  • 避免分布式事務 降低同步需求
  • 引入異步處理 隊列系統 事件驅動

交易系統應用架構宏觀設計

在新舊系統銜接期,利用工具將舊系統訂單轉換為新系統協議後,送到後台撮合,進行結果比對,持續一年多

高負載情況下可能導致系統雪崩,要對源頭進行流量控制

數據流

  • 訂單輸入 (通信主機)
  • 撮合處理 (交易主機)
  • 成交生成 (交易主機)
  • 數據發布 (外部接口主機)

系統設計

  • 分層設計  - 同一層次的設備在同一網路內  - 越接近核心,接入設備數量越少
  • 故障隔離  - 不同子網,防止網路風暴
  • 負載均衡  - 至少一個設備在其他數據中心  - 減少硬體failover依賴,應用層切換備援
  • 叢集
    • 容災部署   - 多機部署於至少三個站點,一個站點完全失效,還有兩個站點可用   - 叢集共享系統訊息安全數據:用戶信息、權限控制  - 防腦裂    - 多數派原則 (how to detect?  - 全連接    - 所有主機互相連接,任一連線被破壞,重新調整系統,移除有斷線的主機
  • 分布式鎖

消息驅動模型

前台請求

  • 無回應時自行重傳
  • 後台去重複
  • 消息在節點中支持重新發送

中台通信伺服器

  • 功能相近 放在同一個process
  • process互鎖 任一process死亡 整台機器終止提供服務
  • 前台通信管理器 (消息傳遞 路由  - 消息隊列 FIFO
  • 後台通信管理器 (消息傳遞 路由
  • 連接管理器 (登陸管理
  • 行情管理器 (行情多播轉發

交易系統還可能有異步消息,成交回報 被撮合後發出成交消息,一筆訂單可能撮合上百萬張單

解決方法 push + pull 後台主動廣播,前台檢測遺失包並發出重傳請求

前台到中台斷線時,前台自動重連到備用通信伺服器 中台到後台斷線時,通信伺服器停止向前台服務

後台交易主機

  • 交易主機
  • 中央主機  - 管理所有連接
  • 指數計算

  • 架構進程  - HCCM 主機與通信伺服器通信管理    - 接收來自中台的req,消息轉發給下面三個    - response回傳  - GSRT 同步路由管理 (非交易類請求?)  - MSRT 撮合路由管理    - 轉交req給撮合器  - HHCM 主機間通信管理    - 主機間信息路由、傳輸  - ART 異步路由管理    - 文件系統,先寫入訊息到文件,再發送觸發訊息    - 重新觸發器,檢查未完成的異步消息  - HROM 主機恢復管理
  • 應用進程  - 預撮合器  - 主撮合器  - 交易時段轉換觸發器

process設計sliding windows,req > response到一個數目會暫停發送

應用層廣播

後台發送成交回報時,可能是多到多傳輸,發現通信伺服器堵塞時,直接丟棄封包 讓通信伺服器發出回補請求,用auto increment id當消息編號

驗證:輸入上千萬筆賣出1股訂單,用一張單買入上百萬股,使得後台瞬間發出大量成交回報

行情類消息:用多播協議發送給指數主機、通信伺服器和外部接口

事務處理模型

  • 叢集系統
  • 不共享memory
  • 自研In-memory DB
  • 需要共享的數據,各機replay請求修改本地數據
  • ACID
  • master故障後,slave的數據與master故障前一致
  • 對產生故障的原因隔離繞開 (request?)
  • 持久化
  • 事務操作  - 訂單輸入  - 訂單撮合  - 訂單簿更新  - 成交生成  - 行情發布  - 持倉讀取  - 持倉修改
  • 自製mmap機制,定時持久化

(基本上是master-slave架構,master RW、slave read-only,slave replay binlog)

  • 熱備援切換  1. slave協調進程檢測到master崩潰  2. 等待slave停止複製工作  3. slave撮合器active  4. 通信伺服器改與slave連線  5. 前台重發訂單  6. 後台重發成交回報
  • 100ms內檢測到master失效
  • 切換過程約30秒
  • 前台中台消息隊列在切換中持續keep資料
  • 資料中心互備,同一資料中心內,有master也有slave

監控模型

  • 格式化錯誤訊息
  • 系統運行指標
  • 異步防止監控影響應用

破壞性測試

  • 核心進程
  • 部件
  • 連線
  • 數據中心全部掉電

2007年後國際交易所技術發展

  • 倫敦 => Linux
  • 德國 => RedHat Linux + IBM MQ LLM
  • NASDAQ => Amazon S3 Storage Cloud (!?

未來技術

  • 多核心的利用
  • Linux
  • Infiniband RDMA
  • 大數據 eco system

心得

  • 在前代系統中有著分布式鎖和狀態同步的蹤跡
  • 現在系統已經從NonStop和OpenVMS走向Linux
  • Message Queue System會是未來重點
  • 大數據的相關系統有可以借鏡參考的地方

文件訊息

Search

    Table of Contents