solen

用并发多线程测试过，没有做异步处理。每个线程完全向不同的服务器发送请求，发送前测试过每个服务器的时延小于固定值（即服务器选择有效的）。 测试结论是40线程并发效果最好，再增加线程并不会提高速度。而且轮询一次，平均会有1%左右的错误，需要对于错误部分重巡。 这个跟我的代码环境和网络环境应该也有关系，大家参考。

获取个数多的话，单机可以考虑用python的多进程map-reduce向多个服务器发起请求。用futures.ProcessPoolExecutor()的map方法。代码几乎不用修改，很简单。 目前这几天正在测试，用M个进程实时获取数据，每个进程随机从N（N>3M）个服务器中选取一个。 用了API后，数据获取模式会跟一般客户端有明显区别，如果对单个服务器扒太狠，当心TDX提出限制措施，那时就变成魔高一尺，道高一丈的游戏了。

用yutiansut 的代码 [https://github.com/yutiansut/QUANTAXIS/blob/master/QUANTAXIS/QAFetch/QATdx.py#L53](url) 修改了一个函数： tdx_get_servers()，用途是测试ip列表中的服务器速度，返回连接速度较快的n个列表。 使用的时候，，一般这样： ``` servers=tdx_get_servers(n=10) api.connect(server[randint(1,10)],7709) ``` 把servers=tdx_get_servers()放在程序头部 在程序内编写涉及到api.connect时，用随机函数从该列表中取得地址 应该可以部分缓解对单个服务器的压力。 更进一步的数据读取采取多线程或者进程的话，注意测试servers作为参数是否传递进线程或者进程。 ``` from pytdx.hq import TdxHq_API from datetime import datetime,timedelta import pandas as pd #import numpy as...

嗯，就是参考您代码改的，因为需要一次获取多个列表。主要为了实现单线程或多线程运行中随机更换tdx服务器。 另外防止股票‘000001’休市可能导致异常，ping里面改成获取指数api.get_index_bars

确实，我单进程测试，30个服务器，都通的话4-5秒就结束。有2个TO，就要+4S左右了。如果更多TO，时间估计还要加。 如果TO服务器比例特别高，我这代码改两行，用多线程可以缓解。但你这面向公众的代码又不能随便采用多线程，到时不同的机器硬件出一堆其他问题。

发现一个坑爹的情况，对于停牌股票，不同服务器的返回策略不一样： 有些是返回当前K线，但成交额为0或者一个很小的数。 有些返回停牌前的K线。

没有记录.....比例很小，但可能会撞上。估计是某个券商的调整。加了一段代码进行判断才正常，把获取的最新记录的日期和当前日期比对，然后再根据成交量判断。 ``` last_day = datetime.date(tt.iloc[-1,].name) if last_day == date.today(): if tt.loc[last_day:,'amount'].sum() >1: return (code,tt.loc[last_day:,]) else: return ('stop_'+code,'有返回当天数据但实际无成交量，判断停牌') else: return ('stop_'+code,'未返回当天数据,判断停牌') ```

本地数据存储方案很多，测试过的HDF5性能确实比较好。 其实这个包能完成基本的网络数据发包解包就很好了，简单的本地存储方案也就几行代码......复杂的就是一个大PROJECT.

学习了。记得vnpy也用的是mongo，看来有必要研究下。