证券行业集中式交易系统

有个证券公司的技术负责人问了这样一个问题：为什么美国人能够做
集中式交易系统而我们却不行？这真是一个值得思考的问题，在中国不但
可以买到美国制造的最先进的计算机硬件，也可以买到美国工程师使用的
各种系统软件和开发工具，但是，为什么我们的实际应用水平却相去甚远
呢？

　　经过多年的演变和实践，美国证券公司的实时交易系统已经十分成熟
。不同的证券公司系统之间的技术架构基本相似，在软件和硬件技术上也
没有任何密码和壁垒可言。我们的紧邻韩国的证券公司在1997年开始开发
基于互联网的新一代集中式交易系统，经过5年塌实认真地学习和实践国际
潮流技术，不但在集中式交易系统建设上获得了成功，而且在技术上也取
得了长足的进步，积累了丰富的经验。

　　中国证券公司致力于建设集中式交易系统由来已久，深圳一家对IT系
统投入很大的证券公司在1997年就开始规划集中式交易系统，但直到现在
还没有获得一个可运行的系统，在集中式交易系统中，每秒钟对交易事务
处理的数量是标志系统是否成功的关键参数。国内某个IT公司正在给这家
证券公司开发集中式交易系统，第一次压力测试的结果显示每秒钟可交易
40多笔，与系统设计目标200笔/秒相差很远。经过系统优化之后也还是没
有完全达到设计指标。还有一家证券公司为了建设一套集中式交易系统，
先是购买了IBM的AS400服务器，后有购买了IBM RS6000，系统建设前后历
时3年多也没有实现全公司的集中交易。

　　这里面有一个相似之处，就是许多证券公司在建设其集中式交易系统
的时候，都是相应的硬件系统早已到位，而自行开发的应用软件系统却无
法达到实际应用的标准。可以说，国内证券行业迄今为止所开发的应用于
全国范围的集中式交易系统还没有一个可以成功推广的经验。

　　问题出在哪里呢？在计算机的硬件系统上吗？许多证券公司在开发其
集中式交易系统的时候，已经花去了大把的真金白银，买回了大量美国的
计算机，如果说只要购买高价先进的计算机硬件就可以解决问题的话，中
国的证券公司5年前就大工告成了。

　　这些证券公司出现的问题无法考证，也许问题出在比较容易修正的程
序技术处理上，也许出在系统测试的环境上，而最不乐观的估计是从技术
路线、系统架构设计，到对目标业务理解都出了问题。这样，即使成倍地
增加对计算机硬件的配置和投资，也将无法达到设计的要求。

　　软件技术影响集中式交易系统效率

　　许多证券公司都在执着地开发集中式交易系统而未果。问题的原因很
可能是缺乏对软件技术的理解和正确应用。然而，对应用软件技术认识的
缺失。甚至会导致整个系统开发的失败。

　　从技术的角度来讲，即使数据类型定义这一项在编程中最常用和最基
本的技能也会直接影响软件系统的运行效率，而软件系统的运行效率，又
对系统硬件的选型和是否能够得到一个成功的系统起着决定的作用。

　　以目前国内证券交易软件中股票代码为例，许多传统的柜台交易系统
都把它定义为字符串，这种定义方法与上海和深圳两个交易所所提供的交
易库中的定义是相一致的。

　　但是计算机在计算整数时要比计算机字符串快得多。整数是计算机程
序中定义变量的一种基本类型，而在运算字符串变量时计算机首先把字符
串中的每一个字符逐一转换为整数，然后再对每一个整数分别进行运算，
然后再对每一个整数分别进行运算，可以证明，计算机软件处理整数的效
率要比处理字符串快2n倍，其中n是字符串中的字符的个数。这是一个很可
怕的差距。

　　上海和深圳两个证券交易所的股票代码长度均为6位数，在计算机中，
股票代码000001可以被定义为整数，也可以被定义为字符串。以整数定义
时在计算机中表示的长度为1，而以字符串定义的时候其长度为6。如果一
家证券公司要求其集中式交易系统的处理能力达到10000笔/秒，同时我们
把交易过程中对股票代码的使用分解成以下6个步骤：

　　1、接收交易 2、验证股票 3、冻结股票 4、提交交易 5、处理成交回
报 6、记录日志

　　假设以上每一个步骤都只对股票代码进行一次计算的话，处理一笔交
易就需要对股票代码进行6次计算。按照系统要求，计算以整数定义股票代
码的计算能力为6万次秒，而计算机一笔以字符串定义的股票却需要达到7
8万次/秒，后者比前这需要多出72万次/秒的计算能力。

　　此外，许多柜台系统把股东代码也定义成了字符串。按深圳交易所股
东代码的长度是10位来计算，假设一笔交易同样需要对股东代码做6次与股
票代码相同的处理步骤的话，集中式交易系统仅仅对字符串定义的股东代
码和股票代码的计算就需要增加192万次/秒的计算能力。

　　还有，每一笔交易都要和数据做相关的运算，通过计算得知，按股东
代码被定义为字符串来计算，当数据库每验证一个客户时就要比整数定义
的股东代码多480次比较运算，仅仅在验证股东代码这一项运算上计算机就
需要多出480万次/秒的计算能力。

　　如果把股票冻结、交易日志和成交回报数据都储存到数据库中的话，
单是对数据库进行使用字符串定义股东代码的计算就需要多出1920万次/秒
的计算。一天4小时的交易，系统将需要负担2765亿次的计算。

　　对任何一个数据库设计人员来讲，这些都是十分可怕的数字，更重要
的是这还不是一个完整的计算过程。由于数据库需要保证数据的一致性和
完整性，以及数据计算的可逆转性等等，如果再把股票代码和资金帐号考
虑进来的话，在实际的交易系统中数据库运算的次数将远远超过以上的估
算。

　　事实上，影响一笔交易的因素还有很多，比如，交易系统架构中的中
间层次越多，则对一笔交易计算的次数就越多。如果设计架构中采用第三
方开发的中间件软件，则更需要重点考察其在实时计算方面的能力。例如
第三方产品的开发语言没有采用C或是C++语言编写，其实时计算机的能力
已经大打折扣，因为计算机界公认的结果是C语言的运算效率最高，C++语
言排在其次。虽然第三方产品的代码不向用户开放，但还可以从其对事物
处理的流程中推算出计算的次数。目前，美国和韩国的同行基本上都采用
C和C++语言来开发实时交易的处理过程。经验还告诉我们，通过中间件产
品在其设计中通常对实时运算的考虑不充分。

　　以上这些数字和因素是任何一个系统分析师和结构设计师在设计集中
式交易系统时都不能忽视的，因为这些附加的计算能力需求，在一般的情
况下都需要通过增加服务器的配置或者是提高服务器的型号来满足。而对
做甲方的证券公司来讲，提高服务器的配置或是型号，将直接转换为增加
项目的投资。

　　跳出硬件思维的定式

　　证券公司的CIO们完全可以在项目的前期把好效率关，要求IT公司在完
成系统设计阶段之后进行一些必要的证明，充分地说明一下为什么他们设
计的系统是实用的、有效的、实时的、可扩展的和可靠的，以规避系统后
期开发带来的风险。不然的话，将浪费大量的人力、物力和时间。

　　国内有不少证券公司的IT厂商对硬件的投资比较关注，特别是一些系
统集成商和跨国公司会说服证券公司在完成系统设计阶段之前买回服务器
。这样的做法会造成以下三种情况的投资浪费。

　　1、最终系统对计算机能力的要求低于提早购买的服务器，造成投资的
浪费；

　　2、最终系统对计算能力的要求超过提早购买的服务器，需要二次购买
更强大的服务器，造成前期投资浪费，损失更加惨重；

　　3、如果早早地买好了服务器，而系统开发的时间拖了一年二载，并且
服务器处于闲置状态的话，按照计算机硬件设计折旧的计算机方式，服务
器很快将被淘汰，损失同样惊人。

　　不少证券公司都有过硬件系统躺着睡觉的经验。一家大券商为了实现
交易的实时监控，购买了IBM著名的“深蓝”计算机，但由于软件应用开发
时间过长，当软件要上线运行的时候，却发现需要对几年前购买的IBM“深
蓝”计算机追加投资之后才能使用。

　　韩国证券业的IT人员对软件和硬件的关系做过十分精辟的注释。在中
国某大证券公司访问韩国的时候，中国的技术人员一而再、再而三的询问
不同的韩国证券公司和IT公司有关如何选取集中式交易计算机硬件的问题
----是IBM的主机系统好，还是UNIX系统好？而我们的韩国同行们却一遍又
一遍地，反复第强调系统的处理能力主要取决于交易软件，而不取决于硬
件。韩国大宇证券公司在没有增加任何硬件设备的基础上，依靠对中间件
软件的重新设计和编排使整个交易系统的运行效率30%，这是一个十分可观
的数字，也更进一步说明了软件设计和编程的魅力所在。

　　项目外包是否最佳选择

　　北京某大证券公司一位负责人表示得很清楚：开发集中交易系统一定
会走外包的路子。这一观点在证券行业颇有市场，原因之一是系统开发外
包是眼下国际上流行的做法。

　　软件开发外包，是由美国公司开始的。对美国的公司而言，自己本身
就有足够的业务和技术能力开发完整的信息系统。一般来讲，美国的大证
券公司既知道怎样规划集中式交易系统，也知道如何去开发。系统开发外
包是在寻求降低生产成本的过程中可供选择的一种模式。通常的做法是自
己做IT系统的分析和结构设计。把占50%~60%的系统开发和测试工作外包出
去，编程的方法和使用的计算机语言等都是由发包方指定的。

　　对国内券商来讲，外包却是建设集中式交易系统的唯一选择，80%~90
%的工作量需要外包，从系统的方案、整体的逻辑框架设计，到确定编程的
方法和使用计算机语言等都需要外包，这是一个非常矛盾的事情。一方面
，证券公司希望打造自己所独特的集中式交易系统，充分体现自身的核心
竞争力；另一方面，又不得不把打造自己核心竞争力的思路传授给承包的
IT厂商，把80%以上的系统建设风险控制权拱手交了出去。这等于把这一战
略目标的命运完全交给了IT承包厂商。

　　根据目前阶段证券行业对集中式交易系统建设的情况来看，外包的做
法不能令证券商满意。许多国内的IT公司在投标的时候方案做的很漂亮，
但是却无法回避第一次开发集中式交易系统这一事实。而银行及保险业的
IT系统建设的经验又和证券行业的实时交易系统大不一样，在系统设计和
技术运用上有一定的差别，无从借鉴。大多数国内IT公司还处于摸索、学
习和尝试的阶段，不仅是编程技术可以改进，而且对数据库的设计和理解
也大有潜力可挖。

证券行业集中式交易系统相关推荐

现代银行集中式业务系统及数据整合
随着互联网和移动互联网的普及,互联网金融也日益进入人们的日常生活.当前互联网金融方兴未艾,各种新颖高效的金融产品层出不穷.随之而来的是日益激烈的竞争.在这次金融革新的大潮中,传统银行暂时处于相对保守的 ...
证券行业信息化17_我的香港游记3_交易系统技术支持部_会计与结算技术支持部都干些什么?
转自 https://stanleyyan.wordpress.com/category/%E8%AF%81%E5%88%B8%E4%BF%A1%E6%81%AF%E5%8C%96/ 总结:IT支持部 ...
2021年中国光伏行业现状分析，光伏发电集中式与分布式并举的发展趋势明显「图」
一.光伏行业发展历程光伏发电技术最早可以追溯到1839年法国科学家E.Becquerel发现液体的光生伏特效应(简称光伏现象),光伏发电大规模商业应用要从2004年德国率先推出光伏补贴政策开始.自2 ...
集中式还是分布式？账务类数据库架构的选型
近年来,分布式数据库已经成为了行业中默认的主流技术方向,仿佛只要一款数据库不是分布式架构,即丧失了其技术先进性,无法承载未来业务的发展.这种观点对于"大数据"时代的海量数据需求完全 ...
国产分布式数据库在证券行业的应用及实践
[摘要]近年来,证券市场行情火爆,对支撑业务的IT系统及数据库提出了更高要求.本文分析了证券行业当前数据库应用的困境及我司典型的应用场景,对国产分布式数据库在证券行业中的应用价值进行了探索,包括其高可 ...
架构选型必读：集中式与分布式全方位优劣对比
应用现状比较由于历史原因,集中式架构多用于传统银行.电信等行业.主机资源集中在大型主机或小型机上.集中式架构下,包括操作系统.中间件.数据库等"基础软件" 均为闭源商用系统.集中 ...
集中式管理助推服装企业腾飞
对于服装企业采用B/S和C/S优缺点的问题.近年来一直是行业内争论的热点问题.基于C/S架构的应用因为响应速度快.操作界面的个性化.对复杂流程的适应快,一直是服饰管理软件的主流架构,但随着互联网的发展 ...
postgresql 分区视图_PostgreSQL架构集中式到分布式主流架构总结
文章目录一.PG未来主流架构为什么是分布式二.PostgreSQL集中式到分布式架构总结一.PG未来主流架构为什么是分布式如果说5年前DB的分布式还只是一种趋势,如今分布式数据库正逐渐从趋势变成 ...
大咖布道丨证券行业规模化敏捷和核心能力演进
摘要:本文以证券行业的某头部企业的重点产品为例,探讨基于行业特征,同时脱离现成框架的规模化敏捷实施的实践总结. 说到规模化敏捷,大家通常马上会想到市场上的各种主流框架.诚然,现成的框架能与企业现状较好 ...

证券行业集中式交易系统

证券行业集中式交易系统相关推荐

最新文章

热门文章