上海证券交易所新一交易系统部署启动培训资料.pptVIP

上交所新一代交易系统 市场参与者 部署启动培训材料  提纲 口背景 口会员端变动说明 口 EzOES报盘程序简介 口新交易系统会员数据接口变动情况简介 口 Rptget盘后文件获取程序简介 口 EzMoni tor监视程序简介  背景  上交所决策层在2002年的战略思考 口决策:对交易系统进行升级换代 ■内部:整合配套系统接入,集约化到存储网关与消息 总线这样的公共基础设施上来 市场:扬弃市场传统数据库接口;逐步支持国金标 STEP协议接口; 架构:无单点故障设计,满足高可用性设计需求 扩展:多主机负载分担,满足水平扩展设计需求 ■接口:系统间和系统内部定义清晰接口规范,满足松 耦合设计需求 产权:拥有完全自主知识产权,但善用“外脑” 文档:厘清系统功能规格和接口规格说明书;与业务 部门和接口系统之间通过强制性的“签约”进行变更 管理;  SHARE78国际标准定义的容灾系统七个层次 专门的远程灾备中心 Tim接近零或是零数据丢失,远程数据镜像,并且业务环境可进行高自动化的业务接管 Ter6近零或是学数据丢失,远栏数据镜像保证数据的完整性和一致性 Te5软件级的,两地点两阶段提交《交易完整性) Tie4批量在的教据库镜像耽日志的传输,重复的时间点持贝 可用的备份中心 Tm3电子链接件输 Te2PTAM卡车运送+热备份站点 时间点备份 Terl-PTAM开率运送访问 5分钟14小时48小时812小时1216小时24小时好几天 决复需要的时间(RTO)  满足高性能需求面临的设计困难 口小型机采用的CPU主频徘徊不前,CPU厂家没办法 的办法:增加核;导致我们应用程序设计也不得 不采用多进程流水线技术来提升性能。 口内存在主机掉电等场景下数据会丢失,必须写入 磁盘才能“永久化”,且只有在“永久化”之 后,才发回确认。导致我们不得不用双进程交替 执行并行技术来使得磁盘操作和内存操作并行, 使得性能达到纯内存操作的性能。 口自行管理内存导致应用程序复杂度大幅提高!而 海量规模的数据甚至导致二分查找这样的0(log2 N复杂度的算法都不够快!  满足事务处理需求面临的设计困难 口要保证交易系统不丢单、不重单,必须实 现如下规则 前台发现无响应时重传 后台保证同一订单不会被重复处理 口后台查重的功能,简化了前台设计 口后台查重的功能,便于前台使用“合同号 ”撤单 口但是海量订单规模下,查重处理开销较大 ,需要提速  满足快速响应需求面临的设计困难 口通过轮询的技术来获取成交确认信息,可能会遇上“运 气不好”的时候。没办法的办法:采用订阅/广播技术 即后台主动向前台推送成交,试图为投资者提供最迅速 的成交确认信息。 口订阅/广播技术复杂度较高,需要进行“流控”和“重传 ”设计。 口为保留扩展性,多个成交确认流并发向下推送,导致传 统接口表上的处理复杂化。 口公共信息也采用订阅/广播技术,未来可以通过STEP接口 “点播”行情,即行情针对某一个证券,只有在后台发 现行情变更时,才主动向前台发出  满足高扩展性需求面临的设计困难 口多主机在带来方便扩展系统性能和容量的同时,对于某 些必须串行的业务:“指定交易变更”,在技术实现上 带来很大的复杂性。 口其他采用多主机的市场要么是T+1进行转托管,要么后台 不控制投资者帐户。而我们由于“路径依赖”,必须要 支持T+0的指定交易撒销/指定指令的执行 口为了不改变现在习惯,我们在前台对指定交易指令进行 了“停-等”控制。指定交易指令发出后,该投资者后续 的其他指令只有在前面的指定交易确认后,才会向后台 发出。 口给大家提一个问题:“如何支持大批量的转移指定?” ETF申购赎回”有类似的复杂度  HSP101 hann o+m ath 半时