请教下，关于股票实时数据的获取

HarryYu

我的问题是这样的，比如安装了一款操盘软件，这个时候，如果有实时数据，界面上就会显示这条数据，我知道这个数据是从服务器上获取的，服务器上数据更新了，客户端也更新了。我的问题是，客户端是怎么更新这条数据的，客户端是在不停的读服务器吗，还是有别的机制，知道的帮忙解释一下。

zggjtsgzczh

回复第1楼的 HarryYu：

一般客户端软件都会有相应的通信模块，定时与服务端联系，具体是广播型还是其他类型取决于具体功能的需求。编程上的问题，找一下基于网络的客户端和服务端编程内容的资料看一下就知道了。如果是你自己玩，交易量大的话直接去开条专线就可以了。如果是打算搞软件开发，就去登记一个数据提供商端口，他会给你提供实时数据的。如果这两者都不是，那就Yahoo吧，15分钟一更新。

HarryYu

我想自己写一个操盘软件，我猜想应该轮询那个端口，每秒一次或半秒一次，没搞过，我这边延迟了对方能处理吗？照你说的，符合登记一个端口的情形。我就按照这个模式走了，把接口先留出来

zggjtsgzczh

回复第3楼的 HarryYu：

给定条件：我没有开发过此类软件。

一般他会给你一个请求代码列表，根据不同的请求返回不同的数据流。比如：实时前十名后十名等。如果你打算查看个股信息，可以创建一个新窗体，这样载入窗体的同时会向服务端发送代码请求，然后返回数据流，导入新窗体的相应组件，大不了再加一个缓冲浮动窗口，以及窗体定时器，间隔指定时间更新数据请求就可以了。

开发软件，要从模块的角度去进行，这样如果一个部分停滞了可以在寻找替代方案的同时开发其他的模块部分，建议你采取三步走策略：1.开发框架和路线图，论证可行性及替代技术。2.最小化功能实现，也就是软件原型。3.可扩展可升级的完整版本。祝你顺利。

证交所的相应资料页

http://www.sse.com.cn/marketservices/tradingservice/platform/tradingtech/home/

HarryYu

你说的这些都很好，我刚才没有想到的是，这里的通信应该是有协议的，相互之间的延迟问题应该能解决。我这里无非是读端口和读文件，做成一个模块，读出的结果由另外一个模块处理，两个模块分别位于不同的进程空间，技术上的问题应该不大

zggjtsgzczh

回复第5楼的 HarryYu：

还有一个小问题，你要考虑清楚。如果是实时数据的话。那是否需要建立两个程序组件。一个是服务端，一个是客户端。也就是说，服务端的任务是轮询数据，下载数据，写入数据到数据库。然后客户端调用数据库数据进行分析处理。否则，只有一个软件组件，那么处理上述两个问题会比较复杂，且会产生性能上的影响。

HarryYu

第一个模块/组件会本地实现一个数据库

uunet

买行情接口会推送行情 windows窗口会收到消息然后自己处理窗口消息了比如飞狐用的全推行情

还有的是被动刷新当前窗口比如博易大师只更新当前窗口的数据

HarryYu

这个帖子多谢两位鼎力相助，这个帖子背后我感觉是一个很好的软件模型，现在卡在哪呢，就是两个模块的通信上，真正运行起来也要设计成为一个协议式的方式，以满足外界的变化和扩展，这个需求已经不仅仅是数据的传输和获取了。退而求其次，先做一个读文件+显示，先做一个静态的

zggjtsgzczh

回复第9楼的 HarryYu：

其实你的问题都是涉及编程的，所以还是找一个熟悉的编程语言的相关论坛去讨论比较好。如果不打算未来分销软件，可以试试Python，简单方便还跨平台。qt开发图形界面，Python后台支撑，然后就是大量的Python社区所提供的包，串一下就可以了。开发时间也会比较短，但依赖程度会比较高。

HarryYu

嗯，不打算分销，python和qt都不太会

lyxmoo

回复第11楼的 HarryYu：

网上有很多准实时的web 接口，新浪、网易都有。比如腾讯的就是这样的：URL 后面跟股票代码，不能含错误代码，有错误代码则不能执行了。股票代码可以跟好多个，比如20-30，一个页面整栏为限度。其他的网站也都差不多，很容易就能得到。

<br />
http://qt.gtimg.cn/q=sz000858,sh600000,sh600036<br />

</p>

查询回来的结果：

<br />
v_sz000858="51~五 粮 液~000858~16.79~16.84~16.84~76249~38284~37966~16.79~287~16.78~13~16.77~138~16.76~180~16.75~466~16.80~159~16.81~176~16.82~311~16.83~253~16.84~121~15:00:21/16.79/307/S/515453/24482|14:56:45/16.80/2/B/3360/24242|14:56:45/16.78/10/S/16780/24237|14:56:39/16.80/82/S/136937/24228|14:56:36/16.80/9/S/15126/24221|14:56:36/16.81/1/B/1681/24219~20140529150555~-0.05~-0.30~17.02~16.75~16.80/75942/128286455~76249~12880~0.20~6.08~~17.02~16.75~1.60~637.28~637.34~1.65~18.52~15.16~";<br />
v_sh600000="1~浦发银行~600000~9.62~9.68~9.68~752585~339118~413468~9.61~2130~9.60~8074~9.59~4312~9.58~7964~9.57~4197~9.62~374~9.63~3737~9.64~2862~9.65~3749~9.66~3699~15:00:04/9.62/6/B/5766/16960|14:59:54/9.61/1017/S/978347/16953|14:59:49/9.61/1038/S/998526/16948|14:59:44/9.62/350/B/336400/16940|14:59:39/9.61/210/S/201820/16934|14:59:34/9.62/366/B/351786/16929~20140529150500~-0.06~-0.62~9.72~9.60~9.61/752579/726791004~752585~72680~0.50~4.19~~9.72~9.60~1.24~1435.57~1794.47~0.83~10.65~8.71~";<br />
v_sh600036="1~招商银行~600036~10.15~10.20~10.22~395608~197112~198496~10.15~2189~10.14~2708~10.13~1868~10.12~1243~10.11~3523~10.16~1038~10.17~2626~10.18~3990~10.19~2755~10.20~3347~14:59:49/10.15/10/S/10153/16948|14:59:39/10.15/50/S/50750/16934|14:59:34/10.16/28/B/28339/16929|14:59:29/10.15/16/S/16240/16922|14:59:24/10.16/293/B/297688/16914|14:59:24/10.15/5/S/5075/16908~20140529150500~-0.05~-0.49~10.25~10.15~10.15/394627/402564278~395608~40356~0.19~4.28~~10.25~10.15~0.98~2093.83~2559.81~0.90~11.22~9.18~";<br />

</p>

这样，还需要有一个股票代码的列表。还需要有一个并发的请求程序。然后，就没有然后了，不能查询同一顺序的股票代码次数太多，防止被屏蔽。如果存放历史行情，还要把前面的数据按时间去掉重复记录，并放入某种数据库里。累积历史数据需要时间。同时还要想好如果数据有几十亿条怎么处理。

就这样。祝顺利。

lyxmoo

回复第12楼的 lyxmoo：

我上传了股票板块分类代码，每个文件是一个股票板块的类别，内中就是股票代码SZ/SH开头。本人不负责数据准确性。用前需要自己进行检验。

<br />
http://vdisk.weibo.com/s/iNEFc40M1dUE<br />

</p>

lyxmoo

回复第13楼的 lyxmoo：

据中登公司统计数据【2012.11】，目前A股账户数为16762.49万户，持股账户数为5580.51万户，在参与交易账户数562.31万户，占全部A股账户比例仅3.35%。这意味着，接近97%账户变成“僵尸”。最新股民调查采访发现，目前股民普遍损失惨重，其中92%的投资者出现亏损，超过35%的股民市值被腰斩。

且玩且珍惜吧。

【2014.05.19-05.23】上周,期末有效账户数（万户）6,802.79. 参与交易账户数321.12。

HarryYu

回楼上，把数据放入数据库或者序列化放入memcache，只要保证是最新的，是可以通过数据结构的方式绕开协议通信的，这个地方唯一的开销应该就是timestamp去重，但是这不是我预先设想的结构，所以我现在只做静态的了，以后再慢慢完善

lyxmoo

回复第15楼的 HarryYu：

我的做法也可能不对，我写了一个单独的数据采集归入数据库的模块，几个低能耗主机同时运行。由数据库负责去重。另外的模块运行在其他机器上从数据库里读，这样可平行扩展。采集时间延迟不算，从数据库同步到后面计算的机器上基本上几个毫秒。

HarryYu

我现在只做读文件的

zggjtsgzczh

回复第16楼的 lyxmoo：

个人建议仅供参考，事实可以在数据库中建立两个库，一个储存历史数据，也就是当日以前的数据，称为历史数据库。另一个储存当日交易数据，也就是当日采集的数据，称为当日数据库。然后，写一个存储进程到当日数据库，每次插入数据时自动去重（主流数据库软件都支持较高的并发数）；每日收盘后自动更新当日数据库到历史数据库。如果前端需要调用数据可以分别按照需求返回数据，无论是当日数据，还是包含当日数据的历史数据，还是仅仅读取历史数据，都可以在存储进程中来完成，外部软件调用一下就可以了。

lyxmoo

回复第18楼的 zggjtsgzczh：

最终面临的都是工程问题，而不是想法问题。我曾经碰到而且花了很长时间解决的问题是：

有30亿笔历史交易的记录(每年还要增加10亿笔记录，每天约近500万笔记录)，从中抽取大约1~2千万条，需要在几秒内的时间内完成。没有一种关系数据库能解决这个问题，就算目前热门的内存数据库，要绕的坑也很多，不小心就掉进去了。初步想象，这个问题超级简单，走到代码实现上，就变的复杂起来了。

设想下1990年之前，一般的计算机也完成不了这种问题。

HarryYu

我读文件的差不多搞出来了，可以出demo了