一种多链路传输系统的制作方法

本发明涉及金融交易软件领域，具体涉及一种低延迟高可靠的高性能多链路传输系统。

背景技术：

金融交易软件本质上是一种流式处理系统，因此不可避免地会涉及到不同模块之间的数据流传输，模块之间的数据传输一般交由传输通信组件负责，也称为通信中间件。

传输通讯组件一般采用“发布-订阅”机制进行消息传输。典型场景如图1所示。图1所示的组件中包含：主题流、通道、发布端和订阅端。

主题流描述了消息的组织形式。在传输通讯组件中，每一个被传输的消息都必须有一个所属的主题，同一个主题下的各个消息形成了一个消息主题流。主题流内的消息是有序的，可以理解为是一类消息形成的队列。

数据传输需经过通信通道。根据不同机器之间的数据传输，通道可以分为tcp、udp广播、udp单播、udp组播四种类型。同台机器内的数据传输，除了可以使用上述四种通信通道外，还可以使用共享内存作为数据通信通道。

发布端也称为生产者，负责发布一个主题流。应用层产生新消息后，发布端将消息放入对应的主题流内，并负责将该主题流通过通信通道发送至订阅端。

订阅端也称为消费者，负责接收一个主题流。订阅端负责将订阅到的消息按照其原始发布顺序传递给应用层，一般需具备丢包检测能力。

由于金融交易软件低延迟、高可靠的特性，因此要求金融交易软件中的传输通信组件具备如下特点：

(1)低延迟。延迟衡量的是从发布端对外发送一个消息，到接收端确认该消息接收成功的时间，由于金融交易软件对系统内延时极为敏感，因此要求通信组件也具备较低的延迟。

(2)高可靠。对于发布端产生的消息，需保证接收端能有序接收，并提供丢包重传机制。

目前业界亟待开发满足上述要求的传输通讯组件。

技术实现要素：

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种多链路传输系统，可实现发布端支持多通道并行发布主题流，提升吞吐，降低整体延时，由于通信通道支持多种机制，使得同一主题流可同时并行使用多种不同类型的通道，提供丢包重传、心跳检测等机制保证数据的可靠传输；通过流控、包合并等机制降低消息延时。

本发明的技术方案为：本发明揭示了一种多链路传输系统，系统包括一个发布端、多个订阅端、多个通道和一个主题流，其中：

发布端用于执行一个指定主题流的发布任务；

通道用于发布端的任务发布和订阅端的消息接收；

主题流中存有主题流消息并将主题流消息通过多个通道并行发布给多个订阅端；

订阅端用于通过多个通道接收主题流消息，将接收到的主题流消息传递给应用层处理。

根据本发明的多链路传输系统的一实施例，通道支持的类型包括但不限于：支持tcp、udp广播、udp单播、udp组播、共享内存。

根据本发明的多链路传输系统的一实施例，发布端内维护一发布会话列表，发布会话列表中包括多个发布会话，发布会话列表中的发布会话与通道一一对应，其中发布会话配置为监听各自对应的通道上的主题流消息，同时将主题流消息发布到各自对应的通道上。

根据本发明的多链路传输系统的一实施例，订阅端内维护一订阅会话列表，订阅会话列表中包括多个订阅会话，订阅会话列表中的订阅会话和通道一一对应，其中订阅会话配置为处理各自对应的通道上的主题流消息。

根据本发明的多链路传输系统的一实施例，各个订阅会话运行在不同的线程实体内，各个订阅会话之间共享一个订阅主题流，订阅会话并行接收各通道上的主题流消息，并将接收到的主题流消息写入共享的订阅主题流中。

根据本发明的多链路传输系统的一实施例，多链路传输系统配置为订阅端在某一通道上发起主题订阅请求，发布端对应通道上的发布会话监听到该主题订阅请求后，根据该主题订阅请求中的订阅端节点号和订阅起始位置新建一个订阅端节点，发布端的该发布会话将新建的订阅端节点加入到该发布会话所维护的当前的订阅端节点列表中，其中订阅端节点列表中包括多个订阅端节点，订阅端节点是消息发布的基本单位，用于保存订阅端的消息；发布端还维护发布标识列表，发布标识列表由多个发布标识组成，每个发布标识对应一个订阅端，用于发布标识用于实时记录针对该订阅端的发布情况。

根据本发明的多链路传输系统的一实施例，如果一发布会话内不包含任何订阅端节点，该发布会话处于休眠状态且不进行数据发布，当有新的订阅端节点加入到该发布会话后，该发布会话被激活并开始进行消息发布；订阅端节点所保存的订阅端的消息包括但不限于：订阅端节点编号、当前发布位置、订阅端发布标识指针，订阅端发布标识指针用于记录每个消息对应的发布状态。

根据本发明的多链路传输系统的一实施例，多链路传输系统配置为发布端内维护一发布主题流，该发布主题流是一个线程安全的消息队列，由一系列消息构成，在该发布主题流中，每个消息都有一个唯一的消息编号，当应用层产生新消息后，发布端给该新消息分配一新的消息编号，并将该新消息放入到该发布主题流中。

根据本发明的多链路传输系统的一实施例，多链路传输系统中还配置为执行一发布任务的处理流程，发布任务是将一个消息发布到通道上，处理流程为：

在一次发布任务内，发布会话遍历各个订阅端节点来执行消息发布，在遍历过程中，对于每个订阅端节点，取出对应的订阅端发布标识指针和当前发布位置，同时清空发送缓冲区；

如果发送缓冲区未写满，发布会话根据当前发布位置持续读取流中的消息：如果当前发布位置已大于主题流的大小，将发送缓冲区的消息发送后结束该次发布任务；如果当前发布位置在订阅端发布标识指针中被设置为已发布状态，则跳过该消息；如果当前发布位置在订阅端发布标识指针中的状态为待发布，则将该消息放入发送缓冲区，并修改订阅端发布标识指针状态为已发布，其中在将该消息加入发送缓冲区前，发布端为该消息增加发布包头，发布包头内包含消息序号即当前发布位置、主题号、发布端编号信息；

如果发送缓冲区写满，则立即将发送缓冲区内的消息发送至通道内，结束本次发布任务。

根据本发明的多链路传输系统的一实施例，各个发布会话根据流量控制策略实时调整发送缓冲区的大小，寻找发布端与订阅端相匹配的传输速率的最大值作为流量控制。

根据本发明的多链路传输系统的一实施例，发布端的发布会话在将发送缓冲区的数据发送到对应的通道之前，先将发送缓冲区内的多个待发消息合并为一数据包一次性发送。

根据本发明的多链路传输系统的一实施例，订阅端的订阅会话在从通道接收到数据包后先进行校验，再将校验合格的数据包加入到订阅主题流中，如果校验到丢包则做丢包重传处理，其中数据包校验包括主题校验和序号校验，主题校验是检查收到的数据包内的主题号和订阅的主题号是否一致，序号校验是用于保证传递给应用层的消息的有序性。

根据本发明的多链路传输系统的一实施例，丢包重传配置为订阅端确认丢包范围后向发布端发送重传请求，重传请求的信息包括但不限于主题编号、订阅端编号、数据重传范围，发布端的发布会话收到重传请求后先解析重传请求，确认数据重传范围，再根据重传请求中的订阅端编号，取出对应的订阅端节点，在订阅端发布标识指针中将需重传的消息状态置为未发布，最后在发布任务中从主题流中读取消息时，优先读取并发布待重传的消息。

本发明对比现有技术有如下的有益效果：本发明具有如下的创新点：

(1)高性能多链路可靠传输通信组件支持多通道并行的“发布-订阅”机制。对于一个主题流，发布端可通过多个通道发布主题流的数据，接收端可接入多个通道收取主题流消息。提供线程池机制，发布端的各个发布会话可独立运行于不同的线程实体内，实现消息的并行发布；类似地，接收端的各个接收会话也可以独立运行于不同的线程实体内，实现消息的并行收取。对于多网卡的环境，可以在每个网卡上分配一个传输通道，充分利用多个网卡的传输能力，将数据发布的任务分摊到各个通道上，以提升整体吞吐，降低消息延时。

(2)提供订阅校验、丢包重传、心跳检测机制保证数据的可靠传输，通过流量控制、包合并机制提升消息发布速率。

(3)通信通道支持tcp、udp广播、udp单播、udp组播、共享内存等多种机制，同一主题流可同时并行使用多种不同类型的通道。通信通道的数量及类型可灵活配置。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了通信中间件的消息传输的原理。

图2示出了本发明的多链路传输系统的一实施例的结构图。

图3示出了本发明的多链路传输系统的一实施例中的发布端和订阅端的组成结构图。

图4示出了本发明的多链路传输系统的一实施例执行一次发布任务的流程图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图2示出了本发明的多链路传输系统的一实施例的结构。请参见图2，本实施例的系统包括：一个发布端、多个订阅端、为发布端配置的多个通道和一个主题流。

发布端用于执行一个指定主题流的发布任务。订阅端用于接收主题流下的消息。通道用于发布端的任务发布，支持tcp、udp广播、udp单播、udp组播、共享内存等通道类型，主题流中存有任务中的消息(以下称为主题流消息)并将主题流消息通过多个通道并行发布给各个订阅端。订阅端通过一个或多个通道接收主题流中的消息，将确认接收的消息有序传递给应用层处理。订阅端的数量不受限制。

发布端和订阅端的内部组成结构如图3所示。

发布端内部维护了一个发布会话(pubsession)列表，列表中包括多个发布会话，例如图示的发布会话1、发布会话2。列表中的发布会话的数量与通道的数量一致，每个发布会话对应一个通道。发布会话配置为监听各自的通道上的主题流消息，同时将主题流消息发布到该通道上。各个发布会话可运行在不同的线程实体内，发布会话之间共享一个发布的主题流对象，各发布会话并行读取发布主题流中的消息并将其发送至各自对应的通道。

订阅端内部维护了一个订阅会话(subsession)列表，订阅会话列表中包括多个订阅会话，订阅会话的数量等于订阅端接入的通道数量，每个订阅会话对应于一个通道，订阅会话配置为处理各自对应的通道上的消息(亦即数据)。各个订阅会话可运行在不同的线程实体内，订阅会话之间共享一个订阅主题流，订阅会话并行接收各通道上的主题流消息，并将确认接收的主题流消息写入共享的订阅主题流中。

订阅端启动后，根据配置的通道地址，通过各个通道向发布端发送主题订阅请求，主题订阅请求中带有订阅端节点号的标识。发布端的每个发布会话内维护一个订阅端节点列表，该订阅端节点列表由一系列订阅端节点(node)组成。订阅端在某个通道上发起了主题订阅请求，发布端对应通道上的发布会话监听到该主题订阅请求后，根据该主题订阅请求中的订阅端节点号和订阅起始位置新建一个订阅端节点，将新建的订阅端节点加入到当前的订阅端节点列表中。此外，发布端还维护一份发布标识列表，该发布标识列表由一系列的发布标识(pubflag)组成，每个发布标识对应一个订阅端，发布标识用于实时记录针对该订阅端的发布情况。

在图2所示的示例中，发布端注册了两个通道，生成两个发布会话。有三个订阅端订阅主题流，因此发布端的发布标识列表内有三个发布标识(pubflag)。例如，图2中的订阅端1只订阅了通道1，订阅端2和订阅端3都订阅了通道1和通道2。因此，发布会话1(pubsession1)中包含3个订阅端节点(node)，发布会话2(pubsession2)中包含2个订阅端节点(node)。

发布端内部维护了一个发布主题流，该发布主题流是一个线程安全的消息队列。在该发布主题流中，每个消息都有一个唯一的消息编号(seqno)，消息编号seqno从0开始递增。当应用层产生新消息后，发布端给这个新产生的消息分配一个新的seqno，并将该新产生的消息放入到该发布主题流中。

发布端的各发布会话pubsession独立进行消息发布。如果一个发布会话pubsession内不包含任何订阅端节点node，说明该通道上没有任何订阅端，因此该发布会话pubsession将处于休眠状态，不进行数据发布。当有新的订阅端节点node加入到该发布会话pubsession后，该发布会话pubsession被激活，开始进行消息发布。

消息发布的基本单位是订阅端节点node，发布端的订阅端节点node结构用于保存订阅端相关的信息，具体包括：(1)订阅端节点编号subid；(2)当前发布位置seqno：标识已向该订阅端发布的最大消息序号；(3)订阅端发布标识pubflag指针：pubflag是一个多线程读写安全的数组，用于记录每个消息对应的发布状态，包含“未发布”、“已发布”两种状态。发布端为每个订阅端维护了一个pubflag指针，订阅端node内保存的是对应于该订阅端的pubflag指针。

处于激活状态的发布会话pubsession在各自的线程循环内，持续执行发布任务。

本实施例的多链路传输系统的一次发布任务的执行流程如图4所示，发布任务是将一个消息(也称为数据)发布到通道上的过程。

在一次发布任务内，发布会话pubsession遍历各个订阅端节点node来执行数据发布。对于每个订阅端节点node，取出对应的订阅端发布标识pubflag指针和当前发布位置seqno，同时清空发送缓冲区。在发送缓冲区未写满的情况下，发布会话pubsession根据当前发布位置seqno持续读取流中的消息：如果当前发布位置seqno已大于主题流的大小，说明已发布至最新位置，此时将发送缓冲区的消息发送后可结束该次发布任务；如果当前发布位置seqno在订阅端发布标识pubflag中已被设置为“已发布”状态，说明其他发布会话pubsession已经发布了该消息，因此可跳过该消息；如果当前发布位置seqno在订阅端发布标识pubflag中的状态为“待发布”，说明该消息还没有被发布过，因此将该消息放入发送缓冲区，并修改订阅端发布标识pubflag状态为“已发布”。在将消息加入发送缓冲区前，发布端负责为消息增加发布包头，发布包头内包含消息序号seqno(即当前发布位置)、主题号、发布端编号信息。如果发送缓冲区写满，则立即将发送缓冲区内的消息发送至通道内，结束本次发布任务。

消息发布流程中的发送缓冲区大小并不是固定的，各个发布会话pubsession需要根据流量控制策略实时调整发送缓冲区的大小。

流量控制的主要目的在于找到发布端与订阅端相匹配的传输速率的最大值，从而既保证传输效率的最大化，又保证不会出现网络拥塞。传输速率与通道性能相关，不同通道的传输速率是不同的，比如通道a走万兆网卡，通道b走千兆网卡，则通道a的传输速率是通道b传输速率的十倍。考虑到传输速率不应该仅仅标识网络通道的网络容量大小，还应该能够标识应用层程序可以处理的消息量，因此将每秒传输的数据包的个数作为速率的计算指标。

发布端的发布会话pubsession使用慢启动方式来寻找最佳传输速率：给定一个初始速率，如果在该初始速率上没有丢包事件，则每隔固定的时间将速率升级为1.5倍；如果在当前速率上发生了丢包事件，则将当前速率降低为0.75倍。

发布端的发布会话pubsession中的发送缓冲区写满后，需要将数据发送到对应的通道内，本发明的多链路传输系统采用了包合并的机制进行数据发送。由于发布会话pubsession将数据发送到tcp/udp通道上时，需通过调用linux提供的系统调用接口来完成数据发送，而系统调用的执行次数越多，数据发送的延时就越大。因此，在实际发送数据时，发布会话pubsession执行系统调用前，先将发送缓冲区内的多个待发送消息合并成一个大数据包(不超过1024字节)，将合并后的数据包一次性发送，以减少系统调用次数，降低消息发送延时。

订阅端内部维护了一个订阅会话(subsession)列表以及一个订阅主题流。当各个订阅会话subsession从接入的通道内收到数据包后，会根据发布包头对数据包进行校验，将通过校验的数据包加入到订阅主题流中，并通知应用层有新消息可处理。数据包校验包括主题校验和序号校验两个阶段。

主题校验的目的是检查收到的数据包内的主题号和订阅的主题号是否一致，如果不一致则直接将该数据包丢弃。

序号校验的目的是保证传递给应用层的消息是严格有序的，如果检测到丢包事件则需进行丢包重传处理。假设当前收到的数据包的序号为k，订阅端已确认接收的主题流最大序号为n(预期下一个接收的数据包序号为n+1)：(1)如果k<n+1，说明当前消息已被确认接收，直接丢弃当前数据包(2)如果k>n+1，此时检测到丢包事件，丢包序号范围为[n+1,k-1]，将进入丢包重传处理，同时订阅会话subsession将当前收到的数据包放入接收缓冲区中(3)如果k＝n+1，说明当前接收的数据包是预期数据包，订阅会话subsession将其加入主题流中，并检测接受缓冲区中的数据包是否可确认接收。

如果通道类型为udp广播、udp单播或udp组播，由于udp协议本身不保证数据的可靠传输，因此需要通讯组件进行丢包检测与重传。如果订阅端的订阅会话subsession检测到了丢包事件，确认丢包范围后，将向发布端发送重传请求。重传请求包含主题编号、订阅端编号、数据重传范围等信息。

发布端的发布会话pubsession收到重传请求后将按如下步骤进行处理：(1)解析重传请求，确认数据重传范围；(2)根据重传请求中的订阅端编号，取出对应的订阅端节点node，在订阅端发布标识pubflag中将需重传的消息状态置为“未发布”；(3)在发布任务中，从主题流中读取消息时，优先读取并发布待重传的消息。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如dsp与微处理器的组合、多个微处理器、与dsp核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动盘、cd-rom、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在asic中。asic可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(dsl)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、dsl、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(cd)、激光碟、光碟、数字多用碟(dvd)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。