概述
随着金融市场行情数据量以及成交量的指数提升，如何提升交易速度，降低交易延迟，提高成交率，越来越成为交易所和各种金融机构需要面对的挑战。对于高性能和低延迟有需求的应用程序，大多采用分布式系统。在金融领域有很多这样的场景，包括交易所（Exchanges, ECNs）、自动交易系统、银行券商系统以及实时广告竞标平台等。

在分布式系统中，多个节点共同完成相应的计算，这些节点通过消息传递的方式进行通信和协作，随着节点数量增加，点对点，点对面的信息传递场景变得复杂。大多数系统都会采用消息中间件（Message-Oriented Middleware）来简化节点之间的通信架构。

消息中间件支持多种不同的通信方式， 常用的比较典型的是发布/订阅模型（Pub/Sub）。发布/订阅模型允许消息异步的广播到分布式系统的不同部分，并通过消息主题的方式支持异步的事件通知，发布者/订阅者可以同时向一个特定的消息主题生成/订阅消息，发布者只需向消息主题生产消息，一个或多个订阅者可以订阅该主题并接受对应的消息。

这种模型把消息的生产者和消费者的语意和身份定位标准化，明确了各自的功能和职责，结构清晰，便于开发。但是Pub/Sub结构的一个潜在问题是，当某个订阅者无法实时处理发布者生产的消息时，会导致发布者减慢消息发布，从而影响该主题的其他处理能力足够的订阅者，这是常见的拥堵原因：

对这种拥堵，有一种改良解决办法是使用代理程序或者消息中间构件，实现发布者和订阅者的解耦合。在许多基于发布/订阅模型的系统中，发布者将消息发给一个消息代理或者事件总线，订阅者向代理程序订阅消息，由代理程序处理消息过滤等功能。消息代理通常采用存储并转发的方式将消息从发布者送达订阅者，并根据订阅者的订阅速度进行速度匹配：

Pub/Sub或中间代理程序一般用在，多个消费者，同时有一个或多个生产者的的场景。对于一个生产者和一个消费者的模式，Pub/Sub消息系统一般会适配“消息直连模式”（无代理，常说的点对点模式），以实现消息直接从发布者送达订阅者。在这种模式下，消息按照发布者发出的顺序送给订阅者，为了提高速度，订阅者可以不返回消息的收件回执，因此消息是“短暂的，一次性”。如果订阅者不在线就收不到当前数据。而且当系统拥塞发生时，消息可能永久丢失。这会对系统的完备性造成很大的隐患。常见的解决办法是，有些系统会在消息直连路径，加一个旁路，用来作消息备份。存储节点可以解决消息丢失的问题，新上线或者较慢的订阅者可以通过存储节点获取未收到的消息：

除了Pub/Sub 模式，另一种使用较多的传输模式是消息队列（Message Queue）。消息发布者将消息发送到消息队列，订阅者通过访问消息队列获取订阅的消息，发布者和订阅者不需要同时与消息队列交互，从而实现异步的通信方式。发送到消息队列的消息在被订阅者读取之前会存储在队列中，队列消息可以放在内存中也可以持久化，以保证在消息服务出现故障时仍然能够传递消息。

消息队列本身是异步的，发布者和订阅者的时间耦合度和空间耦合度低。订阅者在消息发送很长时间后，可以再取回消息。这和大多数实时通信协议是不同的。当一个进程需要通知另一个进程发生了一个事件，但不需要等待回应，就可以用消息队列。但消息队列的异步要求接收者必须轮询消息队列，才能保持消息的及时性。消息队列的大小可以配置，消息的格式可以预先规定。开发和使用比较方便，但消息队列仍然有大小限制。消息堵塞的时候也要有复杂的应对机制。

多数的消息系统都能同时支持这两种模式，在竞争激烈的市场，参与者都希望能提高消息吞吐量并降低延迟。所以金融市场中的各个公司会运用各种最先进的软硬件技术来实现消息系统。消息系统技术栈的发展也经历了从常规的软件实现TCP，UDP和共享内存，到先进的Zero copy, Kernal Bypass ，到专用的InfiniBand，Solarflare，甚至硬件加速FPGA等技术升级和跳跃，性能也实现了量级的提高。

市场参与者——软件方案
消息中间件并不是一个新的技术，在金融行业中运用也有很多年了，最早的一个在金融领域被广泛运用的消息中间件产品是TIBCO Rendezvous——一个基于软件的低延迟消息总线。TIBCO Rendezvous采用基于主题的消息专递模式，由一个叫RVD（Rendezvous Daemon）的守护进程来接收发送到主题的消息，接收消息的节点向RVD注册感兴趣的主题，对应的消息就会被发送到接收节点。RVD支持发布/订阅，请求/回复，点对点以及多播等消息模式。

TIBCO在Rendezvous之后的升级产品叫FTL，是一个为实现高性能和低延迟而设计的，支持应用到应用的消息系统。FTL支持点对点消息，也支持消息代理的模式。FTL支持消息的可靠送达，支持基于内容的寻址的高级消息过滤功能。

一个2011年*（可惜没有最近的测试报告数据）Mellanox公司发布的测试报告可以提供一些TIBCO FTL 1.0的性能参数作为参考（延迟单位为微秒，micro second）:

基于TIBCO最近的数据，一个TIBCO FTL可以支持：
• 大于600万消息每秒
• 保证消息送达的情况下大于85万消息每秒
• 线程间通信延迟最低50纳秒
• 主机内通信延迟最低210纳秒
• 主机间通信延迟最低1.7微秒（基于InfiniBand和RDMA，16字节）

另外一个在金融领域非常流行的消息中间件产品是Informatica公司的Ultra Messaging（前身是29West）。该产品有三个版本分别针对不同的优化要求，其中持久版（Persistence Edition）保证消息永久保存，0延迟的故障转移，队列版（Queuing Edition）保证消息一次且仅有一次送达，流媒体版本（Streaming Edition，UMS）是针对低延迟应用设计，采用直接消息的模式。与当代的一些其他中间件产品不同的是，UMS没有一个中心的路由和监控守护进程，消除中心守护进程的瓶颈，以获取性能的提升。UMS支持TCP，可靠组播（reliable multicast），单播，共享内存（IPC）以及基于InfiniBand的通讯。

最新延迟性能应该有提高，但未能找到公开数据

开源软件方案

Java作为主要技术栈的公司有时会用Kafka作为消息总线。Kafka 也提供Pub/Sub模式，并且封装在各自主题里。虽然Kafka的设计不是用于高频，高并发的交易系统。但是因为Kafka开发，配置简单，可以集群使用，有多种语言接口和完善的社群支持。一些小公司初期也会用Kafka作为交易系统的主干，或者用于延迟不敏感的报警系统或者后台系统。随着技术升级，交易量增加，当延迟需求小于1毫秒的时候，就应该考虑替换Kafka系统，用其他高性能系统叠代升级。

有两个著名的的开源社区的消息系统值得提一下， ZeroMQ 和RabbitMQ。

Rabbit MQ实现了消息代理（Message Broker) ，数据收发需要经过MB。这种实现的优缺点前面已有讨论。值得一提的是, 如果对数据完整性需求高的项目，可以考虑用RabbitMQ，如果延迟需求比较高的项目尽量用ZeroMQ。
下图是RabbitMQ的结构示意图：

ZeroMQ的开发历史和支持团队比较有优势，用软件的方法实现Zerocopy，支持Pub/Sub，Request-reply等常用模式。ZeroMQ用C/C++语言开发，代码结构清晰，社区维护活跃，可以作为中小型项目的消息系统的开发平台，也可以作为Kafka系统的升级备胎。
 

一些大型交易所的解决方案
大型交易所在繁忙的交易时间内每秒处理数百万条消息，健壮且高性能的消息系统不仅对交易所系统至关重要，对所有投资者也都至关重要。一些交易所使用硬件和软件结合的解决方案来开发自己的消息传递系统，纽约证券交易所（New York Stock Exchange）的Pillar交易系统就是基于InfiniBand技术设计开发了自己的消息系统TXN。TXN支持Pillar Stream协议，从多个源通道接收流消息，并以极低的延迟传递给多个目标通道。TXN是位于交易系统中心的一个轻量级的消息定序器，它的唯一目的是将流消息尽快传递到下一个节点，同时提供可扩展性和可靠性。关于TXN的性能没有公开的信息，但是纽交所（NYSE/ARCA）每天会发布多达15亿条股票报价消息。（https://www.nasdaqtrader.com/trader.aspx?id=FullVolumeSummary）

TXN架构:

Monitor接收所有消息，并且如果任何接收方（例如目标B）发现消息出现乱序，则它可以从Monitor获取丢失的消息：

市场参与者——硬件方案
为了进一步提高消息中间件系统的性能，已经有厂商采用专用硬件技术，例如FPGA和网络处理器。其中一个市场领先的解决方案是Solace Systems的PubSub+设备，它是一种可机架安装的网络设备，在专用硬件中实现面向消息的中间件以及基于内容的路由功能。该公司声称，与基于软件的同类产品相比，在硬件中实现这些功能可实现更高的吞吐量和更低、更一致的延迟。

通过使用硬件，他们能够避免CPU资源限制和上下文切换，从而在性能上垂直扩展，每秒最多可处理数百万条消息。专用FPGA和网络处理器消除了对OS的需求，从而使延迟可预测。Solace PubSub+设备可以将所有消息连续复制到备用站点，并提供其状态，队列和配置，以实现非常快速的故障转移而不会丢失消息。

Solace发布的PubSub+设备的性能：

盛立事务定序器
盛立事务定序器是超低延迟分布式系统的消息总线的新实现，它是一个基于硬件的高性能、超低延迟消息传递系统，具有高度的可靠性。它运用所有消息到所有节点（all-messages-to-all-nodes）的方法，并支持可靠UDP协议的多播。

发布者/生产者生成的所有消息都被发送到事务定序器，事务定序器随后将以与接收到的消息完全相同的顺序发送消息，并加入序列号和准确的时间戳。

盛立事务定序器被设计为支持热备份，从而实现零延迟的故障转移，两个相同的事务定序器并行运行，它们接收相同的消息并为下一级的节点生成相同的输出，接收节点将仅接收传入的第一条消息，并丢弃重复的消息。FPGA的确定性特性确保主实例和次实例之间的延迟差异非常小。

实现这种系统有多种可能的方法，简单的方法是使用普通的网卡和软件，其延迟在几十个微秒范围内，并且由于CPU资源的限制而限制了吞吐量，通过内核旁路，可以将延迟降低到个位数微秒级别。一些高性能的网卡可以在这个基础上进一步提高性能，一个例子是使用支持efvi和TCPDirect API的Solarflare网卡，这样能够将延迟降至2us以下。

为了获得最低的延迟和最高的性能，盛立设计了基于FPGA技术的事务定序器。所有网络协议（MAC，TCP/IP等）和消息传递协议均使用专用的FPGA逻辑进行处理。

主要特点及性能：

• 支持1000万条消息每秒
• 支持10GbE
• 280纳秒穿越延迟
• 紧凑的数据包头为应用程序数据留出了更多的网络带宽
• 确定性的延迟性能，消息速率可饱和网络带宽
• 保证消息传递，消息不会丢失
• 没有单点故障
• 多个节点可以以热备的方式并行使用