在金融業裡大多數採用封閉式系統作為伺服器，且年代幾乎跨越十年二十年之久，而電腦技術先進和開源資源豐富的現在， 透過軟體達成以往大型主機的功能也並非不可能，從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萬行 (除了系統基礎架構外應該還包含業務層)
交易系統在此指稱作為證券交易所的交易撮合系統
交易系統的設計可分為兩個面向：交易機制、架構設計
架構上須滿足六項需求
- 交易訂單的傳輸到系統中
- 訂單的正確性 有效性 完整性 不可否認性等等
- 依照業務邏輯的訂單撮合
- 訂單執行結果返回使用者手中
- 成交情況轉交給結算系統
- 公開市場行情
以及系統的特性須滿足
- 訂單的Exactly once
- 事務的ACID
- 恢復時間指標RTO 恢復點指標RPO
- 容量和性能滿足業務需求
- 靈活高效能的對外接口
為何系統需持續更新與推進
- 硬體的效能進步
- 開源軟體的版本更新
- 業務需求的增加
全球著名交易系統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會是未來重點
- 大數據的相關系統有可以借鏡參考的地方
