证券集中交易性能管理解决方案培训.pptx

1、证券集中交易性能监控解决方案议程1、集中交易系统的管理挑战2、Crossflow解决之道3、项目实施准备4、应用场景与案例集中交易系统的管理挑战技术风险与监控要素前台渠道多 覆盖全国的大量营业部系统水平参差不一，需要区分监控；来自电子渠道的交易所占比重越来越大，也是需要重点监控的交易环节多 包括通讯平台、柜台网关、交易中间件、数据库、报盘中间件、报盘机等，一旦发生问题需要快速定位故障外联机构多 需要跟银行、交易所、登记公司、监管部门、基金等机构互联，这些环节出问题需要首先确定问题职责边界交易集中化后，原本分散的风险汇聚成集中风险，一旦集中交易系统出现技术故障，整个公司的交易都会受到影响，甚至造

2、成严重后果。运维复杂性交易类型多通讯模式多交易时段短业务峰谷分化交易延迟敏感同步类交易：查询、资金操作等异步类交易：委托、撤单等集合竞价时段开盘、闭市时段客户满意度故障恢复速度要求更高交易客户流失行情同步/异步有排期监控和告警需求资讯发布行情波动交易系统问题的传统分析过程找问题查日志查数据库问题分析定位出结论 数据量巨大缺乏有效手段搜索性能差大海捞针需熟悉库表结构、SQL语句未到达数据库的异常交易查不到收集相关信息后，需要手工梳理、关联和分析，定位问题缓慢已经过了解决问题的时限，并且耗费大量人力物力区分是网络问题还是应用问题不同部门/工作组相互推诿缺乏实时性和快速故障定位能力无法适应快速发展的

3、集中交易系统证监会规定，符合下列情形之一，且未达到重大事件的为较大事件：证券公司、期货公司集中交易系统或者网上交易系统全部中断、部分中断，影响交易时间累计在5分钟以上的；（来源：http:/ 交易时间短，排障时间非常宝贵 无法接受不够实时的监控手段实时性 可用性要求非常高，故障恢复时间紧迫 交易系统架构复杂，需要快速定位问题在哪里快速定位 传统手段存在局限性，例如响应时间计算不够准确，丢失的交易查不到源头等 需要准确可靠的监控方法准确性 整个交易过程从外围接入到通讯前置再到交易中间件，然后经过报盘环节到交易所，任何一个位置都可能造成性能下降或故障，需要多段关联分析能力多段关联？交易系统典型运维

4、需求指标需求业务容量交易量基线偏离特定业务笔数业务速度平均时延应用时延网络时延交易所报盘时延可用性典型业务成功率过低重要业务响应率分析需求多段追踪分析 同一业务多段关联分析单笔交易端到端追踪历史数据回溯分析查看历史交易指标和明细保存原始交易数据实时性快速定位交易模型整理券商集中交易同步交易处理模式 同步方式是由客户端向服务器提出交易申请后进入等待状态，服务器对数据库中相关数据进行处理后向客户端反馈处理结果，客户端再进行一定的操作（数据变换、打印等）后结束本次交易过程。证券业务系统中采用同步模式的交易主要有涉及股民资金与证券账户的账户管理功能类交易、涉及股民资金在不同资金系统间划转的资金处理类交

5、易以及查询类交易。异步交易处理模式 异步交易处理模式又称为通知式交易处理模式，它与同步方式最大的不同在于客户在提出申请后，不需要立即获得最终处理结果，只要得到申请已被受理的确认后即可结束联机交易，处理结果将在未来时刻得到通知或可主动查询结果。异步交易模式通常应用于证券交易类中，这种模式的产生与证券交易的特定环境是密不可分的。整个交易处理的过程分为交易申请的受理及成交回报处理两个阶段。根据我们的分析，实时交易将是系统运行过程中业务量最大的。无论对网络或主机资源的需求也将最大。金证集中交易2314567213451.委托请求通过XP到达BP2.BP生成order-ID，同时写入DB-run3.报盘

6、中间件读取DB-run里的新委托4.报盘中间件发送给自动报盘机5.自动报盘机写入报盘接口库6.交易所报盘机读取到接口库里的委托7.交易所报盘机发给交易所说明1.SSE发回成交回报2.报盘机收到，写入数据库3.报盘BP读取到接口库里的成交回报4.写入DB-run5.客户端发起查询，查到成交结果金仕达海通快速交易网关SPX网关SPXDRTP群DRTP群DRTP群DRTP群交易中间件/DB报盘App报盘机交易所营业部1221.委托、查询等交易从营业部等渠道上来后，由SPX网关发给一级DRTP，DRTP负责消息路由和转发，发给交易中间件，DB和App在同一台机器上。然后交易中间件给出响应。2.如果是需

7、要报盘的，则交易中间件再通过DRTP转发给报盘中间件，由它发给报盘机，报盘机再发给交易所。3.成交或撤单成功后，交易所发送确认，原路返回至交易中间件写入DB，结束金仕达海通集中交易网关SPX网关SPX二级DRTP二级DRTP一级DRTP交易中间件/DB报盘App报盘机交易所营业部221.区别只是多了两级DRTP2.DRTP本身无业务逻辑，只是消息转发3.多级设计主要是考虑承载量和速率保证三级DRTP一级DRTP11.在金仕达系统内，都用c-pack协议通讯2.userdata在协议头里面3.委托号、合同号这种在协议体里面4.路径1可以通过userdata关联金仕达集中交易 大部分查询类交易都有

8、多包机制 例如，发起一个股票查询请求，查10个股票 到网络上的报文就是10次请求-响应 但业务上算一笔查询 用户希望看到首包响应时间和尾包响应时间 第一个包有FirstFlag 后面如果还有包，NextFlag会置1，同时下一个包的UserData会+1 Nextflag变成0时结束。期交所典型委托流程：NGES交易系统支持的每个合法报单，都有其状态。所有的报单状态定义如下：AllTraded（简称为AT）：全部成交，即该报单的所有数量已经全部成交了。PartTradedQueueing（简称为PTQ）：部分成交排队中，即该报单中的部分数量已经成交了，剩余的部分在报单簿中排队，等待与对手方成交

9、。PartTradedNotQueueing（简称为PTNQ）：部分成交不在队列中，即该报单中的部分数量已经成交了，但剩余的部分不在报单簿中排队，不能立即成交。NoTradeQueueing（简称为NTQ）：没有成交排队中，即该报单没有产生成交，在报单簿中排队，等待与对手方成交。NoTradeNotQueueing（简称为NTNQ）：没有成交不在队列中，即该报单没有产生成交，同时不在报单簿中排队。Canceled（简称为C）：该报单已经取消了。期交所撮合流程Crossflow解决之道Crossflow解决之道实时性快速定位准确性多段关联旁路被动方式获取流量，实时分析展示，实时告警对交易路径上每

10、个环节进行前后关联分析，通过智能故障定位算法，能够快速定位故障节点网络数据具备天然的唯一性和真实性，并具备单一时间戳来源，产生的指标准确、精确、客观Crossflow分析交易经过的路径，捕获和发现每个环节的异常或性能瓶颈，并进行多段关联分析来找到问题根源典型监控部署方式营业部Router/SwitchFW通讯机负载均衡业务中间件报盘DB营业部Router/SwitchFW通讯机负载均衡业务中间件报盘DB流量镜像实时数据解析BPC服务器（主）BPC服务器（从）集中呈现数据中心-A数据中心-B沪、深交易所流量镜像实时数据解析BPC协议支持列表证券行业序号类别协议1证券、期货上海证券交易所 新一代E

11、zOES/EzSTEP2金仕达C-PACK证券通讯协议3FIX 5.0 SP2 及以下4金证核心业务平台协议（KCBP）5金证通讯交换平台协议（KCXP）6期货交易数据交换协议（FTD）7SOA典型技术IBM WAS8Tuxedo/WTC9IBM WMQ10IBM WMB11WebLogic解决方案的核心价值将集中交易系统的复杂架构梳理清楚，建立运维基础实时的业务性能指标、实时故障定位分析和告警消除性能信息孤岛，统一网络与应用运维视角客观精确的指标数据，纯旁路监控对系统无风险架构先进、易于实施，用户可以快速落地性能管理项目BPC能为证券行业哪些系统提供服务 集中交易系统、融资融券系统、个股期权

12、系统、VIP快速交易系统、理财账户、开户平台、基金代销等 原则上，实时交易类系统，只要交互通过网络进行，均适用BPC进行监控并实现：交易性能评估 交易性能优化 重要业务保障 VIP客户差别化服务内部文档，注意保密天旦网络 版权所有 25针对高频交易，BPC能做哪些事情 在一轮低延迟军备竞赛后，各家从事HFT的机构在硬件上获取的性能优势已经微乎其微了。正如传统基础架构一样，在大规模建设后，面临的是测量和监控的问题 部署的高频交易系统是否达到了预期的性能？性能瓶颈在哪里？BPC已经具备了监控高频交易的技术能力，包括处理纳秒级时间戳 除了完成日常运维的支持，BPC还能将监控数据通过REST API提

13、供给HFT的分析工具，帮助交易商进行数据分析，掌握真实的交易执行情况，并以此为依据，制定或调整交易策略，获得更高收益率。内部文档，注意保密天旦网络 版权所有 26为什么BPC不会对业务性能发生影响内部文档，注意保密天旦网络 版权所有 27BPC对过程数据的采集BPC通过捕获端到端的网络流量，获取完整的过程数据避免了日志和数据库只记录结果数据的缺陷内部文档，注意保密天旦网络 版权所有 28结果数据过程数据对云的支持Crossflow目前能够支持监控部署在主流的云平台中的应用OpenStackCisco ACIQingCloudAli Yun通过人工或者API自动创建虚拟交换机镜像，将虚拟机之间流

14、量复制给BPC进行监控。通过业务架构梳理功能，BPC帮助用户从传统架构迁移到云；通过性能指标监控和基线建立，BPC帮助用户了解迁移到云前后的性能对比，并持续获得业务在云中运行的情况内部文档，注意保密天旦网络 版权所有 29IaaSPaaSSaaS项目实施步骤敏捷的应用性能管理用户准备信息 针对需要部署BPC监控的场景需提供：应用组件访问关系拓扑（配合SPVD验证）应用系统的服务器IP与名称对照表 应用提供服务的TCP端口 应用通讯报文格式规范、报文数据包样本 规范需要包含：区别请求和响应的标识、交易类型标识、交易返回码、交易渠道标识、交易流水号等软件部署环境要求 服务器要求项目最低配置要求操作

15、系统Linux 64位内核2.6版本推荐CentOS 6.6CPU英特尔 至强 系列支持超线程的处理器，双路8核（共16核）或更多内存64GB 或更高RAID配置RAID 5或RAID 10磁盘空间8*500GB 或更多网卡至少4个1000兆以太网接口电源双电源冗余备份浏览器推荐使用Google Chrome、Firefox 网络流量镜像要求 如果来源交换机较多，则需采用TAP设备*进行流量汇聚处理。对镜像进行合理设计，避免重复数据包应用场景与案例快速故障定位 一旦交易性能指标出现异常，立刻进行智能的故障定位，在复杂的业务路径中定位故障源头实时监控 动态服务路径图监控实时刷新典型交易系统监控案

16、例 金仕达：服务路径图监控典型交易系统监控案例 金仕达：服务路径图典型交易系统监控案例 金仕达：交易多维追踪典型交易系统监控案例 交易追踪多段关联，了解每笔交易在每一段的耗时和结果典型交易系统监控案例 单笔交易追踪，掌握单笔交易的来龙去脉典型交易系统监控案例 网络层重传导致延迟分析典型交易系统监控案例 Delayed ACK导致额外的报盘时延国泰君安用户案例BPC/NPM监控业务：集中交易、网上交易、营业部、报盘等用户收益对最重要的集中交易系统进行端到端全路径监控获得了从应用层到网络层、从外围接入到交易所报盘的可视性实现了快速准确的故障定位和告警国泰君安用户案例 业务架构梳理（金证集中交易）国泰君安用户案例 集中交易服务路径图监控国泰君安用户案例 集中交易应用性能统计监控国泰君安用户案例 交易追踪监控国泰君安用户案例 交易多段关联国泰君安用户案例 数据库操作性能