恒生极速交易系统相关的技术架构与应用发展 朱金奇
2020-03-01 209浏览
- 1.恒生极速交易系统相关的技术架构与应用发展 朱金奇 恒生电子股份有限公司 研发中心 高级技术专家
- 2.自我介绍
- 3.自我介绍 朱金奇 恒生电子股份有限公司 研发中心 2011年加入恒生电子 目前负责恒生高性能中间件平台的研发与推广，平台专注于低延时、高可用等业务场景 证券 期货 信托 交易所 银行 基金 恒生电子 保险 新兴 行业
- 4.目录 1.为什么需要极速交易 2.恒生极速交易系统发展的重要时间节点 3.恒生极速交易系统设计遇到哪些问题？如何解决 4.怎样达到纳秒级的速度
- 5.为什么需要极速交易？ l 交易所撮合原则：价格优先、时间优先 l 高频策略交易在市场的交易份额逐年提升
- 6.交易场景：Tick行情报价 突发大量卖单 速度快的交易者可以立即 521.5卖出开仓并成交 速度慢的交易者521.5卖出 开仓，挂在卖一价，后续没 有成交机会，错失交易时机
- 7.交易场景关注哪些时间？ Ø 客户端响应时间 Ø 订单上行时间 Ø 成交/行情 下行时间 策略终端 金融机构 订单系统 交易所 撮合系统
- 8.我们是怎么去做的？ Ø 客户分类 Ø 业务分类 Ø 系统分类 专业投资者 普通投资者 极速业务 普通业务 行情、成交主推 行情、成交轮询 内存交易系统 数据库交易系统
- 9.恒生极速交易：从毫秒、到微秒、再到纳秒的飞跃 NST纳秒级极速交易 2017年 缓存技术、网络延迟、业务逻辑优化等 2013年 第二代内存交易UFT2.0 可重演，核心节点多活 第一代内存交易UFT1.0 2011年 内存技术、核心交易，开发工具、主备 2008年 期货VIP交易系统 独立通道、独立系统委托成交推送
- 10.第一代UFT（Ultra Fast Trading）总体架构 订单服务处理耗时从 20ms降低到300us以内 客户端响应时间 <5ms
- 11.第一代UFT遇到了哪些问题 • 开发：新业务开发周期长，开发难度高？ • 性能：客户数量多，交易量增大，查找性能变慢？ 客户风控风控条目增多，延时就变大？ • 管理：数据全在内存中，管理不方便？ • 运维：问题排查很麻烦？
- 12.怎么让开发更加快速，程序更加稳定 业务 流程 业务 流程 业务 流程 业务 流程 业务 流程 业务 流程 业务 流程 应用层扩展 业务模型 u专门针对金融行业的内存数据库，支持统一的访问API，业 务与数据分离，业务开发人员不需要关心内存数据的实现 业务 流程 元数据 索引 对象 u 支持专门的开发工具快速开发业务，提高系统稳定性，插 关系 开发工具 开发套件 件化开发，业务功能可任意组合、扩展 统一的开发API 事务管理 日志管理 数据持久化管理 基础架构
- 13.开发工具帮我们做了哪些事情？ 提高开发效率 l 原数据管理：标准字段、标准错误号、数据字典、内存对象等 l 接口管理：服务接口、函数接口 l 基础数据管理：系统配置参数 降低开发难度 l 业务伪代码代码开发（系统宏：[插入记录]、 [修改记录] 等） l 禁止关键字：new/malloc、goto等 l 集成pclint等静态代码检查工具 l 死锁分析检查 内存表结构设计 接口管理 元数据管理 伪代码翻译 规范开发过程 l 一键生成代码、上传、编译、运行、伪代码调试 l 自动化测试对接，自动分析修改影响到的业务接口 l 业务逻辑分层（逻辑层、原子层）
- 14.UFT开发工具帮我们做了哪些事情？
- 15.数据量大了性能还能否保持稳定？ ü 交易单元，数据预先关联（1：1，1：N，N ：1，N ：N） ü 主体呈树状组织，缩小查找范围
- 16.风控条目变多了，延时就变大？ ü拆分 ü并行 ü汇总
- 17.数据全在内存，怎么管理？ 运维管理客户端 其他客户端 SQLite Virtual Table 是一种自定义的扩展，允许用户通过代码定制表的数 据结构和数据内容 对于数据库引擎，它和普通表一样，允许进行大多数 的sql操作 标准SQL语句增删改查 业务请求 接收外部请求 Sqlite VTable 业务模块 内存数据库访问API接口 数据+索引+关联关系
- 18.问题怎么排查？ 1. 按需记录 客户端 2. 旁路记录 接入前置（旁路） 按需记录关 键信息 请求包/应答包 旁路日志环境 记录日志 log 正式交易环境 交易节点
- 19.第一代UFT解决了这些问题 高性能 易管理 易开发 高可用 封装内存数据库，支 持事务、索引，业务 内存中处理 通过标准SQL进行管 理，采用灵活的日志 方式排查问题 开发工具开发业务，规 范业务代码，提升开发 效率和程序稳定性 交易核心节点主备 部署，实时同步， 支持秒级切换 新三板、港交所 交易所场景需求 核心节点(撮合)可重放
- 20.排队机保证输入的顺序一致 消息 消息 消息 …… 消息[3] 消息[2] 消息[1] n将所有业务请求按时序、优先级进行编排，确保各核心数据处理一致 n可以进行业务反演，用于交易服务器宕机后反演数据恢复，升级时也可进行数据核对
- 21.可靠组播保证消息有序可靠传输 n采用基于组播协议，增加处理同一消息的组件对性能 无影响 同一主题 发布者A 发布者B 订阅者A 订阅者B n采用可靠、有序的数据发布/订阅模式，简化系统间 耦合程度 n支持一对多和多对多模式，订阅收到同一主题多个发 布者发布的数据后过滤 n采用A/B网，发送者在发送消息的时候，向A网卡发送 一次，同时向B网卡发送一次，在硬件上保证通讯可 靠
- 22.第二代UFT总体架构 n主排队机对业务处理请求进行排队 n依靠可靠组播，多个撮合核心同时订阅并且排队机的消息 n提供差异化的实现，查询请求无需排队
- 23.速度是否可以更快一些？ 选择方案： 复杂的交易所API处理和交易核心采用 CPU加速。重复性强的周边策略、行情、风控采用 FPGA加速 FPGA加速 CPU加速 行情处理； 交易核心； 事前风控； 交易所API调用； 周边策略平台；
- 24.服务器三种体系架构 I/O N U M A 服 务 器 I/O 内存控制器 内存控制器 本地存储器 本地存储器 CPU n CPU n 内存 I/O NUMA内部 互联模块 内存 I/O 内存控制器 内存控制器 本地存储器 本地存储器 CPU n SMP 对称多处理器结构 CPU n 内存 内存 SMP节点 I/O M P P 服 务 器 内存控制器 本地存储器 本地存储器 CPU n CPU n 内存 I/O MPP节点 互联网络 内存 I/O 内存控制器 内存控制器 本地存储器 本地存储器 CPU n SMP节点 NUMA 非一致存储访问结构 I/O 内存控制器 CPU n 内存 内存 MPP 海量并行处理
- 25.CPU内部缓存结构分析 处理器1 延迟时间 (ns) 存储大小 L3 寄存器 <=1 几字节 L2 L2 L1d ~1 几十K L2 ~10 几百K L3 ~40 几M 主存 ~100 几G 核心2 L1I 存储类型 L3 核心1 L1D 处理器2 L1D 核心3 L1I L1D 核心4 L1I L1D L1I
- 26.降低访存延迟—考虑物理架构 A 充分考虑主机NUMA架构 B 充分考虑缓存和CPU核心的关系
- 27.降低访存延迟—提高缓存命中率 Ø连续 vs 离散 Ø数据结构的定义和业务访问顺序一致 Ø某些数据结构按照缓存线对齐原则 Ø针对业务特色组织数据结构
- 28.什么样的查找算法更快？ 无需查找的“查找算法”就是最快的查找算法！
- 29.低延时网卡机制分析 低延时网卡优化 User Space User Space Ø 内核旁路(Kernel bypass) APPLICATION APPLICATION Ø 用硬件替代软件(offload) SOCKETS SOCKETS OpenOnload switch Kernel Domain TCP/IP STACK 网络延迟时间 Network Driver 1000M网络 10G网络 VNIC VNIC 10GbE MAC 低延时网卡 40 — 100 us ~ 15 us 2.0 — 4.3 us
- 30.恒生第一代纳秒级交易产品：期货NST 交易系统内部时延：NST交易核心处理时延< 交易所 组播 / FPGA加速 CPU加速 NST 极速交易 极速行情 策略 300纳秒
- 31.
- 32.
