AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

证券交易系统架构设计-挑战与实践 by 陈晨@上海证券交易所

发布者 finance
发布于 1437614282344  浏览 11539 关键词 架构, DevOps, 互联网金融 
分享到

第1页

证券交易系统架构设计
上海证券交易所    技术开发部 
陈晨
cchen@sse.com.cn       +86 138-0199-1611
—— 挑战与实践

第2页

目录

第3页

上交所交易系统介绍

第4页

发展历史
1990年11月26日成立,同年12月19日正式营业。

第5页

1997,1999
发展历史
开业的第一天就采用电子撮合系统进行交易撮合
基于Novell服务器的局域网络
每秒处理3笔业务,月处理成交2万笔
市场的委托、行情、成交回报等环节仍需要手工完成
1992年12月,系统升级
Novell主机更换为基于惠普小型机UNIX操作系统
每秒200笔,日处理能力200万笔
1993年,采用单向卫星广播行情,双向卫星接收报单
1997年和1999年进行了两次设备和应用的重大升级
系统处理能力提高到每秒2万笔,日处理能力800万笔
后随着不断的扩容和改造,性能和容量不断被刷新

1990.12.19
开业第一天即采用电子撮合系统
每秒处理3笔,月处理2万笔
上交所
1992.12
系统升级,采用UNIX小型机
每秒200笔,日处理200万笔
1993.1
采用卫星广播行情
双向卫星接收订单
系统两次升级,性能提升至每秒2万笔,日处理800万

第6页

发展历史
新一代交易系统的上线
2009年11月23日,新一代交易系统上线
使用多主机并行撮合
最高支持10万笔每秒
全天容量1亿笔订单
帐户容量1亿
基于新一代交易系统,2014年11月17日沪港通业务上线
2009.11.23
新一代交易系统上线
使用多主机并行撮合
最高支持10万笔每秒
全天容量1亿笔订单
账户容量1亿
上交所
2014.11.17
沪港通业务上线

第7页

海外市场
市场结构图
证监会
上交所
上期所
深交所
大商所
券商
基金公司
股票
债券
基金
商品期货
贵金属
中金所
QDII
郑商所
权证
监管者
基础设施
市场参与者
     投资者
股指期货
OTC
     产品
香港投资者
上市公司
行情商
指数公司
中登公司
SFC
港交所
沪港通

第8页

系统结构图
券商柜台系统
交易所报单机
通信服务器
通信服务器
交易主机
交易主机
交易主机
交易主机
外部接口主机
外部接口主机
消息总线
存储网关
其他各类系统


交易专网
核心交易系统内部结构

第9页

交易系统技术架构

第10页

交易系统技术架构
交易系统的三层式划分
接入点 B
接入点 A
接入点 C
基金公司
资管公司
沪港通
交易层
定序层
接入层

第11页

交易层

第12页

交易层集群锁管理模式
基于OpenVMS的Lock机制,实现了一套用于集群(Group)管理,集群内各主机同步、通信的工具库
81
82
83
获取锁成功,成为集群Master
获取该锁失败,成为集群Slaver,同时被告知Master为81
获取该锁失败,成为集群Slaver,同时被告知Master为81

第13页

接入层

第14页

定序层

第15页

挑战及解决之道

第16页

交易系统面临的挑战
交易系统在设计之初就要考虑到如何满足和平衡各方面的技术需求
架构设计是一个平衡和抉择的艺术

第17页

高性能
衡量交易系统性能主要指标
吞吐量
订单时延
系统容量

第18页

高性能1. 流水线化内存撮合
HCCM
主机与通信服务器间通信
HHCM
主机间通信
MSRT
撮合直通路由器
Pre Matcher
撮合预处理模块
Main Matcher
主撮合模块
Trade Confirmation
成交确认
Data Replication
数据持久化
Market Data
行情数据
Trade Book Maintain
成交簿维护
      撮合内部消息流
撮合下游消息流

第19页

高性能2. 内容和键值分离
精简的进程间通信消息
消息body通过内存缓存;
进程间传递短小的消息header;
进程通过header信息,访问内存获取消息实体;

第20页

高性能3. 数据打包处理
消息的打包处理
请求消息通过用header表示后很短小,支持多条打包模式;
申请新的共享内存消息,消息体中包含多个请求实体的header;
实际消息通信中传递打包消息的消息header即可;
进程接收消息后,根据打包消息body中的多个实际消息header,逐一处理。

第21页

高性能4.多线程异步IO
应用异步IO提升性能的典型案例
调用进程通过异步IO连续的抛出一组IO请求,RMS可以并行地处理这些请求,成倍地提升IO吞吐量;
连续发出的请求应当有一定限制,当未完成的请求数量达到限制时,调用进程可以主动将自己阻塞。

第22页

高性能5. 多机并行

第23页

高可用
衡量交易系统可用性主要指标
恢复时间目标RTO(Recovery Time Objectives)
恢复点目标RPO(Recovery Point Objectives)

第24页

高可用技术抉择的难题
人工侦测故障           OR     应用程序自动侦测故障?

应对单点故障           OR      应对双点故障?

同城灾备同步复制   OR      异步复制?

第25页

高可用1. 站点备份
站点备份

第26页

高可用2. 主机备份

第27页

高可用3. 进程恢复
进程的恢复机制
事务/请求数据带事务的文件存储,包含相应的状态位;
任何一个进程异常,根据事务文件中数据状态重演恢复;
无法应对程序本身逻辑错误

第28页

高可用4. 消息重发/防重处理
系统发生主备切换
切换完成后的自动通知机制
未响应消息重新路由机制
消息防重复处理机制

第29页

高可用5. 流控机制
流量/负载控制:
系统必须提供自保护机制来处理异常的大量或者突发交易量
包括主动控制和被动控制
主动控制:
主动控制实现于前端(请求源端)会员,根据尚未响应的订单数量控制请求发送速度
系统可配置成会员端总体的请求数量不超过后台的处理能力,因此从源端控制整个系统的负载
被动控制:
路由架构内置的自我保护机制
每个路由架构组件跟踪其输入/输出差异,并且根据监测的差异触发自我保护机制来或者阻塞消息流,或者弹回新的请求

第30页

易扩展
主要指标
扩展性衡量系统适应业务发展与变更的能力,既包括业务容量的扩展又包括业务模式的扩展
应对方案
高扩展性需要在内部核心数据结构和接口定义上预留足够的扩展空间。
系统内部结构上,通过分层抽象服务使得某一个层次的升级更新不影响到全局架构,通过模块化设计使得某一个模块的变更不影响到整体稳定。

第31页

易扩展1. 系统架构的扩展
FrontEnd
HostTier
CS
CS
CS
CSTier
LAN
OES
OES
OES
OESTier
Binary values
Fix
Step
ProtocolTier
BackEnd
LAN
WAN
or
LAN
后台的扩展
交易层中的各个平台,可以平行扩展设备,支持业务的容量和品种的发展
接入层中,可以根据网段规模和接入点无缝第进行平行扩展;每个接入点属于无状态设备
前台的扩展
对于市场参与者的接入,既提供客户端的模式,也支持消息协议和API的模式扩展
交易所提供的接入端可以无差异的多地不少和彼此备份、分流业务数据等

第32页

易扩展2. 应用配置的扩展
基于产品的不同类别配置,可根据负载均衡的原则,重新进行划分或扩展
单一类别的处理容量可以通过配置参数进行调整。调整后的容量在系统重启后自动生效
银行股
银行股A
银行股B
主机1
主机2
主机1
医药板块
零售板块
订单量200w
订单量200w
医药板块
零售板块
订单量500w
订单量150w

第33页

易扩展3. 设计模式的分层设计
业务应用系统
Patten 
Layer
Function
Layer
Wrapper
Layer
OS 操作系统 (Linux, UNIX, Free BSD等支持POSIX接口的操作系统)
批处理架构
BAT Arch 
消息通讯架构
MSG Arch 
应用进程架构
SHL Arch 
监控架构
MON Arch 
操作架构
OPT Arch 
高可用架构
H Arch 
共享内存库
SHM Lib
日志库
LOG Lib 
同步IO库
SIO Lib
异步IO库
AIO Lib
配置信息库
CFG Lib 
数据算法库
DSM Lib
应用锁库
LCK Lib
C99标准
POSIX标准
OS Feature
GLIB
Log4c
OS  Wrapper
3nd Party Lib Wrapper
错误
传递




数据
类型




框架
配置

第34页

交易系统的未来

第35页

交易系统的未来
轻量化的技术系统
小型机 -》PC服务器
开放性的转变
封闭操作系统 -》开源操作系统
商业应用软件-》开源应用软件
形成企业级的基础库
EzWEB
EzSOFT
HAP
新技术新算法的研究
FPGA
Infiniband
全内存备份




第36页

互联网格局下的交易系统
更多的外部攻击
更长的交易时间
更复杂的业务处理
更紧迫的竞争压力

第37页

Thanks!
支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。