560 likes | 729 Views
上交所新一代交易系统 市场参与者 部署启动培训材料 2009年2月. 提纲. 背景 会员端变动说明 EzOES报盘程序简介 新交易系统会员数据接口变动情况简介 RptGet盘后文件获取程序简介 EzMonitor监视程序简介. 背景. 上交所决策层在2002年的战略思考. 决策:对交易系统进行升级换代 内部:整合配套系统接入,集约化到存储网关与消息总线这样的公共基础设施上来; 市场:扬弃市场传统数据库接口;逐步支持国金标STEP协议接口; 架构:无单点故障设计,满足高可用性设计需求; 扩展:多主机负载分担,满足水平扩展设计需求;
E N D
上交所新一代交易系统 市场参与者 部署启动培训材料 2009年2月
提纲 • 背景 • 会员端变动说明 • EzOES报盘程序简介 • 新交易系统会员数据接口变动情况简介 • RptGet盘后文件获取程序简介 • EzMonitor监视程序简介
上交所决策层在2002年的战略思考 • 决策:对交易系统进行升级换代 • 内部:整合配套系统接入,集约化到存储网关与消息总线这样的公共基础设施上来; • 市场:扬弃市场传统数据库接口;逐步支持国金标STEP协议接口; • 架构:无单点故障设计,满足高可用性设计需求; • 扩展:多主机负载分担,满足水平扩展设计需求; • 接口:系统间和系统内部定义清晰接口规范,满足松耦合设计需求; • 产权:拥有完全自主知识产权,但善用“外脑”; • 文档:厘清系统功能规格和接口规格说明书;与业务部门和接口系统之间通过强制性的“签约”进行变更管理;
满足高性能需求面临的设计困难 • 小型机采用的CPU主频徘徊不前,CPU厂家没办法的办法:增加核;导致我们应用程序设计也不得不采用多进程流水线技术来提升性能。 • 内存在主机掉电等场景下数据会丢失,必须写入磁盘才能“永久化”,且只有在 “永久化”之后,才发回确认。导致我们不得不用双进程交替执行并行技术来使得磁盘操作和内存操作并行,使得性能达到纯内存操作的性能。 • 自行管理内存导致应用程序复杂度大幅提高!而海量规模的数据甚至导致二分查找这样的O(log2 N)复杂度的算法都不够快!
满足事务处理需求面临的设计困难 • 要保证交易系统不丢单、不重单,必须实现如下规则: • 前台发现无响应时重传 • 后台保证同一订单不会被重复处理 • 后台查重的功能,简化了前台设计 • 后台查重的功能,便于前台使用“合同号”撤单 • 但是海量订单规模下,查重处理开销较大,需要提速
满足快速响应需求面临的设计困难 • 通过轮询的技术来获取成交确认信息,可能会遇上“运气不好”的时候。没办法的办法:采用订阅/广播技术,即后台主动向前台推送成交,试图为投资者提供最迅速的成交确认信息。 • 订阅/广播技术复杂度较高,需要进行“流控”和“重传”设计。 • 为保留扩展性,多个成交确认流并发向下推送,导致传统接口表上的处理复杂化。 • 公共信息也采用订阅/广播技术,未来可以通过STEP接口“点播”行情,即行情针对某一个证券,只有在后台发现行情变更时,才主动向前台发出。
满足高扩展性需求面临的设计困难 • 多主机在带来方便扩展系统性能和容量的同时,对于某些必须串行的业务:“指定交易变更”,在技术实现上带来很大的复杂性。 • 其他采用多主机的市场要么是T+1进行转托管,要么后台不控制投资者帐户。而我们由于“路径依赖”,必须要支持T+0的指定交易撤销/指定指令的执行。 • 为了不改变现在习惯,我们在前台对指定交易指令进行了“停-等”控制。指定交易指令发出后,该投资者后续的其他指令只有在前面的指定交易确认后,才会向后台发出。 • 给大家提一个问题:“如何支持大批量的转移指定?” • “ETF申购赎回”有类似的复杂度
会员端变动说明 • 交易所在会员公司的前端软件主要有四个部分: • 报盘软件,升级到EzOES • 盘后数据获取软件,升级到RptGet • 行情接收软件,本次不做调整 • 新增报盘监视软件,可择机试用 • 为完成新交易系统市场切换,会员公司动作如下: • 调整柜台系统,兼容新接口; • 使用新开发的EzOES报盘软件; • 使用新开发的RptGet软件获取盘后数据; • 根据会员公司实际情况,试用报盘监视软件
EzOES的发展历程 • 2006年底,新一代交易系统在市场参与者端部署了会员集成服务系统(MISS),并进行了市场演练。该次演练,反映系统成熟度不足,还有待改进才能推出。 • 2007年初,所领导带队走访了部分券商,听取了市场参与者对演练和切换上线的建议和意见。 • 2007年中,技术中心根据市场参与者的访谈反馈,本着“服务市场”的精神,对会员端软件设计进行了调整,重新开发了EzOES软件,作为市场参与者与交易系统的报盘软件。 • 2008年中,根据部分会员参加测试的反馈,对用户界面进行了进一步优化。
EzOES的设计要点 • 操作界面、操作习惯和配置方式与现有报盘程序基本兼容。继承多PBU同时报盘、多种主流数据库版本接口、网络自动重连和多链路切换方面等特性。 • 使用Java进行开发,支持跨平台运行。 • 成交回报采用“后台推”的方式,保证会员公司最快地获得成交信息。 • 界面上新增一些信息例如流速权、通信服务器地址等进一步方便日常运维。 • 支持登录交易系统的用户口令和登录数据库的用户口令加密存储;支持批量启动和批量停止,方便日常运维。 • 支持被实时监视工具监视,且提供接口可以与会员公司自己的监视工具集成。
EzOES的安装、卸载和配置 • EzOES是一个绿色软件,安装十分简便。 • 先下载并安装JRE1.6版本; • 从交易所网站上下载软件压缩包; • 将其解压释放到硬盘; • 在桌面上创建快捷键。 • 如需要卸载软件,退出运行后,删除EzOES所在目录和相应快捷方式即可。 • EzOES的配置方式借鉴了现有报盘程序的配置方式,采用通过配置文件来管理的方法: 在EzOES安装目录下cfgA / cfgB分别存放为A/B股配置文件。 文件结构和现有系统相同,用户可以将现有系统的配置文件拷贝到上述目录中,然后用文本编辑工具进行修改。 • EzOES中大部分配置项均可通过EzOES中的操作界面进行修改。
EzOES修改的配置项 • 主要需要修改内容如下: • OperCode填写5位PBU加6位操作员。23145000001表示PBU23145的000001操作员 • 修改Gwip为交易所分配的前置机地址,LocalIP为报盘机本地网卡地址。 • 将数据源配置修改为JDBC的方式,配置相关参数: • jdbc.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver • jdbc.url= jdbc:sqlserver://localhost:1433;databaseName=oiw • 请用数据库服务器IP代替localhost,数据库名代替oiw。 • 对sql2000以下版本用户以及其他类型数据库的用户,数据库驱动配置方法请参考帮助文件。 • 以下参数过期,不用配置 • GetCJHBFromTE;GwWay;DataSource;ConsignTime和CjhbTime。
交易前置机参数配置调整 • 把交易前置机切换为通信服务器 • 根据Gwip在目前生产系统中的取值,通过查地址对照表,得出在新交易系统中通信服务器的IP地址 • 检查报盘机的主用链路和备用链路是否接入同一个通信服务器,或者接入名称同为偶数或者同为奇数的通信服务器,若是,则进行调整 • LocalIP为报盘机本地网卡地址,可以重复
时间同步 • 市场参与人可通过设置操作系统级别的参数设置,配置报盘机与后台通信服务器进行NTP时间同步。此处通信服务器的IP地址须和报盘登录的通信服务器相同。 • EzOES应用程序不需使用Administrator用户登录Windows,运行中应用程序不更改系统时间。 • 用户界面上时间显示区会随着操作员的登录变化,在登录前显示当前时间(本地),在登录后显示交易系统时间/状态。
EzOES和现有报盘程序主操作界面比较 • 左侧是EzOES和现有报盘程序主操作界面运行时的截屏对比。 • 主操作界面都包括以下几个区域:操作员列表区、当前时间显示区、交易主机状态区、交易时间段区和系统信息区。
EzOES和现有报盘程序操作员列表区比较 • 上面的两个截图,是EzOES和现有报盘程序主界面中操作员列表区对比。 • EzOES增加了序号栏、选择控件、Local IP栏、流速权栏(含最近一分钟报盘速度)。对重要信息用不同颜色表示。
EzOES的批量启动和批量停止 • 可以加密存储操作员口令和数据库用户口令 • 可以通过选择控件和批量启动/批量停止菜单项进行批量操作
EzOES和现有报盘程序的当前时间显示区界面比较 • 上面的两个截图,是EzOES和现有报盘程序的时间、交易状态显示区。 • EzOES应用程序不更改系统时间,该显示区会随着操作员的登录变化,显示当前时间(本地)和交易系统时间/状态。 • 市场参与人可配置与后台通信服务器的NTP时间同步。 • 运行过程中,如果人工调整报盘机的本地时间,如果不在当前交易时段内,可能发生异常,且会在2分钟后重新同步。
EzOES和现有报盘程序信息区的比较 • 上图是EzOES和现有报盘程序系统信息区的对比 • EzOES提供一种接收全市场短消息广播的备份通道功能 • EzOES可以设定只显示警告和错误信息 • EzOES可以设定只显示某个PBU的信息 • EzOES对不同的系统信息用不同的颜色进行区分,红色为主机相关错误,蓝色为本地错误,其余提示性信息为黑色
关于EzOES配置的补充说明 • 操作员配置通过用户界面修改后重新登录即可生效。但如通过修改配置文件修改,则需要重启应用程序。 • 链路组合的增、删操作属于敏感动作,故不提供用户界面,需要通过修改配置文件来完成。
关于启动过程的补充说明 • 操作员密码长度限制在8位内,请使用复杂组合。 • 每个交易时段第一笔订单采用“敲门-等待-再敲门”处理逻辑。 • 登录时如果发现有非当日报单数据,则拒绝登录,必须把数据修复后才能登录。 • 登录时如果发现申报表数据rec_num不连续,则拒绝登录,必须把数据修复后才能登录。
关于链路故障恢复的说明 • 与上交所的链路 • 请把高带宽的链路配置为第1链路。 • EzOES允许LocalIP可以重复。 • 如果当前链路中断断开,从第1链路开始尝试重新登录,直到所有链路尝试完毕。 • 与接口库的链路 • 与接口库链路中断,EzOES会把PBU退出,请使用备份设备或者修复链路后重新登录。
监视接口 • EzOES定时输出状态文件 • 揭示市场类型、OES状态、交易员状态、当前工作、PBU报单数、委托确认数、成交数、流速权、MaxRecNum等。
关于日志文件的说明 • 日志分为两类,VSLog和OESLog。 • 二者均处于\logs下。 • VSLog记录简单信息,比如操作员的登录注销等、业务错误。 • OESLog记录关键点的流程信息、数据库信息、和CS交互的数据、异常信息等等。 • EzOES不删除过期日志历史VSLog和OESLog。过期文件名中均包含日期。 • 请会员公司运行维护人员对日志进行管理,比如备份、删除。
降低接口数据库资源的消耗 • EzOES采用批量读取/批量写入的方式与接口数据库交互 • 接口数据库访问队列超过设定阈值时,会暂缓报单
高级参数配置 • 每次从数据库读取的订单块大小dbOrdFetchUnit • 重传表3的参数配置,缺省45,最大360 • 需要确认是否对表3进行恢复的条数阈值tc.gapalarm • 多环境支持envNo • 是否支持监视monitor.active • 监视信息输出时间间隔monitor.interval
数据接口 • 新交易系统的会员端数据接口和现有交易系统的数据接口基本保持一致,但由于后台架构的升级换代,导致有一些变化,这些变化均在数据接口规范中有描述。 • 会员柜台系统必须“各自独立地”于2009年4月底前完成升级,兼容上交所两代交易系统的数据接口。 • 在上交所新交易系统市场割接日,会员柜台系统无需调整。
对柜台系统有影响的数据库表接口实现之差异 • 两类数据写入顺序从单进程变成了多进程 • 申报接口确认表写入顺序不再完全按照rec_num字段递增写入,而是按照后台多主机实际处理顺序写入。(注:同一PBU同一产品不同订单之间的先后顺序不会变化) • 成交确认表写入顺序不再完全按照cjbh字段递增写入。在gdxm和bcye字段提供了SET和成交在该SET内顺序号。 • 日常处理场景中,在切换点可以通过增加自增字段来仿真以前的单进程逻辑;在未来柜台也可考虑调整为多进程逻辑。 • 灾难备份场景中,三个场景是大家关心的: • 如何在灾备切换后尽快恢复报单? • 如何对灾备切换前已申报订单进行撤单? • 如何在灾备切换后进行成交回报的“断点”处理? • 如何进行大批量转指定?
如何在灾备切换后尽快恢复报单? • 申报表不再严格要求recnum从1开始,只要连续递增即可。 • 如果申报表损坏,市场参与人启用备份数据库,不需要插入空记录,只要在新的申报表中直接插入后续订单即可申报。 • 由于交易系统后台对同一个PBU、同一个产品集、相同rec_num的订单不会重复处理,所以切换时,后续订单的编号每切换1次必须超过已经向交易所发出的rec_num号,市场参与者可以通过累加一个其业务上不可能发生的值比如1000万,来避免重单。
如何对灾备切换前已申报订单进行撤单? • 在切换点把数据库表接口调整为:不再要求待撤销申报所对应的申报表记录和申报确认表记录在数据库中存在。也就是说不用恢复由交易所产生的申报确认记录,直接根据会员自己备份的申报记录即可撤单。 • 切换完成后的短期内,可进一步根据大家的正式需求,逐步地推出支持用“Reff”字段来撤单的报盘机软件。Reff撤单需要柜台系统满足如下要求: • Reff后8位必须在1个PBU内部当日唯一。 • 撤单记录中ordrec字段需要填写待撤订单Reff的后8位。 • 接下来,STEP/FIX协议接口中撤单就是用的“Reff”模式。即没有在接口机上的落地数据库表,采用直通方式处理。目标:更快更简洁。
如何在灾备切换后进行成交回报的“断点”处理?如何在灾备切换后进行成交回报的“断点”处理? • 要点一:从交易所恢复只需要恢复的数据。根据转义后的gdxm和bcye,从柜台系统中找出每个SET处理过的最大成交顺序号,将这些断点写入灾备系统中的报盘接口表中。 • 要点二:由于成交顺序号在一个SET内,对于一个PBU是“连续”递增的,可以快速定位断点。
如何进行大批量转指定? • EzOES对同一个投资者帐户的指定交易变更和后续的其他订单进行停-等 • 不要使得同一个投资者帐户的指定交易变更指令之后就立即进行该账户其他订单输入或者该账户另外一个指定交易变更 • 可采用批量提交一批投资者的指定交易变更指令的方式进行大批量转指定
市场参与人接口后续规划 • 接口方面持续优化的目标: • 进一步提供更高报单速度更快响应时间的接口 • 进一步规范,提供更为灵活简洁,支持业务扩展和程序交易的接口 • 字段扩位 • 报盘接口系列化:传统数据库表;STEP协议 • 报盘程序监视和控制接口公开化: • 提供状态文件定期刷新的方式公开报盘接口机监视接口 • 提供指令文件/指令应答文件的方式公开报盘接口机操作接口方式 • 行情接口系列化:传统文件接口,定期全量;STEP协议接口,定期全量+实时变量 • 盘后文件或者其他信息类接口 • 传统已有文件 • 部分文件字段需要扩位
报表数据获取软件 • RptGet软件也是绿色软件,无需安装,直接解压在一个目录中即可。 • RptGet软件主要用于通过双向链路从交易所后台获取每天各个PBU的报表文件,主要是成交记录文件等。 • RptGet软件主要提供三个界面:报表下载、授权关系维护、查询、参数配置。 • 变化如下: • 支持手工查询,选择特定报表下载,增加了灵活性 • 增加用户查询被授权关系功能 • 支持对查询结果按任意项目排序,方便用户手工选择自己需要的报表 • 所有操作结合在一个主界面,通过子界面来进行切换,配置更加丰富,提高了用户可用性和灵活性
报盘机监视软件 • 通过报盘机监视软件,会员公司可以在一台机器上集中地看到多个报盘机和其上PBU的状态。 • 交易所会公开监视接口,会员公司可以集成到自身的监控系统中。 • 报盘机监视软件EzMonitor分为两个部分: • 监视端(Monitor),包含了监视的主界面、报盘机状态窗口、PBU状态窗口、报盘机详细信息界面、报盘机信息维护界面以及其他对话框窗口。 • 探针端(Agent),为监视界面提供了探针接口,实现从EzOES获取运行状态、获得报盘机状态等信息发送给监视端。 • 监视端(Monitor)与探针端(Agent)通过TCP/IP进行通信,端口号可以在Monitor和Agent的操作界面上进行修改。 • 一个监视程序可以同时监视多台报盘机,一台报盘机可以配置允许被多台不同的监视主机的监视,但是同时刻活跃的监视主机只能有一台。