集中交易系统是证券行业的核心系统，券商业务的波动性比较大，突发的高并发业务场景给交易系统带来了巨大压力，如何构建高可用、高并发、弹性的分布式的基础架构，是每个券商必须面对的。目前恒生、金证、金仕达集中交易系统软件在应用层实现了分布式部署，后台数据层主要使用的是 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. 基于生产环境的自动升级，由于交易系统由供应商控制，软件补丁包多，迭代太快，生产环境的自动升级还没有太成功的案例。将来券商自主研发交易系统，将会更好的做好版本管理 / 自动化升级。