恒生极速交易系统相关的技术架构与应用发展 朱金奇

Razor

2019/10/19 发布于 技术 分类

文字内容
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纳秒