frankk
作者frankk2019-09-30 14:48
技术总监, 券商

证券企业如何构建高可用、弹性的集中交易系统基础架构交流总结

字数 6427阅读 2351评论 0赞 5

集中交易系统是证券行业的核心系统,券商业务的波动性比较大,突发的高并发业务场景给交易系统带来了巨大压力,如何构建高可用、高并发、弹性的分布式的基础架构,是每个券商必须面对的。目前恒生、金证、金仕达集中交易系统软件在应用层实现了分布式部署,后台数据层主要使用的是 Oracle 、 Db2 、 SQLserver 数据库,虽然已经实现读写分离,但由于处理逻辑的强关联性,整体系统架构能否应对高并发系统压力,能否解决应用层和数据层的性能瓶颈问题,能否弹性扩展、按需分配、扩展时对业务是否能无影响非常关键。

在本次交流活动中, twt 邀请到了多位券商专家和浪商技术专家,来对证券企业如何构建高可用、弹性的集中交易系统基础架构进行交流探讨,重点帮助大家进行新一代集中交易系统基础架构优化改造。

交流精华

1 、 集中交易系统从Power7 主机迁移到Power9 ,需要做哪些方面的优化才能发挥 Power9 最佳性能?

回复: dawey 技 术经 理 , 光大证券股份有限公司

1 、选择测试基线( OS 、 DB 、应用)

1 )不同的 Power 芯片都有对应的 AIX 版本,确定合适的操作系统

2 )根据操作系统选择对应的数据库

3 )确定应用版本

2 、确定测试样本

用相同的样本进行不同组合测试,确定最优组合和性能基线

3 、优化主机、存储、 AIX 、 DB 、应用参数

1 )主机调至最大性能模式

2 )数据库参数优化

3 )应用优化

每次调整与基线进行对比,以 “ 不求最好,但求更好 ” 的心态,不断优化提升

通过以上不断循环,就能不断把 Power9 的性能挤压出来。

在最求性能最大化时,安全、稳定永远是第一位的!

2 、 集中交易系统多活架构中数据同步是如何实现的?

在集中交易系统多活架构中,各多活节点之间的数据同步是通过 IP 传输,还是通过 SAN 传输,各有什么利弊?

回复 1 、: dawey 技 术经 理 , 光大证券股份有限公司

后台数据同步:

1 、基于数据库 (占多数)

1 )基于 Oracle : DSG 、九桥、 ADG

2 ) DB2 : hadr , CDC

3 ) SqlServer : AllwaysOn

2 、基于 SAN (对链路要求高,早期多,现在少了)

1 )通过 IBM SVC 实现数据复制

2 )存储底层负责( PPRC 、 SDRF )

回复 2 : frankk 技术总监 , 券商

光大 证 券的兄弟回复的很 专业 ,常 规 的数据复制技 术 基本都提到了。

证券行业多活架构,节点之间的数据复制技术主要还是通过 IP 基于数据 库 日志的同步复制技 术 , 优 点是:( 1 )运 维简单 方便,效率高,同步的 颗 粒度小,便于人工控制和及 时 故障 处 理。

( 2 ) 证 券行 业 常用的基于第三方数据 库 复制 软 件, DDS 和 DSG.

( 3 )目 标 端数据 库 是活 动 ,可以用来做数据 查询 分析 统计

基于 SAN ,存 储 底 层 等的数据复制,遇到故障 处 理起来都比 较 复 杂 ,目 标 段都是非活 动 的,利用效率低。

回复 3 : 曾刚 系 统 架构 师 , 浪潮商用机器企 业云创新中心

各有利弊:基于存储拷贝的复制技术管理比较简单,但是同步情况下性能大概会下降 20~30% ,而且对距离和带宽要求都比较高;如果基于软件逻辑复制,带宽要求比较低,目前证券公司大多采取这种复制方式。

3 、 集中交易数据层如何进行弹性扩展?

目前集中交易系统的数据层基本都是依赖传统数据库( oracle 或者 sqlserver ),请问这种情况下数据层有什么办法进行弹性扩容吗?

回复 1 : dawey 技 术经 理 , 光大证券股份有限公司

我司的集中交易系统的数据一般采用分库方式存放,交易库一般保留 3 个月的数据库,其余存放在历史库。历史库又分 3 年内的和 3 年以上的。

交易库重点是确保快速读写,备份和恢复耗时短,一般存放在闪存存储,访问频繁。

历史库( 3 年内), 存放在闪存存储,访问一般。

历史库( 3 年以上), 存放在 HDD 存储,较少访问。

题目的 “ 集中交易数据层如何进行弹性扩展? ” 不知具体指什么?

对于数据库来说,容量是很大的。 Oracle 数据库的表空间数据文件容量与 DB_BLOCK_SIZE 有关,在初始建库时, DB_BLOCK_SIZE 要根据实际需要,设置为 4K,8K 、 16K 、 32K 、 64K 等几种大小, ORACLE 的物理文件最大只允许 4194304 个数据块(由操作系统决定),表空间数据文件的最大值为 4194304×DB_BLOCK_SIZE/1024M 。

即:

4k 最大表空间为: 16384M

8K 最大表空间为: 32768M

16k 最大表空间为: 65536M

32K 最大表空间为: 131072M

64k 最大表空间为: 262144M

回复 2 : michael1983 技术经 理 , 某证 券

传统数据库要想实现弹性扩容,非常有难度。

硬件层面相对简单, scale up 或 scale out ,相对简单。

但整体层面,还是比较困难。启停数据库,存储空间重新分布,都是难免的。

我觉得与其考虑数据层,还不如更多的考虑应用架构,弹性、分布式架构,对底层依赖小。

4 、 Power9 架构对比X86架构,支撑券商集中交易系统有些什么优势 ?

回复 1 : dawey 技术经 理 , 光大证券股份有限公司

1 、目前 五大柜台软件提供商:恒生、金证、 顶点 、新利、金仕达, 占据国内 95% 以上市场份额。

1 )恒生 UF2.0 (后台数据库为 Oracle RAC ,后台一般为: Power 主机 +EMC vmax 存储,现在存储趋势为闪存,如 IBM FS 系列)

2 )金证新一代 (后台数据库为 SqlServer ,后台一般为: x86 服务器 + 闪存,如 IBM FS 系列)

3 ) 顶点 (后台数据库为 Oracle )

4 )新利

5 )金仕达 (后台数据库为 DB2 ,后台一般为: Power 主机 +IBM FS 系列)

其中, 恒生 和金仕达都是采用大集中模式,金证采用的是区域集中。

顶点和新利不是很了解,在此不做评论

2 、 Power 的特点

1 ) Power 架构具备大规模 SMP 系统性能,其可以保障内存在访问任意一枚 CPU 时速度是一致的。而 x86 则是采用了 NUMA 结构, CPU 和内存分区,这就意味着在访问自己部分的内存速度飞快,而其他部分内存速度要慢不少。也正是因此, 4 路以上的 x86 服务器相对较少。

2 )硬件方面, Power 系统在可靠性、可用性和可维护性的方面的出色表现使得 IBM 从芯片到系统所设计的整机方案有着独有的优势。 Power 架构的处理器在超算、大型企业的 UNIX 服务器等多个方面应用也十分成功。

3 ) 在软件方面,其专用的 AIX 系统在稳定性、软件方案集成度和厂商技术支持能力方面都要更强。由于用户选一平台主要看软件需求,一般对数据保护和 7*24 小时不宕机等有所要求, power 架构的稳定性和运维等方面相对更优。

所以对应不同的集中交易模式会有不同的选择,选择合适的才是关键。

采用全国大集中模式的大券商,一般后台主机都会采用 Power 系统。

回复 2 : 曾刚 系 统 架构 师 , 浪潮商用机器企 业云创新中心

POWER 一直以来以高性能、高可靠性优势,在金融行业核心系统保持垄断地位。券商的集中交易系统,对性能要求非常高,对稳定性的要求甚至超过银行,因此, POWER 是首选。

现在 IBM 已经将 POWER 指令集开源,又在国内跟浪潮成立了合资公司,合资公司负责研发、生产、销售基于 POWER 的国产服务器,现在的 POWER 架构服务器比 x86 更 “ 国产化 ” 。

5 、 券商集中交易系统弹性基础架构的实现路径? 弹性管理机制?

回复 1 : frankk 技术总监 , 券商

集中交易系统的基础架构弹性来自于两方面:

  1. 主机的纵向扩容,比如 power9 ,可以采购 88C ,只开通 44C ,遇到性能压力时,启用临时授权,恢复到 88C 的处理能力,提升系统处理能力。
  2. 主机横向扩容,增加主机数量,从而提升系统处理能力,这依赖于集中交易系统的架构,首先交易系统要支持多中心的架构模式,例如恒生公司的 UF20 集中交易系统,可以按照分支机构客户或者客户业务类型(普通客户、两容客户、高频交易客户)等分多中心处理。

回复 2 : dawey 技术经 理 , 光大证券股份有限公司

frankk 已经把关键点都指出来了,我补充一下。

实现集中交易系统弹性基础架构主要有以下方面:

主机层面:

提升 CPU 主频( power7 升级 Power8 、 Power9 )

提升 CPU 数量(激活 32 、 48 、 64 。。。)

应用层面:

拆分应用,把账户、查询、登入、交易进行拆分,降低读写比

数据层面:

使用内存数据库

数据分库存放

优化索引数量(减少索引数量)

6 、 如何有效对集中交易性能容量进行管理?

由于证券市场的特殊性,在选型设计时如何评估设计架构的性能容量?面对随时而来的爆发式行情和交易量,集中交易系统从基础架构层面可以有哪些方案进行快速响应与应对?

回复: 曾刚 系 统 架构 师 , 浪潮商用机器企 业 云创新中心

性能容量评估通常有三种方式:

1 、测试

2 、参考同行业案例

3 、根据现有架构、机器配置等,推算

POWER 服务器有强大的垂直扩展能力,面对牛市行情, CPU 可以临时激活,也可以通过 CPU 资源池技术,把其他服务器上 CPU 资源转移到主生产服务器。

7 、 交易系统的本地存储是都用双存储 ?

在高可用环节,考虑了存储的双控双电源,但存储本身还是单点,请教下是否考虑双存储做 asm 的 nornal 模式保护,是否有什么缺点。

回复 1 : frankk 技术总监 , 券商

业界主流模式的集中交易系统基础架构模式:双(多)主机 + 双交换机 + 单存储;其中存储的单点故障通过启用本地备份系统来做保障。 方正证券曾经使用:双主机 + 双交换机 + 双存储模式,但后来新一代集中交易系统上线时,方正证券已经抛弃了双存储的架构。

作为证券公司最核心的交易系统,券商对存储的配置要求都非常高,一般均使用高端存储,目前高端存储技术已经非常成熟,双控(甚至四控制器)双电源的应用,使得存储本身的故障率极低(硬盘故障除外),采用双存储会进一步增加故障点,对于两台存储之间的切换,需要更高的技术,意义不大。

针对运维工作来说,简单就是美!简单高效的架构,就是最好的架构,存储故障直接切换本地备份系统。

回复 2 : murenxiang 技术经 理 , 宏源 证券

核心架构要求简单、运维容易管理

建议主备节点分别挂存储,数据用数据库级别同步软件

回复 3 : colins 系 统工程 师 , 金融行业

  1. 也有相当一部分采用在 oracle asm 层使用 2 份存储实现高可用。这种的维护和管理工作在数据库上,而且两台存储的性能要接近,要不然很容易造成木桶原理,降低数据库的性能。

8 、 对于集中交易基础架构环境的监控 ?

券商集中交易基础架构平台涉及众多型号的设备与产品。如何能有效的统一的直观的对基础架构进行监控,以便及时了解当前系统的运行情况与性能表现。

回复: frankk 技术总监 , 券商

证券行业基础平台监控:主机、数据库、网络、操作系统,市场上的都有相应的监控系统,

目前各大头部券商,都在做监控的整合,或者已经上线集中监控系统,通过统一集中的监控平台和各相应的专业监控系统进行对接,从而实现统一监控、统一展现,集中管理。国外的大厂也有类似的产品。

总的来说,集中统一的监控系统实现起来,比智能运维系统要容易的多。

9 、 集中交易系统遇到突发状况进行灾备切换 ,大家采取什么措施来尽量减少切换过程中业务的流失?

遇到异常情况,灾备切换过程中,业务丢失是难免的,大家有没有什么好的措施来尽量减少过程中业务的流失?

回复 1 : rankk 技术总监 , 券商

一、灾备切换中的两个关键指标 RTO 和 RPO ,其中 RPO (业务数据丢失),在目前的技术层面容易做到 0 丢失,或接近 0 丢失。 RTO 指标很关键,要看两个中心机房或者故障切换的设计,更多的是判断切换的时间因素很难衡量,

二,广发证券在灾难备份整体切换中做得比较好,从网络层面控制整体切换,投入大,但效果显著,在行业中树立 了一个标杆。从应用层面做切换,这是很多中小券商的选择,效率不是太高。

回复 2 : 曾刚 系 统 架构 师 , 浪潮商用机器企 业云创新中心

您说的是数据丢失,还是业务中断?

数据的实时同步可以保证数据不丢失,但是肯定会影响性能,鱼与熊掌不可兼得。

10 、 如何做到系统的自动扩缩容?

当证券市场行情来临,系统交易压力大增大时,如何能够快速定位到系统的哪类组件压力为瓶颈所在,并进行自动的扩容。相反的,当有的组件长时间无压力时,如何准确稳定的回收资源。

回复: frankk 技术总监 , 券商

  1. 扩容容易,缩容很难,做到自动扩缩荣更难。作为最核心的交易系统,任何一个部分变动,都需要经过论证,扩容很常见,缩容也遇到过,
  2. 快速定位压力瓶颈,主要在于日常监控知识库的积累和技术人员的能力提升。 当然现在市场上已经有许多工具软件可供选择,实现了端到端的网络流量分析,端到端数据包的性能分析,通过一些列完善的监控分析软件,对组件的瓶颈判断很有帮助。
  3. 各方面专业技术人员的配合:业务系统负责人、数据库管理员、网络管理员、系统管理员、安全管理员的统一配合排查。

11 、 集中交易系统数据库跨城双活方案?

证券行业有没有 Oracle 数据库跨城(两城距离超过 50KM )双活的案例?采用逻辑复制,存在延时问题,数据库一致性也没有保障。 Extended RAC 方案对网络带宽、时延和稳定性都有比较高的要求。想了解下业界有没有实现集中交易系统数据库双活的案例,具体是怎么做的。

回复 1 : 曾刚 系 统 架构 师 , 浪潮商用机器企 业云创新中心

由于物理上的技术限制,远距离的双活实施起来会比较麻烦。

证券行业目前肯定没有。即使是在银行等其他行业,远距离的双活也是用在交易量不大、或者不重要的系统上,作为一个创新或者试点。

回复 2 : frankk 技 术总监 , 券商

如果是指类似 Extended RAC 方案的话,证券行业目前没有 Oracle 数据库跨城(两城距离超过 50KM )双活的案例 。

12 、 集中交易系统应用程序发布自动化?

集中交易系统相关应用的研发、测试和生产运维分离,生产运维部门如何更好的和相关供应商和其他部门有效对接,通过平台化的工具,实现应用发布的版本管理和自动化?

回复: frankk 技术总监 , 券商

  1. 目前市场上有敏捷数据管理平台系统,主要用于仿真 / 开发 / 测试环境,实现数据库不同版本的管理和快速发布。
  2. 基于测试环境的,部分券商交易系统软件补丁升级实现工具化(自研或合作开发)。
  3. 基于生产环境的自动升级,由于交易系统由供应商控制,软件补丁包多,迭代太快,生产环境的自动升级还没有太成功的案例。将来券商自主研发交易系统,将会更好的做好版本管理 / 自动化升级。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30