期货市场的主要功能是“价格发现”和“风险管理”。

其中价格发现是指期货市场的交易者（分多空头）根据自己收集到的影响市场的因素，判定价格走势，以真金白银在期货市场博弈，进而确定一个双方都认可的价格的过程。

为了保护参与者的积极性，期货交易所就要全方位，多维度地维护市场公平，涉及制度设计、风险控制、技术系统设计等方面。今天我们仅从技术系统设计方面，讨论影响公平性的一些因素。

1.应用软件层面

a) 指令接收(入口)

该部分影响公平性的核心问题是，如果多个会员的指令同时到达，先接收谁的？

现代化的期货交易一般采用电子交易系统，会员报单时需建立与交易网关的通信链路。交易网关通常是一个TCP的服务器，侦听在某个端口上等待会员连接。

交易网关侦听并接受一个新的TCP连接后，通常有三种处理方式：

• 采用多进程服务器模型：新建进程/线程专门处理该连接
• 采用select/poll多路复用模型：将套接字加入事件监控列表
• 采用epoll多路复用模型：将套接字加入事件监控列表

采用多进程服务器模型时，先接收哪个连接上的数据，主要取决于操作系统的进程/线程调度策略，软件层面无法干预(这其实是一种推脱责任的做法，把维护公平的职责由软件推给了操作系统-在某些企业中，操作系统通常是另外一拨人或者外部公司维护的)。

该模型优点和缺点都很明显，优点是软件层面的实现比较简单，缺点是容量十分有限：操作系统调度大量进程时，性能会急剧降低。另外，也不解决根本问题。

然后多路复用模型就出现了。多路复用是一种在同一个进程同时处理多个套接字的底层技术。应用进程可以设置一组套接字，交由select/poll这样的底层机制去检测。检测的结果通常是一组套接字都有事件发生，然后服务器再挨个检测到底是哪些套接字发生了哪些事件，然后再处理这些事件。

多路复用模型很好地解决了上个模型中进程数量过多的问题，但是又引入了两个新问题：

第一个：select/poll只给我们返回了一个就绪套接字数量，我们需要遍历套接字列表，找到到底是哪些套接字发生需要处理的事件了。而遍历策略选择不当就会影响公平性。例如如果你总是从头遍历到尾或从尾遍历到头，就会造成总是偏向于先收某条连接的问题。简单的处理方法比如这一遍先从前往后收，下一遍从后往前收等；复杂一点的比如引入一些随机机制、公平调度机制等。

第二个：不能一次性从某个连接收过多数据，最好是一个连接只收一包就转向下一个连接。不过这样一来，服务器就会花大量的时间去遍历列表，增加网关的单指令处理时延，降低整体吞吐量。

更好的选择是用epoll来代替poll，epoll向应用程序返回就绪套接字列表时，列表的排列顺序即为真实的套接字就绪顺序，与套接字何时建立，以及套接字句柄的数值大小无关（这一点未进行代码层面的验证，后续补上）。应用程序无需做公平性处理，顺序处理列表即可。

*事实上epoll还很好地解决了其他select/poll存在的突出问题，比如套接字列表拷贝，需要遍历列表等，今天我们主要探讨公平性问题，因此不再展开。

b) 指令处理路径

这指的是所有会员的交易指令是不是都是走同样的路径到达交易系统的。

据一些例子（虚构的，仅为说明问题）：

• 部分客户交易指令不经过会员端柜台系统直接进入交易所
• 部分客户有专用交易通道，可绕过交易网关直达撮合系统
• 部分客户的指令优先成交

c) 信息发布(出口)

首先应尽量做到单一出口，即只有一个信息发布通道。如果存在多个出口，要做到接入资格公平。即这个通道不是只为某些人开放，而是面向所有参与者开放，并且收费不能太离谱。很久之前发生过某些境外交易所伙同会员将高质量通道收费标准定得极其高，从而变相地提供专用通道的情况。

在单一通道内，则要采用公平性更好的发布技术，比如TCP就明显不如组播来的公平。但由于TCP应用起来比较简单，而且特别适合跨地域传输，因此还不能完全放弃。因此采用TCP的信息发布服务器（比如行情服务器）就有必要做公平性优化了。常见的优化手段有：

• 向一组会员发布一批同样的数据时，发送多轮，每轮仅发送一个数据包
• 向一组会员发布数据时，不采用固定的发送顺序：比如轮换从前往后发或从后往前发，或者引入随机机制等

2.操作系统平台层面

应用软件本身的公平性是一方面，运行应用软件的操作系统平台是另一方面。

这里举几个例子：

• 不同的操作系统，比如HPUX vs Linux，前者的条件变量唤醒时延极其稳定，大概在5微秒左右
• 同一操作系统的不同版本，比如Redhat 7相比Redhat 6在某些应用场景下的时延能降低数百微秒
• 通用操作系统版本 vs 低时延优化的操作系统版本，在时延极限以及抖动性方面都提升极大
• 不同编译器，比如在X86平台上，Intel C++编译器相比G++能凭空将软件的运行速度提升30%以上
• 同一编译器的不同版本，比如G++的老版本和新版本，性能差异也是很大的（没有具体数据）

3.硬件层面

硬件层面影响公平性的因素太多了，这里仅列出几个比较容易犯的：

a) 所在机房

一些交易所在同一城市往往有多个(托管)机房，如果这两个机房距离交易所的距离不同，那么速度也有会差异，而且非常明显。

b) 所在机柜

即使在同一机房，不同机柜到交易所系统的距离远近也会影响交易速度。不过现在一般业内都会采用等距光纤连接，即较近的机柜的服务器也会给你缠相同距离的光纤，这样交易速度就与所在机柜无关了。

c) 接入速率

铜线顶多千兆，光纤万兆起步，速度当然不一样。

d）交换机端口

即使两台机器插在同一台交换机上，速度都有可能不一样！以接收组播数据为例：

首先很多交换机在底层传输组播数据的时候并不是并发的，这是业内的共识，因此同一交换机不同端口接收到组播数据的时间是有先后的。

即使交换机是并发的，由于实际网络环境中，统一交换机通常要划分多个vlan，这样交换机往不同交换机传输组播数据的时候，就得一个个修改数据包中的vlanid，这样必然也会造成有先有后（交换机说：我太难了。。。）。

e）交换机层级

大型的数据中心往往网络结构比较复杂， 交换机要做各种堆叠之类的架构，如果前期网络规划不合理，后期修修补补不断调整，客户机器的网络层次就可能会有差异，这也会造成速度不同。