Tick数据在技术上究竟是什么东西_2_2

2019-11-07 10:13:13

从交易所的数据发出到你的电脑上能看到发生了很多事，如何判断数据的好坏是一个复杂的事情。作为曾经写过不少交易所的tick数据的处理程序的人，可以解释下为啥复杂：）TickData本身并不神秘，就是交易所把每只股票（亦或是futuresoptions）的activeorderbook(就是你的order还存在在交易所里面，并且没有被撮合成交。)里面的买、卖的单的情况发给你，但是每个市场的规定都不同，举个栗子：最真实的orderbook是这样的,一天的市场一开始的时候苹果股票的orderbook清空（这里不进行auctionperiod的探讨）：1.接着来了第一个卖家：1000@100:这时候交易所会发给你一个message，告诉你是苹果股票有人想以100块钱买1000股，那么这个order就先挂在了orderbook上。2.第二个卖家来了，他想卖得更高：1000@101:这时候交易所会发给你另一个message，告诉你是苹果股票有人卖的价格比你差，于是排序在下面。3.刚才的第一个卖家后悔了，cancel了他的order：1000@100撤消了，那么交易所会有message告诉你，但是你需要自己编程处理这种remove掉一个tick的情况：4.终于有买家来了...500@90,这个价格是不会成交的，因为买家低于现在的最佳卖价：101，那么orderbook里面会继续存着这个order，同时会发送一个tick告诉市场上的其他人：有买单了：5.继续，接着有一位买家以101块钱买入1000股，等于要把目前的bestoffer1000@101给match-撮合了，那么你是不会收到这个最新的bid：101@1000的，因为它会进入matchingengine的瞬间跟对面的bestoffer撮合了，ticktable的一个规则：bidoffer永远不会cross，否则要么是数据商的bug，要么是交易所的bug。现在，你只会收到一个告诉你deletethebestoffer的message，那么ticktable长这样：Tick数据就是这么简单，市场上会重复这个过程。但是比较麻烦的是：很多时候tick的数据会以UDP发送，想象股市上如果交易非常活跃，那么数据量会非常大，UDP会存在丢包情况，如何处理。曾经遇到过很疯狂的tickupdate但是还要保持在xmicrosecond的更新cache，可能要排序（看交易所protocol），以及发送出去给前端。如何更快的处理实时的tick数据，否则数据量如此大，一旦延迟，以后就再也跟不上“实时”的节奏了，直到你的程序挂掉。如何避免一些特殊情况造成bug，一旦一个tick没有算对，那么后面的ticktable全是错的：）同样，还有对tick的理解问题：不同市场的tick还有不同点，上面所说的是发达国家的股票市场，以实时情况推送（有新的order并且在tick的发送level以内，比如东京交易所只发送8个ticklevel，那么你看不到整个fulltick的，因为可能会有100多个level，如果很多人交易的话）。但是国内是多少个millisecond截取一个快照（snapshot），然后发送给你，兴许是国内交易系统已经非常古老，跟不上IT的发展了。那么这个tick数据并不是“realtime”的，你只知道“哦！在前100millisecond和现在的tick变化是这样的”，可能中间已经成交了数千单。

上一条：上一篇：Google被全面封杀国内Nexus设备还能收到AndroidL的升级吗
下一条：下一篇：奥斯卡除了小金人还有啥所谓的大礼包都是什么东西

相关产品

相关资讯