RT，
订阅全市场所有合约的Tick，无论用什么数据库存储，都会因为存储造成事件拥挤，结果就是当前时刻处理的数据可能还是几分钟甚至几十分钟前的行情。

请问，目前用vnpy的话，有没有可能做到期货全市场合约无延迟（低延迟）录制？

谢谢。

大半夜的有挺多感慨

从需求层面来说，
1、10年+的TB/金字塔等三方软件的使用习惯；
这些商业化软件连接对方行情服务器后其实本地也是有缓存了数据的。多账户交易也很顺畅。
2、多品种交易的需求。
意味着订阅只订阅部分合约的方案是个伪命题，现在都是多品种交易，而品种或许只要流动性好的品种都有可能去交易。流动性差的品种就算是做了订阅，因为其本身数据极少，不会对引擎产生什么压力。压力核心还是来源于流动性相对好的品种（比如市场前2/3）。
如果基于指数交易，那么意味着必然需要有个数据累计的过程，不然要算信号的时候没有历史数据就尴尬了。
3、分布式交易的不足。
当然，期货市场中程序化参与主体中，从人数上看可能个人交易者是大多数，看起来是个需求，但这部分人里面大多数人甚至没有能力使用vnpy，只能使用第三方商业软件（就像A股市场里散户新开户数量又在创新高，但从资金规模的划分来看，散户的户数新高，但资金占市场比例是在下降的。）。
虽然有RPC的服务端-客户端模式可以分布式交易，但是多账户+多服务端客户端对低成本下的运维管理其实造成了不小的压力。

vnpy作为一个发展多年的相对成熟的产品，在功能上或者横向扩展上做到了无出其右，但是也只能说这个功能我有，但每个功能的压力测试做没做到，做没做好呢，我觉得这块还是有相当大的进步空间。
就像全球做的比较大的开源软件（不限行业、不限功能）来说，它们必然能够做到支撑起一个高度商业化需求来获得收入维持运营（如果非要强调很多单靠基金会活着，当我没说）。
定位其实挺关键的——到底是做个万金油，还是做到领域专精然后再扩展其实是挺纠结的。我算是陈总一推出vnpy就了解学习的第一批人了，那时候vnpy是起于期货CTP，发展到现在有那么多接口那么多市场可以交易。但是CTP方面真的高度完善了吗？乍一看回测、交易、仿真、数据落地好像都有，真的很完善。但真是这样吗？好像又不是，比如说，CTP接口的退出就一直是没有做好，真的是做不到吗？好像不是做不到，是关注点并不在这里。视野高了，细微处可能容易被忽略。
翻了下聊天记录（别问我为什么换了这么多次电脑还有，我也很好奇和惊喜），跟陈总的聊天竟然还有。

那时候从15年跟着学C++的编译封装，到后来弃坑，到现2.1.7在再入坑，兜兜转转好多年过去了。很有幸，我还活在这个市场之中。而彼时关注的一些细节问题至今仍然存在。限于个人能力吧，五年多的时间至今未从vnpy上以程序化的方式往实盘账户下过一手合约，不得不说是很遗憾的事情。

斗转星移，时过境迁，我又回到了当初弃坑的问题上，

而这次，我不会再放弃。

昨晚发感慨竟然打了这么多字，夜深人静的时候是真不能多说话。

更新一下目前的暂时的解决方案：
数据库：postgres
数据库操作文件中postgres的on_conflict操作改为on_conflict_ignore操作。（此处需要感谢上弦之月）
dr模块上，tick的逐个存储改为累计+定频存储。具体来说就是构造一个tick列表，当列表累积到一定量（如1000个tick）时数据库操作批量存储，或距离上次存储的时间超过N秒后存储。
当前市场流动性下，全市场期货合约的tick大约2秒1000条，通过上述操作可以使数据库操作频率下降上千倍，数据库的插入速度就上来了。

大佬牛，有没有代码可以分享~

大牛的楼，占个座学习^_^

我认为可以先找瓶颈，因为每个人的环境是不一样的，所以优化的方案肯定也不一样。对于全行情录制的话基本上分为三个环节：

1. CTP服务器到脚本机
2. 脚本机到数据库
3. 数据库写盘

可以先隔离每一部分的代码来测试

1. 比方说只连CTP接口，但是不做数据库写入，然后在收到TickData的时候打印一下Tick的时间和本地时间，如果相差太多就说明CTP服务器到脚本机的网络不行，这时解决方案就是距离CTP服务器更近的地方部署服务器
2. 如果脚本机到数据库也走网络的话，需要考虑两方面的因素，延迟与吞吐量，延迟可以用ping的方式来探测，吞吐量可以直接查看网卡io的数据，看一下是否到达网卡上限，如果没到网卡上限但速度也不快的话也有可能是wifi导致的不稳定或者网线需要换成6类线或者更高规格
3. 如果是数据库机器硬盘io过高的话，那就有可能需要在第三个环节进行调优，软的方面把逐条插入改为批量插入，硬的方面可以选用高性能的ssd硬盘，关闭atime，做raid，取消实时备份等功能
4. 还有可能是数据库CPU过高，这也是需要改批量插入或者换更牛的CPU
5. 为了解决数据库性能瓶颈，可以考虑做分表分库，也就是说不同的合约考虑发到不同的数据库服务器上。或者做的更极端一些我们可以从最开始的脚本机就做拆分，比方说两台或更多台独立脚本机对应各自的数据库服务器，每组监听不同的合约

现在支持influxdb了，作为时序数据库，性能是不错的，用这个挺好，用postgres则明显不合适，然并卵，数据写入并不是瓶颈

只录制指定的100个合约，速度就快了吧。应该怎么搞呢，请教。

kingmo888 wrote:

RT，
订阅全市场所有合约的Tick，无论用什么数据库存储，都会因为存储造成事件拥挤，结果就是当前时刻处理的数据可能还是几分钟甚至几十分钟前的行情。

请问，目前用vnpy的话，有没有可能做到期货全市场合约无延迟（低延迟）录制？

谢谢。

大佬，能不能分享一下你的行情记录的代码，我找了很久没找到能用的