新一代集中撮合交易系统技术_王习平.pdf

数据库系统设计Database System Design电子技术与软件工程Electronic Technology&Software Engineering1961 当前国内主流交易系统特性当前国内主流交易系统是在 2000 年 2010 年间上线，运行至今，下面将分别就系统开发遵循的原则以及交易系统的特性进行阐述。1.1 遵循的原则第一个是简单化原则，不倾向非常精巧、非常复杂的设计。非常精巧的东西所需要的前提条件就比较多，在运行和开发的过程中都会带来风险，即使能构建出一个复杂的模型，运行当中也会带来潜在风险。第二个原则是要避免特殊化原则，开发团队和运行团队不可能记得这些特殊的要求，减少依赖性，自然合理地封装，尽可能减少对硬件、操作系统等的依赖。第三个是避免生疏原则，越是相对复杂、平时难以用到、掌控不够的东西，比如一些应急流程，越是要反复演练，最好是想办法纳入日常操作中，这样一旦需要真正用到时，才有可能按部就班，做到不出错。同时降低操作难度，比如我们规定系统上线、灾备切换等复杂流程的操作步骤也不能超过 10 步，尽可能地自动化，紧急时人们考虑问题的全面性总是不够的，俗话说“百密一疏”，避免遗漏的最好办法是不要百密，两密就不疏了。操作简单化也是能够日常反复演练的前提，相辅相成。1.2 核心技术特性当前主流系统具有如下的技术特性：第一个特性是开放的技术开发平台，也体现了少依赖性。在代码层面上实现跨平台性，源代码不做任何修改，就可以运行在小型机和 PC 机上，运行不同的操作系统上。完整的交易系统甚至可以在装有 Windows操作系统的一台 PC 机上运行，这个特性带来很多好处，比如说，一旦交易系统出现了问题，我们可以拿到Windows 环境中重现问题，可以非常方便地调试，提高解决问题的效率。10 年前，交易系统从小型机迁移到 PC 机上，操作系统平台也从 HP-UX 移植到 LINUX 上，跨平台的代码为顺利迁移提供了保证。交易环境移植到 PC 服务器上大大降低了硬件成本，但这不是最主要的，主要的是为开发实施节约了很多的宝贵部署时间，降低了对硬件厂商的依赖，现在部署一套 PC 版的交易环境，一周时间就够了，提高了应变能力。另外，PC 迁移也给整体性能带来 40%提升，PC 服务器高主频的 CPU 弥补了交易系统中单个线程运算能力的短板。2006 年某期货交易系统上线的时候，大概每秒有 7000-8000 的报单能力，迁移到PC环境后实测处理能力达每秒12000笔报单左右。第二个重要的特性是可精确重演机制，构建完全精确重演的分布式体系架构，采用排队机制，实现所有业务的单源输入，而所有的业务处理都能够基于该单源输入进行分步处理，最终得到确定处理结果。值得注意的是，这要求所有系统控制参数都要归入单元输入中去，才能保证可以精确的重演。支持完全重演的目的包括业务和技术两个方面。在业务方面，通过完全重演，可以精确地了解交易过程中的某个时刻，整个交易引擎的状态，对于进行事后的核查，保障交易公平性，有着至关重要的作用。在技术方面，通过重演，我们可以实现多引擎并行工作，提高系统的可靠性，消除单点故障，同时，这也是灾备系统运行的基础。另外，利用这个特性新一代集中撮合交易系统技术王习平（华鑫证券有限责任公司 上海市 200122）摘要：本文对新一代集中撮合交易系统技术发展路线做出了详细阐述。对当代交易系统的特性进行了详细分析，交易系统面向二级资本市场，社会影响大，安全稳定运行高，采用简洁化、通用化和熟练化三原则。总结出系统的开放性、可重演，高性能以及高可维护性等特点，同时指出系统面临的一些响应时延，系统处理能力，指令丰富性和业务多样性方面与国际先进系统之间的差距，以及越来越高的安全运行要求方面的挑战。给出了新一代集中撮合交易系统的技术发展路线图和研究实施方案。关键词：PC 机；撮合交易系统；低时延；容灾技术数据库系统设计Database System Design电子技术与软件工程Electronic Technology&Software Engineering197还可以进行自动化回归测试，让变更后待上线的交易系统重演历史上真实的交易流水，然后比对交易处理结果，可保证原有业务处理的一致性和正确性。第三个特性就是为了提高集中撮合交易系统的性能，运用自适应 UDP 可靠多播通讯技术，构建交易系统的核心信息总线，并使用了多通道互备、自适应网络性能控制、自动压缩和信息压紧等机制，保障了信息的高速可靠有序送达，在 100Base-T 网络上，可以达到每秒传送 40000 个 300 字节的消息，网络的使用效率达到了 95%以上。第四个重要特性就是多业务主机同时工作，互为备份和自由加入的集群容错可靠性保障机制，不仅达到了无单点故障的效果，做到双源/双发/双收，还实现了零切换时间，即任意业务主机停止工作，都不会对外部的业务服务有任何影响，而且可以在业务进行的过程中，根据需要自由地恢复因故暂停业务主机的工作，使系统重新回到停机前的高可靠性保障水平。另外一个重要特性是系统数据和状态都在单一的输入流水中，这是可靠精确重演机制保证的，可以通过转发、复制流水来监控系统状态和开展一些其他的延伸服务。这也是实现灾备的基础，将主中心输入流水实时复制到备中心，当主中心发生灾难时，备中心可基于从主中心复制过来的输入流水重演，恢复到主数据中心灾难前的断点，从而完成主备切换。交易所等金融机构都在两地建立了三个数据中心，同城灾备采用热运行的模式，同城两个中心交易前置同时对外提供服务，异地中心采用跟随热运行的模式，强调热运行模式，是为了保证备份中心的可用性，将备份中心的健康状态纳入日常监控，否则，一旦发生切换就不能保证灾备中心是不是真的准备好了，是不是真的能够立刻提供服务。这也是避免生疏原则的体现。过去几年多次进行了异地灾备切换的实测，切换时间大概在 10 分钟以内。还有个特点是集中的系统控制台，统一控制两地三中心版本发布和运行操作。每个中心的组件超过百个，三个中心数百个组件，如果没有一个统一的控制台的话就会比较麻烦。控制台也坚持少依赖原则，所有功能都基于操作系统的基本命令实现，避免控制台本身成为几个中心系统运行风险点。最后一个特点是技术监控。在三个数据中心各自部署了一套监控系统，每套监控系统都同时监控三个数据中心系统运行情况。1.3 核心性能以一个期货交易所为例，目前系统实测性能为每秒处理 12000 笔报单，响应时间在 35-40 毫秒之间，整个系统在峰值上达到过 25000 笔，但是这个处理能力不能持续。实测环境主要为：Dell R710 服务器，两路 2.5G主频 CPU，144G 内存，RHEL 5 操作系统，1G 以太网，使用 iptables 防火墙策略。处理能力提升一直是期货交易所头疼的问题，因为期货行业要求在交易中实施风控手段比较多，比如限仓管理、资金校验，实时监控会员的资金能不能支持报单，会员和客户是否超仓，这些复杂规则不但本身消耗处理能力，同时制约了并行处理，形成了交易系统的性能处理瓶颈。实际生产中该交易所处理峰值为 3800 笔报单/秒，目前交易系统的性能应能满足实际需要。2 面临挑战现在系统面临的一些挑战主要是在安全和效率的平衡上面。安全方面主要有技术和业务两个角度，从业务角度看，风险防范措施日益增多，新品种不断推出，监管要求越来越严格；从技术角度看，可靠性、可用性的要求也是越来越高。效率方面，现在主要是处理能力和响应时间，还有一些提升市场效率业务创新，另外从运维角度讲，要坚持开放的平台，坚持快速部署的原则也是效率因素。从交易系统设计考虑核心因素上讲，目前国内外是存在差别的，国际上关注度排序为：响应速度，处理性能（大于 2 万笔报单/秒），容量以及可靠性。而国内关注度排序则是：可靠性，容量，处理性能以及响应速度。比如，目前国际上为了满足机构投资者的需求，响应时间是 0.25 毫秒-1 毫秒，而国内则没那么高要求，1秒内回报即可。国内更多把可靠性放在前面，由于散户众多，容量也是优先考虑的因素，而会员对于交易所的响应时间不是那么关注，因为不存在跨市场的竞争。但是，从长远来说响应速度也是值得考虑的因素之一，未来交易所竞争和同一品种跨市场套利是我们不能回避的问题。下面简单分析一下国内交易系统和国际主流交易系统差距。一是指令相对单一，虽然国内交易系统也前瞻性地考虑了一些复杂的指令，但基于性能和其它方面的数据库系统设计Database System Design电子技术与软件工程Electronic Technology&Software Engineering198顾虑使得这些指令都没有放开；二是响应速度同国际主流交易系统的差距在一个数量级左右；三是系统吞吐量不足支持我国庞大的投资需求；当然这也是目前行业里不关注它的结果。四是监管机构对安全可靠性要求越来越高，比如交易终端不能超过 3 分钟。3 新一代交易撮合系统的研发目标3.1 高精度度量机制增加跟踪机制，把所有的处理指令里面都增加跟踪号，精确知道每个指令在每个环节花费了多少时间，从而为进行系统进一步优化提供依据。遵循相对度量，分层细化的原则，尽量减少对处理单元的干扰。为后续优化降低处理延时，提高系统吞吐量，缩短灾备切换时间奠定基础。如图 1 所示。3.2 降低处理延时和提高处理能力更快的响应时间意味着更好的客户满意度，随着程序化交易在国内的发展，响应时间的快慢更是成为争取客户的关键因素。为了提高客户满意度，应对程序化交易的趋势，加快交易响应时间势在必行。在压力较低时（真实交易日的压力情况都可以认为是较低的），目前实测的交易响应时间约为 2ms，这个响应时间计算是从用户发出报单到用户收到成交回报来计算的。加快交易响应时间需要从两主面着手解决，一方面是减少因阻塞调用而占用系统时间、别一方面是加快xtp 协议的驱动周期。下面分别进行分析：（1）阻塞调用：目前交易系统会造成阻塞而影响响应时间的地方有两处，分别是：select()阻塞：在等待 IO 事件时，会设置超时等待；但当无 IO 事件时，相当于是在超时时间内被阻塞了。sleep()阻塞：在指定的 sleep 时间内被阻塞。所以针对以上两种阻塞，需要分别加以处理、达到需要唤醒时随时可以唤醒。（2）XTP 协议的驱动周期：目前 XTP 协议的驱动周期是 10 毫秒一次，因在驱动 XTP 协议之前已经做过图 1：处理跟踪机制数据库系统设计Database System Design电子技术与软件工程Electronic Technology&Software Engineering199select（）调用，所以可以去掉周期驱动、直接每次都调用即可。当前交易系统研发的主要目标是进一步提高性能，降低响应时间的同时将处理能力定在 3 万笔报单/秒左右，响应时间希望控制在 1ms 以内。进一步提高可靠性，在单中心抗单点故障的基础上，考虑提升应付双点故障能力，改变只有主数据中心整体损坏才会切换到备用中心的原则，当一个中心出现双点故障的时候，尝试考虑是不是能切到备中心去，这样做有一个前提，就是切换要做到非常容易和可靠，必须在几分钟内搞定。切换不能带来风险，否则将得不偿失。基本框架上还是坚持延用以前的可靠重演机制，做一些局部调整，如减少前置机重演时间。进行提升处理能力和缩短响应时间的研发，如缩短流水线，增加并发度，把一些上下文无关的东西拿出来单独运行。针对主要的处理过程尝试进行一些并行处理，拆分处理过程，并行处理子过程。大部分情况下，这多个子过程之间未必有关联性，可以并行处理，处理后进行关联性判断，如果存在关联就作废处理结果，该过程退回串行重做。当然这样做是不是真正能达到预想效果，还需要进一步验证。还有，总线也会进一步优化，减少日常发送的数据量。总线的双源/双发能抗单点故障，但也带来传输压力，占用宝贵的带宽资源，尽管目前带宽不是系统的瓶颈，当其它环节完成优化性能得到提升后，就该考虑传输问题了，必须将双源/双发改造成动态负载均衡模式，将带宽资源利用提升一倍。另外，也会考虑尝