算法交易平台的建设进展

经过近几个月的努力算法交易平台的建设得到了快速的发展，以下与各位分享一下目前的成果，以及对于某些问题的探讨。
目前我们建设的算法交易平台主要包括以下几个组成部分：
1）交易代理服务器：
• 提供客户端统一接入服务
• 负责代理完成证券、期货市场的交易指令下达，提供全市场的交易通道服务
• 提供全市场的实时行情推送服务（目前已支持levelI的证券实时行情推送服务，level II也支持但是还没想好服务的方式和内容）。
• 提供历史行情数据的高效查询服务
• 提供资讯数据查询和订阅服务
• 提供基本的交易策略服务（到价、到时、到量策略交易）
2）算法引擎服务器
• 提供用户隔离的事件模型
• 提供算法策略函数
• 提供基本的交易策略模型demo
• 提供远程算法托管服务
• 提供前置式算法引擎服务，可将算法引擎部署到用户端，由用户自行管理算法的托管运行
• 支持基本的金融函数和指标
• 提供由我司金工团队开发的经过多年研究和实践的专业vwap算法服务（只针对特定机构客户）
3）统一行情服务器
• 提供全市场的实时行情全推送服务，目前已支持level I的证券、期货实时行情服务
• 提供历史高频数据的查询服务，为用户提供全方位的数据解决方案（优待完善）
• 提供高质量的level II数据服务（高端客户）
• 提供统一的全市场行情数据服务接口
4）资讯服务器
• 提供万德资讯数据查询服务（提供查询api函数集）
5）事件订阅服务器
• 提供交易确认、成交回报事件订阅与发布服务
• 提供客户资金变化订阅服务
• 提供客户仓位变化订阅服务
• 提供特殊事件的订阅服务
6）发布服务器
• 实现订阅发布体系的主要服务器，组群服务

客户端支持方面：
1）提供应用级API函数，简化学习开发曲线
2）提供win版和linux版API函数接口
3）提供专用于C++的应用功能框架类，提供高级开发能力
4）支持基本交易业务、ETF套利模型等
5）支持同步和全异步、多线程安全的的工作方式
6）支持本地内存数据库
7）支持订阅发布机制
8）支持SSL安全通讯
9）支持支持高效的分页查询引擎技术，理论上无论多大的数据查询量都拥有一致的快速查询体验
10）win版支持交互式调试模式，提供类log4j的日志机制且基本无效率损失
•••（more）

「问题」
（1）如何改善行情数据服务的质量和高效率
（2）用户需要的资讯数据查询服务？
（3）建立和健全套利模型，提供用户自定义模型的能力
（4）通过实战提高平台的高可用性、稳定性和处理能力，尤其是多用户下的多算法实例托管运算能力
•••（more）

目前来说我们其实还是相对更注重通道服务的建设，稳定高效的平台服务是首要目标，其次再进一步提供更高阶的服务内容，先解决客户最常关心的基本服务，再与客户沟通并定制高阶服务内容，这是我们的现阶段的想法。

另外我们还开发了FIX引擎通道服务，不过正在参与交易所的FIX应用推广工作，也不是很清楚未来的计划，所以暂时只提供我们的专用API接口。

为了提升客户信心，我们初步先给公司的自营业务使用，同时由研究所牵头与个别机构客户建立了合作关系，进入实盘交易。

总之，感觉还有很多东西需要完善，任重道远吧，由于经验有限，很多想法并不完善，而这里却很多具有实战经验的专家，因此我也希望更多这方面的专家提供意见，如果有这方面意向的客户也可采取合作开发的模式，毕竟我们团队更偏向技术领域，在应用方面还是欠缺经验的，欢迎批评指正，也让我们少走弯路。

 

这么高端庞大的平台，恐怕小散用不起。
对于小散，只要有个行情接口和下单接口就足够了。
中国国内API是尽量保密，与国外相反。这样会使程序化交易在中国很难普及。英国达到了1/3, 美国达到了75%. 如果中国不放开这块市场，差距与国外越来越大。
中国缺乏象interactivebrokers这样的公司，既提供便宜的佣金，又提供API。 你看看金字塔软件，收那么高的年费，与小散的梦想差的太远。
到目前为止中国还没有一家真正意义上的股票自动化交易通道。这个通道应当直接接入交易所，不应当有缓冲，不应有大的延迟，不应当实现内部对冲（违反政策）。
1）行情服务器与交易服务器应当是分开的。行情采用UDP通信。不要用TCP，不要用其它平台作基础。服务器OS要用LINUX或UNIX类，不要用WINDOWS。
2）如果是直接查询万德的数据，它的服务器可够慢的。我试用过，传过来数据太慢，但数据质量不错。
4）托管要使下单速度明显比在客户端快。安全性是大家担心的。别人经过辛苦做的东西托管到你那如何放心？想提高处理能力要想法提高并发处理能力，建立服务群，网络架构要有自动扩展能力，要实现负载均衡。当一台出现问题，要自动切换到别的服务器。
客户端应当与多个网（电信，网通，联通）的多台服务器时刻建立着慢速连接心跳。当其中一个通道有问题时不至于影响到其它通道的下单。现在没有一个平台这样做的。包括TWS也没这样做。如果发现一个通道断了，才重新连接新通道已经来不及了，太晚了。要在中国一级城市建立庞大的服务群。具体架构可参考QQ服务器群或GOOGLE的服务器群。
5）WINDOWS平台最好提供普通的DLL库。这样可以使大多数语言调用。而不是提供仅用于C++的DLL库。

将来交易所可能会用FIX？将来交易所会引入做市商制度？ 有这个可能。如果政策放开，中国会产生一大批做市商，也会产生一大批新富翁。如果开通国际版，50年后中国金融市场可能是世界最大的金融市场。猜想而已。

你的内存数据库支持海量数据吗？光A股的分笔数据至少也要在20G以上。内存装不下如何办？
想提供更高阶的服务？你的平台能提供网络信息智能搜索功能不？学学GOOGLE,别学百度。他们根本不在一个层次上。如果你想搜索点东西，在百度上搜出来的全是些垃圾，根本不是我想要的，而且大量是重复的，真不知道百度这帮混蛋每天是做什么的。再看看GOOGLE就好多了。
闲着没事的灌水贴

 

这个平台人家本来就是吸引有实力的组织, 有钱有策略的那种. 要不人家做的这么全干什么. 散户用那俩已经是偏得了^_^. 和国外差距大,有什么问题么. 自己吃自己, 自己挣自己的钱, 我觉得这个主意不错, 开放的话,一大堆让人调头发的问题呢. 不要想了(我是替共产党给你解释一下). IB好是好, 资金门槛你得合计合计. 金字塔不错, 一年1800可以了. 至于你想直接进交易所交易... 我看你是太把自己当回事了, 一个平头老百姓,没事老合计到人民大会堂做做主席的椅子.
1. 技术问题就不和你讨论了, 反正现在CTP就不错, 你要是有空的, 可以研究一下恒生的, 那个是udp的. 不过时间你自己算 呵呵.
2. 这个是什么玩意, 我去查查, 不过谢谢提醒
4. 这个问题其实不用人民币的话,是最不好解决的. 你搞一套有Fail over 系统的花费是超过你的想象的. 毕竟应对小概率时间, 测试和规划都很费尽. 跟天斗就是这个最烦了( 高铁死了那么多的人, 可以帮助理解这个). 散户的话, 断电短网, 呵呵你可以人工解决. 要是你那时候忙, 那就平掉. 没办法. 这是命了. 散户的命. 你最爱的IB也没给你什么好脸,虽然你入金10万20万的. 我在合计这个问题怎么能解决的gracefully.
3. 对了,你3哪去了
5. 小问题

有那么一天吧. 我估计这个FIX 可能不叫FIX , 叫TD-FIX 好跟国外的区别和抗衡. 50年之后的事情, 根本不用关心的. 2038年之前我都不怎么担心.

内存数据库主要是用来作运行时查询存储的吧. 作这个肯定有用途上的考虑的. 要不直接sqlserver多好啊. 后面我就不说了, 失态了.

 

问LZ一下，你们的产品是针对个人用户还是机构用户？或者二者都是你们产品的潜在客户？

 

你不如问问，收费模式。 这种个性化的服务， 我感觉都到不了小资金量户的手里的。

 

RE

从我个人立场而言我并不认为这个项目就是针对机构客户、或者大客户，其实大家都明白，作为券商只关心交易量，至于你是几百万还是上亿，不是根本性问题，上亿的客户不交易我想大家也不是很有兴趣，毕竟我们看重的是交易量带来的收益，所以贡献度才是真正的考核标准吧，单纯从技术而言，我们这个团队开发这个平台的确想法有点大，也想涵盖散户群，比如说算法引擎前置的方案，这样的技术方案可以不需要增加我后台的压力，服务跑到你家机器上就好，但是肯定不像托管服务24小时不down机，这种服务方式既适合一般客户，也适合那些不愿意将算法托管在券商后台跑的客户，谢谢。

 

RE：

我们的产品面向广泛的不同客户群层次，至于谁才是公司更愿意提供服务的客户群，不是我这个团队关心的问题，我们要做的就是有需求就能顶得上去，包括设计我们一开始的目标就是至少可以取代目前的网上交易吧，一个服务器挂2000~3000连接没问题就行，然后逐步提升并发处理能力。

 

RE：

目前服务器群，主要还是以交易代理服务器作为接入服务器，事件订阅服务器最为事件源，驱动算法引擎服务器运算，行情服务器是独立，作为特别的行情源事件驱动算法运行和通过交易代理服务器完成推送，发布服务器是为了分担大量的数据推送负载，整个架构完全是事件驱动模式的。目前我们既有基于Linux的也有基于Windows Server的，是一个标准的卫星结构吧，通过订阅发布技术基本上也起到了一定的负载均衡和数据同步备份的作用。

我认为我们的交易接口应该是要简单过CTP的接口，当然我是这么认为，但也是理想愿望，因为我们期望提供用户最简单易懂的接口，完全屏蔽技术的东西，毕竟很多用户不是很懂技术。

 

RE：关于性能指标

我们经过初步评测：
（1）行情推送的速度应该是至少不会比大家日常使用的行情分析系统慢了
（2）交易速度依赖柜台系统的处理速度，我们目前用的是恒生的系统，每秒100笔肯定不是问题，我们测试环境来看，单账户做到上万笔单速度明显下降，可能与柜台优化不好有关系。当然大家可能会笑话这样的速度，我也是，但是我只能说我们肯定可以提供超越柜台系统的最高速度，至少我们不会是瓶颈这是基本条件。
（3）我们的内存数据库主要是用于高速cache，所以理论上会有很大帮助，MongoDB数据库集群主要用于资讯，所以大家无需担心万德数据慢的问题。
当然我们系统还有很大的优化空间，我跟我的团队说优化本身就是个工程，循序渐进吧，至少拿出手那天不要被同行笑话才行，呵呵。

 

RE:

首先谢谢这位仁兄的中肯意见。
嗯，针对您提出的几点我也简单回复一下：
1）中国国内API保密其实是不自信的表现，我也很赞同和欣赏这位仁兄提出的国外的模式，俗话说得好，有料干吗不敢拿出来溜溜，再说有什么秘密可言。
2）我认为需要澄清的是并不是国内不愿意放开这块市场，主要原因是因为这个行业的历史原因造成的，比如说，我刚进入这个行业的时候就觉得很奇怪，券商这么有钱，为什么技术实力这么差，像国外同行，几乎关键系统都是自己做自己的，哪有交给开发商垄断的，这个本身就是很大问题，像恒生、金证这样的公司以柜台系统主导了整个市场和技术的发展，我认为现在成了整个行业的障碍，但是没办法券商自己搞不定，领导不重视IT，钱更愿意花在宣传和业务推广上，殊不知技术和业务是相辅相成的。过度依赖开发商成了整个行业的弊病，以至于交易所、登记公司很多的技术、规则推广工作还得招呼这些开发商参与标准制订，券商反而成了配角，我在这行十几年了也无法理解，开发商之间的利益竞争也决定了行业的很多弊病，包括开放市场，统一技术标准等，我本身也是来自IT厂商，所以个中原因心知肚明，当然现在立场不一样了，所以我也呼吁同行争点气，不要总是被恒生之流的公司牵着鼻子走，说实话，他们那点东西，我是看不上眼。
3）站在券商的立场下，过度依赖还导致了券商的低俗、同化竞争格局，技术不突出只好打佣金战了，银行则不同几乎每个大行都有自己的千人开发团队，例如招行，技术不是决定一切，但却是一个软实力。
4）这位仁兄提到的采用行情UDP传输技术，我们已经开发好了，只是得慢慢来，我的计划是淘汰TCP，尽管我们似乎想将TCP通信技术发挥到最好。我想以后会退出纯的基于可靠UDP技术的接口，我评测过速度非常快，不过我现在的任务主要还是在基础平台建设，慢慢来，否则什么叫升级换代嘛，呵呵。
5）我们的服务器有大部分跑在Windows Server上，主要有几个原因，其中最主要的考量是我们需要整合很多第三方的系统，例如：短信平台、CRM、资产管理系统、自营系统、资讯系统等，而这些系统大都不提供Linux平台接口，而且由不同的开发商提供，所以选择Windows平台是被迫方案，而且我想做我们最擅长的是，整合资源为客户提供丰富的功能和服务，我们不是去取代开发商，取长补短是我们更应该做的事情。
6）万德数据是数据源，我们提供给客户的数据是从MongoDB集群过来的，速度非常快，我们利用MongoDB作为高速cache，包括行情统计数据的计算处理等，主要是因为开源；
7）至于托管这个问题这位仁兄提的很好，也是我们在架构设计上考虑过的东西，我们也相信高端客户并不愿意将自己写的算法策略跑在券商后台，因此我们支持前置式部署，唯一要求就是要使用我们的算法引擎，当然我们也只能承诺不会将客户算法传输到后台，或许以后会有更好的方案吧，欢迎大家提建议；
8）至于负载均衡和通讯问题我只能说我们不想单独拿出来讨论，因为我们设计的目标之一就是向用户屏蔽这些，用户无需理会，反正达到你稳定可靠的要求就好了，我们怎么实现的，无需关心，出了问题就是我们的问题；顺便说一下，我们团队也有腾讯过来的，不过没有提供什么好的可继承的东西，不过我认为我们面对的客户群与他们差太远，规模也差很多，倒是可以学习一下，可惜没人指点。
9）客户端接口我想说明一下，我们提供两种方案：纯C函数集，并且是应用级的，类似CTP接口。还有就是C++应用功能框架类库，其实都是同一套东西，我认为类库用起来更加灵活罢了，我们的任务是丰富类库的功能类，覆盖证券、期货交易的所有业务。C函数库提供WIN版和LINUX版。
希望上述回复能让大家更清晰，也谢谢大家的好建议。

 

感觉已经很专业了. 在哪都一样, 考核的都是成交量. 鼓励高频/过度交易的. 但是如果是抄单类型的交易其实收益很受佣金的影响, 不过能一次行购买永久使用也算不错. 你的测试系统 如果是作的柜台中转的话, 延迟肯定是下不来的, 这个无论你怎么作都比不上直连柜台, 除非直连交易所. 但是这个如果个人用上还要像tony要求人民大会堂的待遇的话, 花费可能比买你的系统还要大. 至于资讯这个, 在现阶段, 我不清楚有多少基于新闻文本分析的, 快哪半秒一秒的, 做的太精了的话,用户除非有特别想法. 这个说有优势也就那么回事.

 

RE：关于FIX、高阶服务等问题

1）FIX说起来就很汗，交易所至今没有时间表推出，作为这次的研究课题组主办单位，我认为的确是该加速标准制订和应用的时候了，当然交易所可能还有其他难言之隐吧，但是作为券商其实更关心的不是FIX带来的统一标准、速度等问题，而是有没有带来什么新的业务功能，例如：改单、组合买卖单等，国外已经很成熟了，业务毕竟是推动发展的根本动力源泉；
2）我所说的高阶服务，当然是指针对特定客户的、定制的服务，客户群划分不同层次后我们只有精力坐下来针对这类客户单独设计开发特殊需求的东西，一般客户只能提供标准的、普及版的东西，这个是精力所限而已吧；
3）“网络信息智能搜索功能”不知道是什么？我理解的是不是指对股票行业的分类立体式分析，百度、google本身没错，毕竟是通用的搜索引擎，不是给你专业搜索用的，而且很强大。我倒是有个同学博士后在IBM从事类似微软的立方体技术的研究，好像做得就是类似的技术，曾经聊过，好像是什么纵向搜索引擎，其实用在金融领域就很好，我有一个朋友正在开发类似产品，可以帮助用户立体式分析个股、板块、行业、相关联领域之间的关系，例如：美元升跌对金属期货市场的影响，然后一环一环，听上去像是“蝴蝶效应”，呵呵。如果做好了，我会在第一时间整合这样的产品提供给客户使用。

有一点体会，顺便给大家说说：我认为券商是一个很特殊的角色在国内，占据最主要的资源，所以理应提供给客户有偿使用，免费当然也都是浮云了，毕竟大家都需要动力，在国内绕过券商去做些事其实你会很累，像这个论坛里有很多朋友提的一些问题和困难在我看来简直就是小儿科，当然问题也在于券商一直没有重视这些潜在的需求和服务，而开发商因为利益导向也不愿帮券商做这些事，国内的啥都免费的气氛我觉得不是很好。但是要让客户掏钱，也得拿点像样的东西才是。

 

RE：

呵呵，这位仁兄还是点出了一样要害问题，不过历史原因造成的东西暂时也无法回避，这个不是我能解决的，留给未来去彻底解决吧。

 

我虽然也算你的同行, 但是作的东西没有你们弄得这么专业. 我认为, 唯软件导向的想法是书呆子的想法, 讲究软硬件结合, 量力而行, 而不是想一出是一套. 不然钱没赚到, 本钱都先被软硬件爱好者折贫血了. 技术上的投入是理性消费不单单软件上的一次性投入, 还有周期性的投入, 需要统筹考虑. 可以用资金投入力度决定技术投入多少,要算的帐很多. 比如你就20 30万的钱 交易量也属于小的那种, 如果按照理性回报每年50-60%的话. 在这方面的投入例如不超过3万块,包括软件硬件. 比如认为这个就是适当的. 如果你到达百万量级的话. 你可以考虑在交易所机房租机位了. 和不合算, 效果明显与否, 可以测测. 都是一个比例, 记住到底自己是个搞投机的还是个搞软件的. 这个是我的看法.

 

对了，顺便说一句，如果条件允许，未来我愿意给大家提供公网测试环境和开发包

我们已经建立了公网测试环境，但是目前只针对客户开放，不过我倒是愿意完全开放给任何人，大家可以互相交流些问题，即可落地更具体，也可让彼此了解需求、推动发展，更可以帮我们完善系统也是件美事，呵呵，所以在这里拜谢先了。

 

RE：

嗯，您说的也是对的，不过我主要还在技术领域，所以不愿考虑太多其他方面的因素，毕竟咱只是做IT的，不是领导，有些想法你说了也不算，不过从我立场出发，我希望未来在这个领域的投入还是应该加大，不是因为关切自身利益，而是从行业发展去想，的确应该如此吧。另外说到投入产出问题，有一点大家心知肚明，比如说交易通道吧，虽说行业规定公平原则，但其实大家心里都知道不可能了，VIP的客户一定是专用席位和跑道，散户就给修座大桥吧，不过按照规律，参照国外市场，散户早晚要淘汰出去，机构客户才是未来的市场主角，即使我也就是个散户。

 

这个论坛上活跃这不少程序员. 有些想法 其实是专业思维使然, 什么回测软件不行, 什么界面不好看. 都经过这么长时间了, 也没看那个仙人编出个界面漂亮的一塌糊涂, 回测考虑的彻头彻尾的软件出来. 软件好像随便支个电脑就能编, 其实作作看就知道了. 搭的精力花的钱, 无论你多牛, 花费都超出你的预期.

 

hehe 其实也没啥, 当个程序员也挺好的. 只是不要碰上点不好解决的问题, 就歇斯底里的才好

 

序号大体对应LZ的问题。没对3作出响应，所以缺少3