【交易技术前沿】轻型化交易系统时延分析 / 黄寅飞

【交易技术前沿】轻型化交易系统时延分析 / 黄寅飞

摘要 ：轻便高效交易系统（Light Trading Platform，简称 ：LTP）是国家科技支撑计划《证券核心交易系统研发》课题（课题号 ：2012BAH13F04）的交付成果，于 2015 年 4 月通过国家验收，达到吞吐量 10 万笔／秒、交易时延小于 1 毫秒的技术指标。LTP 引入内存复制技术，在保证高吞吐和高可用性的基础上，时延指标相比现有系统 [1]提升两个数量级。LTP 基于 PC 服务器集群搭建，选用 Linux 操作系统（RHEL 6.3，64 位）。围绕时延建模分析，设计用于时延数据采集分析的监控架构。本文重点对轻型化交易系统时延数据进行试验分析，提出进一步提升性能的优化方向。

1. 技术架构

证券处理的全业务流程如图 1 所示。LTP 关注的是业务流程中由交易所负责的部分，重点解决实时撮合处理的时延和吞吐量问题。相应地，LTP 架构如图 2 所示，主要包括通讯网关 （ Communication Server，简称CS）和交易主机 （ Trading Cluster，简称 TC）两块内容。LTP集成基于 TCP协议的 ZeroMQ消息中间件[2]作为通讯层，以实现多对多的广播订阅通讯方式。集群主机按照产品集合（instrument SET , 简称：SET）进行分区，以支持水平扩展。图 2 中 CS 上 robot 进程负责模拟报单。TC 上router 进程负责消息路由，matcher 进程负责撮合处理，main 为主撮合线程，csq 为定序线程。TC 构成集群，基于 Paxos 算法 [3] 实现主备机订单序号同步。LTP 监控架构与交易架构通过 libmoni 监控探针库以低耦合方式相连接，见图 3。每台 TC 和 CS 上均安装有 Redis 数据库 [4]，用以存放实时监控数据。监控主机上安装有 Redis 客户端，可离线抓取各台主机的监控数据并整合放进本地的 MySQL 数据库。监控主机使用Python 进行数据分析 [5] 并基于 MatplotLib 库进行可视化展示。

2. 时延建模

2.1 时延定义

交易时延指的是交易订单从发出到收到响应之间的时间间隔。参照 Cinobber 公司白皮书 [6]，定义端到端（End-to-end）、 门 到 门（Door-to-door）、 撮 合 器（Business logic）三个时延指标，见图 4。交易所关注的交易时延指的是门到门时延，即消息从 CS 到 TC 再回到 CS 的处理时延。为进一步分析交易时延构成，设置一系列采样点：t0,t1,……tn-1，定义分段时延：

2.2 时延模型

LTP 系统中订单生命周期如图 5 所示。设置 8 个采样点，其中 T1、T7 为 CS 到 TC 间网络时延，T2、T6为 router 到 matcher 进程间通信时延，T3 为主备机定序时延（包含两跳网络时延），T4 为撮合器中 csq 到main 线程间通信时延，T5 为撮合业务处理时延。LTP交易时延为：T0,7=T1+T2+……+T7 （4）因 t0,t7 采样点位于 CS 主机，t1 到 t6 采样点位于 TC 主机，不同主机上的时钟难以做到微秒级同步。 T1、T7 两段时延无法直接计算，而需采用间接计算公式，如下：T1=T7=(T0,7 - T1,6) / 2 （5）

2.3 吞吐量优化策略

在保证时延指标的基础上，需要采取优化策略保证吞吐量指标达标。分析交易时延构成可知，网络通信、进程／线程间通信、定序均可并行执行，只有针对同一SET 多条订单的撮合业务处理必须串行执行。假设 T5为 100 μ s，则该 SET 的吞吐量上限为 10000 笔／秒。假设对撮合业务处理逻辑调优将 T5 缩短 50%，交易时延 T0,7 只能提升 7%，但吞吐量可提升一倍。可采取多机扩展策略，在时延指标大致不变的同时，通过增加交易主机线性提升吞吐量。为充分利用主机的多核计算能力，可采取多 SET 优化策略，通过增加在单台交易主机上的撮合进程数量大幅提升吞吐量。

3. 试验与分析

3.1 环境准备

试验环境为千兆以太网，三台 CS 为 HP DL380p（PC 服 务 器，32 核，128G 内 存 ）， 四 台 TC 为 IBM x3850（PC 服 务 器，64 核，128G 内 存 ）。 设 置 8个 SET，采取一主两备配置，每台 TC 上部署 2 个主SET、4 个备 SET。为接近真实场景，使用工具生成由 100 万账户和100 支产品构成的一亿条模拟持仓。使用工具围绕 40支产品和 1 万账户生成 480 万条模拟订单，每台 CS 负责输入 160 万条订单。订单价格、数量字段随机生成，平均分布在 8 个 SET。订单消息长度为 154 字节。CS 采取匀速报单方式，每隔约 30 微秒（μ s）向 TC 发送 1 笔订单。

3.2 试验结果与分析

3.2.1 时延曲线与分布

3 台 CS、4 台 TC 总计 8 SET（简称 3 对 8）配置下，输入 480 万条订单，打单时长约 46 秒。结果为：吞吐量 10.5 万笔／秒，平均时延 637 μ s。打单期间的时延曲线（取 CS1，SET1），如图 6 所示。可用 Zoom 按钮对局部放大，甚至可以放大到每一笔的时延，如图 7 所示。观察时延曲线，可以看到部分区段时延波动较大，预期可通过消除毛刺方法进一步提升时延性能。时延分布（取 CS1，SET1）如图 8 所示。统计可得，95％的订单时延在 790 μ s 以内，99% 的订单时延在991 μ s 以内，100% 的订单时延在 3242 μ s 以内。

3.2.2 时延构成分析

如 3.2 节所述设置 8 个采样点。3 对 3 配置下， 输入 270 万条订单，统计时延构成，其中 T1、T7 使用公式（5）计算而得，见表 1。

交易时延的分段构成，如图 9 所示。其中网络时延（T1、T3、T7，共四跳）占 75％，进程／线程间通信时延（T2、T4、T6）占 18％，撮合业务处理时延（T5）占 7％。从时延构成来看，网络时延所占比例最高，预期可通过改造万兆网络和使用低延迟网络设备加以提升。进程／线程间通信时延所占比例较高，预期可通过替换相关 IPC 组件加以提升。撮合业务处理时延所占比例最低，但正如 3.3 节所述，该段时延对于吞吐量提升意义重大。

3.2.3 吞吐量 vs 时延

首先试验主机的线性扩展能力。CS 保持为 3 台，TC 分别按照 2 台、4 台进行部署（每台 TC 部署一个主 SET），试验吞吐量和时延的最优组合。结果见表 2。

3.2.4 批量打包策略

4. 小结

LTP 为交易系统轻型化提供了试验平台，允许组合各种通讯协议、主备策略、并行策略进行算法试验。本文对轻型化交易系统的时延模型进行了分析，并给出了进一步优化的方向。

参考文献

[1] 黄寅飞，黄俊杰，王泊，等 . 证券交易系统中的事务恢复方法 . 计算机工程 . 2010, 36(24):241-243.[2] Pieter Hintjens 著，卢涛，李颖译 . ZeroMQ：云时代极速消息通信库 . 2015[3] 黄晓东，张勇，邢春晓，等 . 一种基于 Paxos 算法的证券交易系统内存复制方法研究 . 计算机科学，2012，39(12)[4] 李子骅 . Redis 入门指南 . 人民邮电出版社 . 2013[5] Wes McKinney 著，唐学韬等译 . 利用 Python 进行数据分析 . 机械工业出版社 . 2014[6] Cinober 公司 . A Cinnober white paper on: latency. 2009

作者简介

黄寅飞：上海证券交易所技术开发部执行经理。2002 年博士毕业于清华大学计算机系。主要研究领域为低时延交易、大数据处理。在国内外刊物发表论文 10 余篇。