CN102255794A - 远程消息收发吞吐量优化和等待时间缩短用系统和方法 - Google Patents

Abstract

远程消息收发吞吐量优化和等待时间缩短用系统和方法，该系统用于运行于远程节点上的进程间的进程间通信中的消息收发，包括：可通信地彼此耦连的至少两个主节点；可通信地与至少一个主节点耦连的至少一个订阅方/发布方节点；适于存储进程间消息的存储器；可由多个进程并行访问的共享内存中的至少一个存储缓冲区队列；插入进程间消息的写进程和异步地发送消息的远程发送进程，和同步地接收来自/到达队列的消息的远程接收进程；将至少一个进程间消息插入到远程接收节点存储的队列中；至少一个读进程，它使消息从远程接收节点上的队列中出列；适于指向队列中的空闲存储缓冲区的空闲指向元件；和适于指向包含进程间消息的存储缓冲区的数据指向元件。

Description

远程消息收发吞吐量优化和等待时间缩短用系统和方法

相关申请的交叉引用

本发明要求于2009年4月13日提交的名称为“A Messaging System”的共同待决的专利申请No.966/MUM/2009的权益，该专利申请的全部内容被本文引用，且该专利申请的公开内容通过引用被并入本发明中。

技术领域

本发明涉及消息收发领域，且更具体地涉及用于运行在至少两个远程节点上的至少两个进程之间的进程间通信中的远程消息收发的系统和方法。

背景技术

在通常处理非常高的作业量的某些应用中要求短等待时间的消息收发。算法交易是有望在不远的将来产生非常高的作业量的一个例子。随着计算加速的到来，处理器性能已提高。并行运行的多线程应用可以利用提高的处理器性能来进行并行计算，但是，顺序处理的应用却很少从提高的处理器核心得到益处。

交易应用通常是使用彼此间进行通信的多个进程实现的。这种通信在交易行业普遍被称作消息收发或短等待时间的消息收发。这表示消息收发设施(包括软件)应该能够处理非常大的作业量。非常大的作业量表示每秒超过百万个消息。

在交易应用中，进入命令是与现有命令匹配的。由于必须按到来次序严格处理消息，所以该应用的性质是非常有顺序的。通过对命令进行分类可以达到一定程度的并行，但是，这并没有排除对非常高的顺序处理的需要。当前的市场趋势已表现出每个服务器的CPU核心的数量随更新的产品版本而增加，但是各个CPU的顺序处理性能只表现出有限的改进。交易应用的进程可以运行于本地节点或者远程节点上。因此，希望消息收发系统既提供本地通信又提供远程通信。

然而，如果是为本地通信实现的现有消息收发系统则可能对远程通信表现不佳。而且，包括具有短等待时间和高吞吐量的基本需求的所述通信的重要方面使所述通信系统的重新设计成为必要。

因此，要不断考虑所述交易消息收发系统目前处理的作业量以及以后的预期作业量，就迫切需要能保证短的等待时间和优化的吞吐量的新方法。

根据部署架构，交易应用的进程可以运行于同一节点或分离节点上。所以，消息收发软件应该既支持本地通信又支持远程通信。

用于各个节点之间的进程间通信的现有消息收发系统采用锁定队列来缓冲收发消息，这最终会造成这些系统中的等待时间增加。

公开了用于提高单线程应用的计算性能以达到吞吐量优化和等待时间缩短的一些消息收发系统有：

Isfeld等人的US5828835教导了一种用于大量无连接协议的通信技术，其通过使用具有高优先级命令列表和普通优先级命令列表的用来传送消息的发送列表进程和接收列表进程，根据可以控制发送等待时间的队列优先级规则来控制消息发送的等待时间和可靠性。要求短等待时间的消息被写入高优先级发送列表中，而大多数消息被写入高吞吐量发送列表或普通优先级发送列表中。接收处理器中的接收过滤进程包括调度逻辑，该调度逻辑基于消息报头中的控制位将消息调度到高优先级接收列表或者普通优先级接收列表。虽然Isfeld等人提供了用于消息通信的发送列表和接收列表，但是它采用多个队列来容纳具有不同优先级和状态的消息。以这样的多队列实现方式达到的吞吐量优化和等待时间缩短对于增加的作业量则是不可能的。解决的问题具体涉及在发送的中间阶段中的一个阶段(即在桥或路由器上实现的)的路径优化过程中而非源和目的地的优化过程中的消息的等待时间缩短和吞吐量提高。所述实现方式还包括构造特定硬件，但其没有教导商用硬件或现有系统的优化。

Nageswar等人在文献“HiPerFS：A Framework for High Performance FinancialServices using Advanced Message Queuing”中教导了一种以提高的并行性处理财务计算/业务的通用分布式框架(通过消息收发)，其使用具有并行处理的异步消息收发来加速财务计算。该项研究包括由于在AMQP下的或在其它消息收发应用层诸如ZeroMQ中的等待时间造成的吞吐量边界限制。ZeroMQ框架(消息收发平台)公开了一种用于实现每秒最大吞吐量为56,000个消息的交易系统的系统，每个消息为100字节。尽管通过Nageswar等人的教导，吞吐量增加了，但是，仍然存在要用更大的消息大小来满足增加的作业量的问题。(http://wwwl.cs.columbia.edu/～gms2155/projectspring2009/Project2b.pdf)

因此，根据上文提到的背景技术，很明显需要一种系统和方法，它能：

●提供高吞吐量、短等待时间的消息收发技术以用于在至少两个节点上运行的至少两个进程之间的进程间通信；

●增强消息收发系统的吞吐量优化；

●缩短消息收发系统的等待时间；

●需要最少设施；

●降低硬件安装成本，以提高吞吐量，并缩短消息收发系统的等待时间；以及

●易于配置在现有系统上。

发明内容

在描述本发明的方法、系统和硬件实现之前，应理解本发明并不限制于所描述的特定系统和方法，因为可以有未明确示出在本公开中的本发明的多种可能的实施方式。还应理解本说明书中使用的术语只是为了描述特定的形式或实施方式，而非旨在限制本发明的范围，本发明的范围仅由所附权利要求书来限制。

在通常的本地进程间消息收发中，发送进程和接收进程运行于一个节点上，这些进程对处理器的共享内存中存储的内存映射文件进行处理。在远程进程间消息收发的情况下，内存映射文件和相关队列的操作明显不同于本地进程间消息收发。更特别的是，在远程消息收发中，发送进程和接收进程运行于不同的节点上，并对多个处理器的共享内存中存储的内存映射文件中存储的队列进行处理。

本发明设计了一种用于运行于远程节点上的进程之间的进程间通信中的消息收发的系统。

在本发明的优选实施方式中，一种用于运行于至少两个节点上的至少两个进程之间的进程间通信中的消息收发的系统，包括：

a)可以访问该系统的主内存的至少两个主节点，它们之间通过至少一个网络接口卡(Network Interface Card，NIC)端口彼此可通信地耦连；

b)至少一个订阅方/发布方节点，其与至少一个主节点可通信地耦连；

c)适于存储进程间消息的存储器；

d)在所述存储器的共享内存中的存储缓冲区的至少一个循环链接列表队列，其可被多个进程并行访问；

e)运行于远程发送节点上的至少一个写进程，其将至少一个进程间消息插入所述队列中，从而更新空闲指向元件；

f)运行于远程发送节点上的至少一个远程发送进程，其异步地发送来自所述队列的至少一个消息；

g)运行于远程接收节点上的远程接收进程，其同步地接收至少一个进程间消息，并将其插入到该远程接收节点的共享内存上存储的队列中；

h)具有唯一指定的数据指向元件的至少一个读进程，它使来自所述远程接收节点的共享内存上存储的队列的消息出列，从而更新所述数据指向元件；

i)与适于指向所述队列中的空闲存储缓冲区的进程关联的空闲指向元件；以及

j)与适于指向包含进程间消息的存储缓冲区的进程关联的至少一个数据指向元件。

通常，在本发明的重要实施方式中，该系统包括分别适于更新空闲指向元件和数据指向元件的位置的写进程手段和接收进程手段。

所述进程运行于每个节点中，每个节点具有多核心的处理器。每个节点上每个处理器的高速缓存是共享的，并存储包含消息缓冲区的队列的内存映射文件。高速缓存的共享内存位于每个本地主节点和远程主节点上，适于具有非一致的内存访问。远程节点上运行的进程通过适于促进进程之间连接的通信链路发送和接收消息，并选自由TCP/IP连接、GPRS连接、WiFi连接、WiMax连接和EDGE连接组成的组。

参与进程间消息收发的每个主节点具有运行的读进程和写进程，用以将消息插入到存储于共享内存中的队列中和从队列中提取消息。设置检查手段，以检查队列对于写/插入操作是否是满的，并检查队列对于读/提取操作是否是空的。该检查手段是通过队列的相关标志(即指向空闲数据缓冲区的空闲指向元件和指向数据缓冲区的数据指向元件)而起作用的。

根据本发明的一个优选实施方式，队列包含于文件中，且队列的大小被调整以使得能够将所述文件存储在每个节点的处理器的共享内存中。

优选地，文件被映射到多个处理器的主内存空间中。

在本发明的另一个重要实施方式中，提供一种用于运行于远程节点上的进程之间的进程间通信中的无锁消息收发的方法，该方法包括：

a)提供存储器，以存储进程间消息；

b)在可被多个进程并行访问的所述存储器的共享内存中，设置至少一个存储缓冲区的队列；

c)提供写/读进程，用于将消息插入到所述队列和从所述队列提取消息；

d)提供发送进程和接收进程，用于发送、接收所述队列中存储的所述消息；

e)提供与每个进程关联的空闲指向元件，以指向所述队列中的空闲存储缓冲区；

f)提供与进程关联的至少一个数据指向元件，其指向包含所述进程间消息的所述存储缓冲区；

g)提供可通信地彼此耦连的至少两个主节点；

h)提供可通信地与至少一个主节点耦连的至少一个订阅方/发布方节点；

i)从运行于至少一个主节点上的至少一个进程接收至少一个进程间消息；

j)将所接收的进程间消息插入到由所述空闲指向元件指向的所述队列的存储缓冲区中；

k)将空闲指向元件的位置更新到所述队列的下一空闲存储缓冲区，以容纳下一个进程间消息；

l)通过运行于第一主节点上的远程发送进程，异步地发送来自所述队列的至少一个进程间消息；

m)通过运行于第二主节点上的远程接收进程，同步地接收至少一个进程间消息；

n)将所接收的消息插入到第二主节点上的共享内存的队列中；

o)通过多个进程同时从由相应的数据指向元件指向的第二主节点的所述队列的所述存储缓冲区中取出进程间消息；以及

p)将所述数据指向元件的位置更新至包含待由每个读进程读出的消息的下一存储缓冲区。

通常，队列适于以无锁模式工作，且将消息插入到消息缓冲区和更新空闲指向元件是互相独立的进程。

根据本发明的一个优选实施方式，写进程为：检查所有读进程的数据指向元件以确保队列是空闲的，在消息插入后，检查空闲指向元件是否指向至少一个读进程的数据指向元件，并将消息拷贝到由空闲指向元件指向的消息缓冲区中，并更新空闲指向元件以指向下一个消息缓冲区。

根据本发明的一个优选实施方式，主内存是以进程执行次序被顺序更新的，在更新空闲指向元件之前，至少一个新消息被插入主内存中。

根据本发明的另一方面，提供一种用于运行于远程节点上的进程之间的进程间通信中的消息收发吞吐量优化的系统，该系统包括：

a)可通信地彼此耦连的至少两个主节点；

b)可通信地与至少一个主节点耦连的至少一个订阅方/发布方节点；

c)适于存储进程间消息的存储器；

d)可被多个进程并行访问的所述存储器的共享内存中的至少一个存储缓冲区队列，

e)运行于第一节点上的写进程，其将至少一个进程间消息插入所述队列中，

f)运行于所述第一节点上的远程发送进程，其异步地发送来自所述队列的至少一个进程间消息；

g)运行于第二节点上的远程接收进程，其同步地接收至少一个进程间消息，并将其插入到所述队列中，远程接收方充当远程主机中的发布方；

h)至少一个读进程，其使来自所述队列的消息出列；

i)单个非阻塞远程发送进程和远程接收进程，它们发送和接收分块(bulk)消息；

j)与适于指向所述队列中的空闲存储缓冲区的进程关联的空闲指向元件；以及

j)与适于指向包含进程间消息的存储缓冲区的进程关联的至少一个数据指向元件。

通常，每个远程发送进程在发送来自所述队列的分块消息之前，在所述队列中保留数据缓冲区用于读消息，并在向至少一个远程主节点发送所述消息之后，更新循环队列的数据指向元件，指示所述消息缓冲区是释放的，消息已经读出。

根据本发明的一个优选实施方式，数据指向元件指令所述读进程从存储缓冲区读出进程间消息以用于接收该进程间消息。

根据本发明的一个优选实施方式，单个非阻塞远程发送进程和远程接收进程根据可用的空闲缓冲区发送和接收分块消息，发送的和接收的消息通过各自进程的返回值确认。

上面所述系统和方法优选是财务交易系统，但也可用于其它许多应用。

附图说明

结合附图进行阅读能更好地理解前面的发明内容以及下文对优选实施方式的详细描述。为了图解说明本发明，在附图中示出本发明的示例性结构；但本发明并不限制于所公开的特定方法和系统。附图中：

图1图解说明在共同待决的申请No.966/MUM/2009中公开和要求保护的发明中，用于在至少一个节点上运行的至少两个进程之间的进程间通信中的消息收发的本地通信机制；

图2示出在共同待决的申请No.966/MUM/2009中公开和要求保护的发明中的内存映射文件布局；

图3示出用于在具有远程订阅方和本地订阅方的发布订阅队列中的消息收发的系统和方法；

图4示出根据本发明的各个实施方式的测试硬件安装；

图5示出根据本发明的各个实施方式的用于吞吐量测试的软件部署；

图6示出针对各消息大小在调整之前的吞吐量测试中测得的吞吐量结果；

图7示出根据本发明的各个实施方式的内存映射文件的新设计布局；

图8示出针对各消息大小在优化后在吞吐量测试中测得的吞吐量结果；

图9示出根据本发明的各个实施方式的等待时间测试设置；

图10显示调整之前和调整之后的网络使用结果；

图11示出随着队列大小变化的吞吐量和等待时间的变化；

图12示出等待时间如何受到进入消息的速率的影响；

图13示出使用定制构建队列(Custom Built Queue，CBQ)构建的样本交易系统架构。

具体实施方式

下面详细论述阐释了本发明特征的一些实施方式。词语“包括”、“具有”、“含有”和“包含”及其各种形式在意思上是等同的、是开放式的，因为跟在这些词中任何一个之后的一项或若干项不表示这一项或这些项的详尽列表，也不表示仅限制于所列的一项或若干项。还必须注意的是，如本文及所附权利要求书中使用的，单数形式的“一个”、“一”和“该”包括多个指代，除非上下文清楚指出并非如此。尽管在实践或者本发明的实施方式的测试中可以使用与本文描述的那些系统和方法等同的任何系统和方法，但是下面描述的是优选的系统和方法。公开的实施方式只是本发明的示例，其可以各种形式体现。

定义：

吞吐量：每秒钟来自队列的读或写操作的消息数量被称作吞吐量。

等待时间：在发送进程发送消息和接收进程接收该消息之间过去的时间为该消息经过的等待时间。

定制构建队列(CBQ)：本发明已经通过使用POSIX线程[RICH2005]库中可用的锁定，基于内存映射文件，实现了共享内存IPC机制，其被称作定制构建队列(CBQ)。

本公开内容由在共同待决的申请No.966/MUM/2009中公开和要求保护的用于处理消息的机制来支持，本文将它称为“定制构建队列(CBQ)”。队列存储在存储缓冲区中，由用户化技术优化；所述队列优化技术和相关的实现方式形成本发明的主要实施方式。

图1图解说明在共同待决的申请No.966/MUM/2009中公开和要求保护的发明中，用于在至少一个节点上运行的至少两个进程之间的进程间通信中的消息收发的本地通信机制。用于在至少一个节点上运行的至少两个进程之间的进程间通信的CBQ基本本地机制是内存映射文件。发送进程S将消息拷贝到该文件中，接收进程R从同一文件中读出该消息。进程S和进程R也被称作应用进程。

图2示出在共同待决的申请No.966/MUM/2009中公开和要求保护的发明中的内存映射文件布局。它包含静态循环消息队列。文件中的每个消息结构具有空闲指向元件和数据指向元件。数据指向元件包含通过应用传送的原始消息。它还被称作消息缓冲区。空闲指向元件包含一些控制信息。存储消息的缓冲区是固定大小的，其最先在创建CBQ的实例时被指定。空闲指向元件和数据指向元件用来以先进先出(First In First Out，FIFO)次序(图中未显示)从队列中增加、删除项目。基本CBQ qread()和qwrite()函数具有memcpy()调用，作为它们操作的一部分，并且所述qread()和qwrite()函数分别指内存映射文件上的读写操作。

用于CBQ的基本通信机制的新方法是无锁实现方式。所述无锁通信可行的原因仅在于在任何情况下，同一进程不会更新两个变量。在此情况下，只有发送进程操作空闲指向元件，且只有接收进程操作数据指向元件。

在通常的本地进程间消息收发中，发送进程和接收进程运行于一个节点上，对处理器的共享内存中存储的内存映射文件进行处理。在远程进程间消息收发的情况下，内存映射文件和相关队列的操作明显不同于本地进程间消息收发。更具体地，在远程消息收发中，发送进程和接收进程运行于不同的节点上，并对多个处理器的共享内存中的内存映射文件上存储的队列进行处理。

本发明设计了一种用于运行于至少两个不同的节点上的至少两个进程之间的进程间通信中的消息收发的系统。

图3示出用于在具有远程订阅方和本地订阅方的发布订阅队列中的消息收发的系统和方法。用于在两个不同的节点上运行的发送进程和接收进程之间的进程间通信的消息收发的系统。在本发明的一个示例性实施方式中，所述系统包括一个发布方节点和两个远程订阅方节点。所述的节点通过TCP/IP连接可通信地彼此耦连。根据本发明的一个实施方式，各节点通过从GPRS连接、WiFi连接、WiMax连接和EDGE连接的组中选择的一种连接彼此连接。

上文所述的发布方节点包括写入本地共享内存的一个本地发布方/发送进程S，以及从所述共享内存读取并写入TCP/IP连接的远程发送RS，其中，具有内存映射文件队列的所述本地共享内存具有用于存储进程间消息的存储区。

所述远程订阅方节点包括从远程共享内存读取的一个读进程R以及从所述TCP/IP连接读取并写入该远程共享内存的远程接收RR，远程共享内存具有存储缓冲区队列，其中，所述远程共享内存具有内存映射文件队列以用于存储消息。

下面解释用于运行于两个不同的节点上的至少两个进程之间的进程间通信的CBQ远程机制。首先，在发布方节点上的发送进程S通过使用写进程将进程间消息拷贝/插入到本地共享内存中的内存映射文件队列中，本地订阅方和远程发送RS通过使用读进程从同一文件读/取消息。

所述内存映射文件包含静态循环消息队列。文件中的每个消息结构具有空闲指向元件和数据指向元件。数据指向元件包含指向待读出的下一消息的指针。它还被称作消息缓冲区。空闲指向元件指向存储要被插入的下一消息的缓冲区。存储消息的缓冲区是固定大小的，其最先在创建CBQ的实例时被指定。空闲指向元件和数据指向元件用来以先进先出(FIFO)次序(图中未显示)从队列中增加、删除项目。基本CBQ qread()和qwrite()函数具有memcpy()调用，作为它们操作的一部分，并且所述qread()和qwrite()函数分别指内存映射文件上的读写操作。所述写进程更新空闲指向元件，读进程更新数据指向元件。

所述内存映射文件队列包含存储缓冲区的循环链接列表。所述读/写进程具有检查手段，以检查队列对于写/插入操作是否是满的，并检查队列对于读/取操作是否是空的。远程发送RS从内存映射文件队列中读消息，并写它自己的缓冲区，通过TCP连接异步发送给远程订阅方节点。远程接收节点上运行的远程接收进程同步接收至少一个进程间消息并将其插入到远程接收节点的共享内存上存储的队列中。

远程接收RR中的读进程使远程接收节点的共享内存上存储的队列中的消息出列。所述两个远程订阅方的节点有远程接收RR进程运行，这构成TCP连接的另一端。在每次重复(iteration)过程中，远程发送RS等待下一个消息在内存映射文件中准备就绪。只要读出消息(qread()函数)，就以阻塞模式通过TCP连接使用UNIX send()系统调用发送该消息。

固定有效载荷区域的全部内容作为单个消息发送，其中，文件中的消息结构具有空闲指向元件和数据指向元件。数据指向元件包含指向待读出的下一消息的指针。它还被称作消息缓冲区。空闲指向元件指向要存储待被插入的下一消息的缓冲区。数据指向元件是固定大小的，其最先在创建CBQ的实例时被指定。远程接收RR等待来自TCP连接的一个固定大小的消息，只要读到完整的消息，它就将该消息插入(qwrite()函数)到远程订阅方节点上的内存映射文件中。一个或更多个远程订阅方从该内存映射文件中读消息。不管发送进程和接收进程是否运行于相同主机或远程主机上，发送进程S和接收进程R都读、写内存映射文件。

空闲指向元件与适于指向所述队列中的空闲存储缓冲区的进程关联，数据指向元件与适于指向包含进程间消息的存储缓冲区的进程关联。

该架构的好处是其异步特性。发送进程不需要等待TCP发送消息完成。同样，接收进程也不需要等待读TCP连接中的下一消息。分离节点上的逻辑通信链路被称作远程CBQ。同样，同一节点上发送进程和接收进程之间的通信被称作本地CBQ。用于远程通信的传输机制选择TCP/IP。已经发现在高速网络中使用TCP/IP的等待时间少于100微秒。这足以用CBQ实现端到端的等待时间少于1毫秒的高端交易系统。

根据本发明的一个实施方式，共享内存位于每一本地主节点和远程主节点上，每个所述主节点适于以非一致内存访问的方式访问所述共享内存，每个主节点适于访问其主内存。

每个主节点适于具有以睿频加速(turbo boost)模式运行的处理器核心，其中，调整处理器时钟频率，使核心以更高的工作频率运行。每个主节点通过至少一个网络接口卡(NIC)端口与其它主节点可通信地耦连。两个NIC端口适于具有一个发送中断和多个接收中断，同时插入/取出本地共享内存以及远程共享内存中的内存映射文件队列中的消息。给接收TCP流上的进程间消息的每个主节点分配与所述TCP流关联的一个接收中断，每个读进程适于具有唯一指定的数据指向元件。

从发送进程S到接收进程R的消息采用的路径如下：

·发送进程将消息插入本地共享内存消息队列，是使用内存映射文件的无锁实现方式。

·运行于与发送进程S相同的机器上的CBQ远程发送进程RS从所述消息队列中使该消息出列，并将它发送到运行在远程订阅方节点上的远程接收进程RS。

·运行于远程订阅方节点中的CBQ远程接收进程RS接收该消息，并将其插入到远程共享内存消息队列中。

·接收进程R使所述消息队列中的该消息出列。

在图3中，带圆圈的数字代表消息收发的步骤。如果有多个相同数字的圆圈，则表示步骤是并行进行的。这种实现方法能很好地分配资源，即TCP连接、发送和接收进程以及内存映射文件。

根据本发明的一个实施方式，每个读进程适于具有唯一指定的数据指向元件。进程间消息的插入和取出适于无锁操作，其中，一个进程基本更新与其关联的一个指向元件。通过使写进程将消息插入在由所述空闲指向元件指向的所述空闲存储缓冲区，并使至少一个读进程读包含进程间消息的存储缓冲区中存储的、由所述数据指向元件指向的插入消息，无需锁定队列，每个写进程适于将消息异步地插入到所述队列中的所述存储缓冲区中，每个读进程适于同步地从所述队列中的所述存储缓冲区中取出消息。

内存映射文件队列包含于文件中，其中，调整每个队列的大小，使得能够将所述文件放在每个节点的处理器的共享内存中，队列中的所述存储缓冲区通过空闲指向元件被链接到下一存储缓冲区，最后一个存储缓冲区链接到第一个存储缓冲区，形成循环链接列表，用以将所有的进入消息一个接一个地存储到存储缓冲区中。每个读进程具有关联的单独数据指向元件，每个写进程(发布方)反复检查每个读进程的数据指向元件的状态。

根据本发明的一个实施方式，发送进程对空闲指向元件和数据指向元件所做的更新可被接收进程并行访问，接收进程所做的对数据指向元件的更新可被发送进程并行访问，其中，拷贝每个消息到消息缓冲区和从消息缓冲区中拷贝出每个消息在数据指向元件和空闲指向元件的更新之后进行。

用于CBQ的基本通信机制的新方法是无锁实现方式。所述无锁通信可行的原因仅在于在任何情况下，同一进程不会更新两个变量。在此情况下，只有发送进程操作空闲指向元件，且只有接收进程操作数据指向元件。

根据本发明的一个实施方式，每个节点的所述内存映射文件的所述队列适于在无锁模式下起作用，其中将消息插入到消息缓冲区和更新空闲指向元件是独立的进程，发送进程和接收进程是在两个不同的主节点上被分开编译的，发送进程与数据指向元件的相关性、接收进程与空闲指向元件的相关性是通过两个分立的编译进程并行组织建立的。

根据本发明的另一个实施方式，互相独立的读进程和写进程的单独并行编译通过编译器开关实现，写进程异步地将消息插入到主节点的共享内存存储的队列中，其中具有空闲指向元件的共享内存中为空闲的一个或者更多个进程被刷新(flush)到主内存中。

根据本发明的一个实施方式，其中多个读进程运行并从队列中读消息，而共享内存中并没有多个消息拷贝，其中如果每个读进程已经读过消息，且其状态通过每个读进程各自的数据指向元件指示，则消息被认为是读出的(或出列的)；并且其中写进程检查所有读进程的数据指向元件以确保队列是空闲的，检查在消息插入到其中之后，空闲指向元件是否指向至少一个读进程的数据指向元件，并将消息拷贝到由空闲指向元件指向的消息缓冲区中，并更新空闲指向元件以指向下一个消息缓冲区。

根据本发明的另一个实施方式，主内存是按进程执行次序被顺序更新的，在更新空闲指向元件之前，一个新消息被插入主内存中。

图4示出根据本发明的各个实施方式的测试硬件安装。在本发明的一个示例性实施方式中，借助下文的硬件安装和实现方式来解释运行于两个不同的节点上的至少两个进程之间的进程间通信的CBQ远程机制。Nehalem-EP服务器(此后称作EP服务器/发布方节点)具有以下配置：

2个英特尔至强(Intel Xeon)X5560插口

·每个插口具有能够实现同步多线程的8个2.8GHz的核心

·每个插口的高速缓存-8MB

·RAM-8GB，DDR31066MHz

Nehalem-EX服务器(此后称作EX服务器/远程订阅方节点)具有下列配置：

·4个英特尔至强X7750插口

·每个插口具有能够实现同步多线程的16个2.0GHz的核心

·每个插口的高速缓存-24MB

·RAM-64GB，DDR31066MHz

EX和EP服务器基于非一致内存访问(Non-Uniform Memory Access，NUMA)模型。每个节点是具有多个CPU核心并在该插口的多个CPU核心上共享内部高速缓存的插口(或数据包)。每个节点还具有用于其自身的、直接由该节点访问的一些主内存。如果此节点需要访问另一节点的内存，则可能需要超过1次的跳转，因此内存访问等待时间会增加。

EX服务器和EP服务器共同具有下列特征：

·在BIOS中实现的Turbo模式-Turbo模式，也称作睿频加速(Turbo Boost)，在某些条件下，可以使处理器核心运行得比基本工作频率更快。如果处理器在低于额定功率和热极限下工作，则Turbo模式可通过提高CPU时钟频率来提高性能。

·BIOS中的NUMA设置关闭，这表示主内存在各个节点上交织。如果该选项开启，则变化是内存访问等待时间的更短。

·操作系统：64位Linux，在EP服务器上内核为2.6.18-164.6.1.el5，在EX服务器上内核为2.6.18-164.el5。

·NIC-带82598EB控制器的英特尔AF-DA双端口适配器

·两个10Gbps端口都连接到Cisco Nexus 5000 10Gbps交换机

·NIC驱动器-2.0.44.14-NAPI

·NIC固件版本-1.7-0

·NIC总线-PCIE v2x8

·所有端口上的NIC MTU-1500字节(缺省)

·所有的物理网络连接都使用SFP线缆

两个服务器上的NIC端口被称作NIC端口1和NIC端口2。两个服务器上的NIC端口1属于相同的子网络。两个服务器上的NIC端口2属于相同的子网络，但与端口1使用的子网络不同。

两个NIC端口都具有一个发送Tx中断和多个接收Rx中断。在测试过程中，只使用Rx中断中的一个中断，并给每个TCP流分配1个Rx中断。因此，很难提前预测会使用哪个Rx中断，但一旦分配后，就会在TCP流的存在期间，一直保持该分配。

两个NIC端口具有下列联合的中断设置

·rx-usecs-在接收数据包之后，使RX中断延迟的最大微秒数。对两个服务器上的NIC端口，该数都设置成125。

·tx-frames-irq：在一个中断中要处理的数据包的最大数。对两个服务器上的NIC端口，该参数都设置成1024。

所有其它的联合参数设置成0。联合参数Adaptive TX和Adaptive RX设置成关闭。

图5示出根据本发明的各个实施方式的用于吞吐量测试的软件部署。进行吞吐量测试的目的是观察通过远程CBQ可以达到的最大吞吐量。发送进程S运行于EP服务器上，接收进程R运行于EX服务器上。名称RCBQ用来指逻辑远程CBQ链路。在EP服务器上，S进程和RS进程被仿射到同一插口的分离的核心。类似地，在EX服务器上，R进程和RR进程被仿射到同一插口的分离的核心。S进程只是在每次重复中使用qwrite()函数调用来发送新消息。R进程在每次重复中使用qread()函数调用来读新消息。两个函数调用都是阻塞性质的-即如果内存映射文件中没有空间(例如队列是满的)，则qwrite()函数阻塞。如果在内存映射文件中没有准备就绪可被读出的消息(队列是空的)，则qread()函数阻塞。吞吐量是通过分离的统计进程测量的，统计进程测量在固定的时间间隔内在任一内存映射文件中的qread()的数量。而且还使用Linux工具atop测量NIC端口1和NIC端口2的网络利用。在测试过程中消息大小是变化的，以测量每秒的消息的吞吐量。

图6示出针对各消息大小在调整之前的吞吐量测试中测得的吞吐量结果。单位为消息/秒的吞吐量会随消息变大而降低，但单位为Gbps的网络吞吐量会增大。这是因为消息越大，排队开销的百分比会越小。网络利用还包括TCP/IP开销。注意网络利用不会上升超过9Gbps。

结果分析

注意：基于上述结果，应注意到对于小的消息大小，不可能达到线速。这是因为目前的CPU每秒只可以处理有限数量的send()系统调用，而与消息大小不太相关。考虑到CBQ的远程消息收发架构，应注意到影响远程发送RS进程和远程接收RR进程的性能的下列几点。

1、在应用级，每个消息有两个消息拷贝。一个通过qread()/qwrite()函数，另一个通过send()/recv()系统调用。

2、对TCP send()系统调用，采用同步调用，以通过远程发送RR进程发送消息。一个消息发送包括一个循环内的send()系统调用，循环运行直到完整消息被发送。尽管没有明显提到循环，但为了获得功能正确性需要有循环。在最佳情况下，循环只执行一次。接收进程用recv()系统调用接收一个消息也是这种情况。

3、已经指出，要求每秒钟有大量的send()系统调用，以得到具有小的有效载荷大小的消息，来填充10Gbps的网络管道。

根据本发明的各个实施方式，在至少两个节点上运行的至少两个进程之间的进程间通信中的吞吐量优化可通过以下方式进行：

a)减少消息拷贝

以远程发送RS进程为例。对于每次重复，执行qread()函数，以将内存映射文件中的消息拷贝到其自己的缓冲区中。然后，该缓冲区被转到send()系统调用。它们一起构成两个消息拷贝。如果指向内存映射文件中的消息的指针被直接转到send()系统调用，则可省略中间缓冲区。这样可以省掉一个消息拷贝。

为了能够减少消息拷贝，必须为内存映射文件访问开发新的API。必须引入两个新的函数来从内存映射文件中读数据。reserve_read()函数返回指针指向内存映射文件中的消息缓冲区。release_reserve_read()函数更新循环队列的尾指针，以表示已经读出消息，且内存映射文件中以前保留的消息缓冲区被释放。远程发送进程用三个步骤来处理每个消息：

1、reserve_read()

2、send()

3、release_reserve_read()

尽管运算次数增加了，但对于发送进程S，消息拷贝的数目已经减少了。

类似地，对于远程接收RR进程，借助中间缓冲区存在recv()调用和qwrite()函数，这产生两个消息拷贝。同样，API中已经引入两个新函数reserve_write()和release_reserve_write()以用于内存映射文件访问。reserve_write()函数返回指针指向内存映射文件中可写入新消息的消息缓冲区并更新空闲指向元件。release_reserve_write()用来表示之前通过使用reserve_write()而保留的消息缓冲区准备就绪可被读出。所以远程接收RR可以按以下步骤处理每个消息，从而减少一个消息拷贝：

1、reserve_write()

2、recv()

3、release_reserve_write()

b)降低所需的send()调用率

为了降低小的消息填充10Gbps管道需要的send()调用的次数，一个选择是看小消息的数量是否可以集合成块，使用一个send()系统调用来发送。为了保持在之前部分中减少的消息拷贝的数量的优势，必须扩展新开发的API以作用于消息块。所以，具有块能力的新函数的名称如下：

·reserve_read_bulk(&no_of_messages)一更新no_of_messages变量，以表示可用于读出的空闲缓冲区的数目。

·release_reserve_read_bulk(num)-标记下一个“num”消息为读出。

·reserve_write_bulk(&no_of_messages)-更新no_of_messages变量，以表示可用于写入的空闲缓冲区的数目。

·release_reserve_write_bulk(num)-标记下一个“num”消息为准备就绪可被读出的。

实际上，针对远程发送进程和远程接收进程描述的减少消息拷贝的算法不能被扩展成包括新的块API。这是因为如图2所示的内存映射文件布局。不能使用内存映射文件中消息缓冲区的引用(reference)分块地发送或接收消息，原因是消息空闲指向元件区与消息数据指向元件区重叠。只有固定长度的消息有效载荷通过TCP连接发送。为了支持这两种优化，需要新的内存文件布局。

图7示出根据本发明的各个实施方式的内存映射文件的新设计布局。该图图解说明用于消息空闲指向元件和消息数据指向元件的分立的连续区。修改消息空闲指向元件，使之具有相应的消息数据指向元件的引用。

通过此优化，可以将引用从内存映射文件(消息有效载荷)区段中转到send()系统调用和recv()系统调用。这样，系统可获得益处：即减少消息拷贝和对于许多消息能使用send()系统调用和recv()系统调用。在本发明中不必改变应用代码，即发送进程和接收进程，就可以获得这些益处。

本发明的系统被重新设计并修改，来克服分块消息发送的限制，特别是在要访问最后一个消息缓冲区时。越过此最后一个消息缓冲区的任何分块send()或recv()也会越过内存映射文件极限。为了不出现这种状况，每个消息报头具有一个“最后”位，只对最后一个消息报头设置该位。reserve_write_bulk()和thereserve_read_bulk()检查该位并向调用器报告当前保留的消息缓冲区的分块中最后一个消息缓冲区是否是内存映射文件中的最后一个。然后调用程序(在当前远程发送RS进程和远程接收RR进程中)的责任是使用该信息，并保证不会越过内存映射文件极限。

c)单个非阻塞send()和recv()

如之前的段落中提到的，send()调用和recv()调用是在循环中被调用的，以确保单个消息的发送和接收完成。对于分块消息还可如此，但这会首先否定引入消息分块或分组的原因。在处理分块消息的一次重复中，最好使用一次send()调用或recv()调用。

例如，远程发送RS进程可使用reserve_read_bulk()函数保留与准备好被读出的缓冲区一样多的缓冲区。可以尝试使用一次send()系统调用来发送整个消息。然而，send()系统调用可能仅对消息的子集有用。事实上，最后一个消息可能只是部分发送的。无论如何，远程发送RS进程可通过send()系统调用的返回值确定是否如此，并使用release_reserve_read_bulk()函数将内存映射文件中的许多消息缓冲区标记为已读出。远程接收RR进程也可以以类似方式工作。下面解释用于远程发送RS进程和远程接收RR进程的算法。

而且，如果以非阻塞方式进行send()系统调用，远程发送进程可以运行的快很多。这可以通过使用send()系统调用中的标记很容易地实现。

优化的远程发送进程

在上文描述的所有优化之后，远程发送RS进程在每次重复中的工作如下。在内存映射文件中，变量message_size()保存每个消息的(固定)大小。

1、reserve_read_bulk(&number_of_ready_messages)-获得指向内存映射文件中消息数据指向元件的指针。变量number_of_ready_messages是用待发送的消息的数目更新的。

2、messages_bytes_to_send_now＝messages_bytes_not_sent_previously+number_of_ready_messages*message_size

3、bytes_sent＝send(send_ptr，messages_bytes_to_send_now)-send()调用是非阻塞的。send_ptr指向内存映射文件中刚好在最后发送的字节之前的位置

4、messages_sent＝bytes_send/message_size

5、message_bytes_not_sent_previously＝messages_bytes_to_send_now-bytes_sent

6、send_ptr+＝bytes_sent.

7、release_reserve_read_bulk(messages_sent)-在内存映射文件中指出不再需要在此重复中发送的消息所在的消息缓冲区。

8、返回步骤1。

优化的远程接收进程

在上文描述的所有优化之后，远程接收RR进程在每次重复中的工作如下。在内存映射文件中，变量message_size()保存每个消息的(固定)大小。

1、reserve_write_bulk(&number_of_ready_message_buffers)-获得指向内存映射文件中的消息数据指向元件的指针。用待写入的消息缓冲区的数量来更新变量number_of_ready_message_buffers。

2、messages_bytes_to_receive_now＝messages_bytes_not_received_previously+number_of_ready_message_buffers*message_size

3、bytes_received＝recv(recv_ptr，messages_bytes_to_send_now)-recv_ptr指向刚好在内存映射文件中保存的最后接收的字节之前的位置。

4、messages_received＝bytes_received/message_size

5、message_bytes_not_received_previously＝messages_bytes_to_receive_now-bytes_received

6、recv_ptr+＝bytes_received.

7、release_reserve_write_bulk(messages_received)-在内存映射文件中指出在此次重复中发送的消息所在的消息缓冲区已准备好被读出。

8、返回步骤1。

图8示出在优化后针对各消息大小在吞吐量测试中测得的吞吐量结果。AT表示调整之后，BT表示调整之前，即之前的结果。可以看出，在调整优化后，对于所有的消息大小，吞吐量都增加了。对于这些测试，队列大小被设置成500个消息，且使用的插口缓冲区设置是缺省值。换言之，为了设定插口缓冲区大小，在TCP插口上不使用setsockopt()调用。

图9示出根据本发明的各个实施方式的等待时间测试设置。等待时间测试的目的是确定在各种条件下可以达到的最佳等待时间。在本发明的一个示例性实施方式中，对于每次重复，EP服务器中的LS进程生成一个消息，用发送时间戳给它加标记，并通过逻辑远程CBQ链路RCBQ1将其发送到LB进程。LB进程获得该消息，并将其发送到EP服务上运行的LR进程。一旦接收到消息，LR进程获取该消息的接收时间戳。发送进程S使用qwrite()函数调用来发送消息，LR进程使用qread()函数调用来读消息。等待时间是通过用消息的接收时间戳减去发送时间戳计算出的。吞吐量是由LR进程测量出的，是每秒接收的消息数量。LB进程采用以下算法：

1、用reserve_write()函数在与RCBQ2关联的本地内存映射文件中保留1个消息缓冲区的空间以用于写入。稍后将讨论该函数；

2、从RCBQ1中读一个消息，并将它直接保存到通过步骤1获得的消息缓冲区中；

3、用release_reserve_write()函数将步骤1的那个消息缓冲区标记为准备好读出，该函数在稍后进行讨论。

当LR进程终止时，等待时间测试停止。LR进程运行2分钟以等待吞吐量达到稳定状态。2分钟后，它打印最近一百万个消息的平均等待时间和吞吐量，然后退出。

IP地址是通过下述方式设置的：在EP服务器和EX服务器上，RCBQ1通信量使用NIC端口1，RCBQ2通信量使用NIC端口2。进程和中断之间的关系设置如下：

EP服务器插口0：LS和与RCBQ1关联的远程发送进程RS被仿射在分离的核心上。还给NIC端口1上的一个Tx中断分配其自己的核心。剩下的NIC端口1的Rx中断以循环利用方式分布在剩下的核心中。

EP服务器插口1：LR和与RCBQ2关联的远程接收进程RR被仿射在分离的核心上。还给NIC端口2上的一个Tx中断分配其自己的核心。剩下的NIC端口1的Rx中断以循环利用方式分布在剩下的核心中。

EX服务器插口2：LB、与RCBQ1关联的远程接收进程RR和与RCBQ2关联的远程发送进程RS被仿射在分离的核心上。还给NIC端口1和端口2上的Tx中断分配它们各自的核心。剩下的就是NIC端口1和端口2上的Rx中断。该插口有16个核心，没有给这些核心都分配某事。

对于该测试，变化的参数是：

·最大队列大小-这是可由内存映射文件保存的消息的最大数目。通过改变文件大小可改变此参数。

·发送LS进程的注入率-通过使LS进程在发送连续消息之间休眠固定间隔来改变此参数。

图10显示调整之前和调整之后的网络利用结果。可以看出，对于低至512字节的消息大小，可达到10Gbps的容量。

获得最大吞吐量的设置

为达到如图11和图12中所示的最大吞吐量，需要进行以下设置。

1、必须调整最大队列大小，使整个内存映射文件可驻存在插口的高速缓存中。

2、必须以如下方式仿射中断，即所有的中断和进程运行于在同一插口的分离核心上。

3、在RS和RR进程中，使用setsockopt时，不改变插口缓冲区大小。

4、针对TCP的接收缓冲区的调节必须得到操作系统内核的支持，且该参数必须开启。在Linux操作系统中，参数/proc/sys/net/ipv4/tcp_moderate_rcvbuf必须设置为1。

图11示出队列大小变化时的吞吐量和等待时间的变化。消息大小固定在512字节，插口缓冲区大小为缺省值来进行此测试。可以看出，队列大小越小，等待时间和吞吐量的结果越好。队列大小为1000个消息时获得最佳结果，此时等待时间为3.5毫秒，吞吐量为大于每秒2百万个消息。队列大小越小，队列变满的可能性越大，这会影响吞吐量和等待时间。在较大的队列大小下，由于吞吐量降低、等待时间增大，高速缓存丢失的可能性较高。等待时间还由于以下事实而增大，即按照利特尔法则，队列大小越大，队列中的平均消息数越高。

根据引入率的等待时间变化

通过改变由LS进程发送的连续消息之间的休眠时间，改变消息的引入率。消息大小设置成512字节；对于缺省插口缓冲区，队列大小设置成500个消息。

图12示出等待时间如何受到引入消息速率影响。随着引入消息速率的降低，等待时间也降低。这些结果也遵守利特尔法则。从这些结果可以认为，远程CBQ在10Gbps链路上，每秒以低于1毫秒的等待时间，可传送1百万个消息。在休眠时间为500毫秒时，观察到的最低等待时间是173毫秒。可以将它认为是可忽略连续消息排队可能性时获得的最短的等待时间。这并不奇怪，因为从EP服务器到EX服务器的脉冲(ping)花费基本相同的时间。如果考虑在10Gbps网络上32字节的脉冲消息的传送时间，且测试中所使用的链路的长度不超过1米，可推断出脉冲时间本身与在网络中所花费的时间关系不大。

通过下面给出的示例描述本发明，仅为阐释本发明的目的提供所述示例，因此，所述示例不应被解释为限制本发明的范围。

图13示出使用定制构建队列(CBQ)构建的样本交易系统架构。所有交易商借助交易客户机软件连接到交易系统，并在系统中下购买定单和/或出售定单。每个定单与一个定单确认对应。当定单生成交易时，通知该交易中涉及的所有交易商。交易客户机软件通过网络使用TCP/IP与交易系统通信。在交易系统内部，不同的进程使用消息队列彼此间进行通信。每个进程从其输入队列中移出消息，进行特定处理，并将一个或更多消息放置到其输出队列。如果通信进程是在同一主机上运行的，则使用本地点对点的本地CBQ。如果通信进程在远程主机上，则用远程CBQ进行通信。连接管理器进程管理来自交易商的客户连接。来自交易商的引入消息被写入消息队列，该消息队列被通过前向协议转换器读出。来自反向协议转换器的消息是从各自的消息队列读出的，并且被在各自的TCP连接上发送给交易商。前向协议转换器将引入消息转换成内部格式。反向协议转换器将离开消息从内部格式转换成交易客户机可解析的格式。前向会话控制器和反向会话控制器访问连接到系统的每个交易客户机的会话特定信息。通过前向会话控制器和反向会话控制器进行会话特定处理(例如为了更新共享内存中的会话状态)。确认引擎对引入定单进行确认。匹配引擎将引入定单与系统中的现有定单进行比较，并在匹配时生成交易。为交易中涉及的所有交易商生成交易通知单。从定单到定单确认、从交易生成到交易通知单的消息流如图9所示。有时，对于缺省容许冗余度，有超过一个匹配引擎进程在处理相同数目的定单。在这样的情况下，使用发布订阅方消息队列。例如，确认引擎可以把消息排列到发布订阅方队列中，其中2个匹配引擎可以是该队列的订阅方。

已经参照本发明的各个实施方式给出了前面的描述。本发明所属领域的技术人员会认识到在意思不偏离本发明的原理、范围下，可实施对所描述结构和操作方法的更改和变化。

Claims (26)

1.一种用于运行于至少两个节点上的至少两个进程之间的进程间通信中的消息收发的系统，该系统包括：

a)能够访问该系统的主内存的至少两个主节点，所述主节点之间通过至少一个网络接口卡NIC端口彼此可通信地耦连；

b)至少一个订阅方/发布方节点，其与至少一个主节点可通信地耦连；

c)适于存储进程间消息的存储器；

d)在所述存储器的共享内存中的存储缓冲区的至少一个循环链接列表队列，其可被多个进程并行访问；

e)运行于远程发送节点上的至少一个写进程，其将至少一个进程间消息插入所述队列中，从而更新空闲指向元件；

f)运行于远程发送节点上的至少一个远程发送进程，其异步地发送来自所述队列的至少一个消息；

g)运行于远程接收节点上的远程接收进程，其同步地接收至少一个进程间消息，并将其插入到该远程接收节点的共享内存上存储的队列中；

h)具有唯一指定的数据指向元件的至少一个读进程，它使来自所述远程接收节点的共享内存上存储的队列的消息出列，从而更新所述数据指向元件；

i)与适于指向所述队列中的空闲存储缓冲区的进程关联的空闲指向元件；以及

j)与适于指向包含进程间消息的存储缓冲区的进程关联的至少一个数据指向元件。

2.根据权利要求1所述的系统，其中，所述共享内存位于本地主节点和远程主节点中的每一个上，每个所述主节点适于以非一致内存访问方式访问所述共享内存。

3.在根据权利要求1所述的系统中，每个主节点适于具有以睿频加速模式运行的处理器核心，其中，为核心调整处理器时钟频率，使所述核心运行在较高的工作频率下。

4.根据权利要求1所述的系统，其中，两个NIC端口适于具有一个发送中断和多个接收中断，其中，为在TCP流上接收进程间消息的每个主节点分配与所述TCP流关联的一个接收中断。

5.根据权利要求1所述的系统，其中，远程节点适于运行各进程，各进程使用适于促进连接的通信手段进行通信，所述连接选自TCP/IP连接、GPRS连接、WiFi连接、WiMax连接和EDGE连接组成的组。

6.根据权利要求1所述的系统，其中，进程间消息的插入、取出适于无锁操作，其中，一个进程基本更新与其关联的一个指向元件。

7.根据权利要求1所述的系统，其中，通过使写进程将消息插入由所述空闲指向元件指向的所述空闲存储缓冲区中，使至少一个读进程读出包含由所述数据指向元件指向的进程间消息的存储缓冲区中存储的插入消息，无需锁定队列，每个写进程适于在检查存储缓冲区的所述队列的状态时异步地将消息插入该队列中，每个读进程适于在检查存储缓冲区的所述队列的状态时同步地从所述队列中取出消息。

8.根据权利要求1所述的系统，其中，队列包含于文件中，其中，所述队列的大小被调整以使得能够将所述文件存储在每个节点的处理器的共享内存中。

9.根据权利要求1所述的系统，其中，队列中的每个存储缓冲区通过空闲指向元件链接到下一个存储缓冲区，最后一个存储缓冲区链接到第一个存储缓冲区，形成循环链接列表，用于将所有的引入消息一个接一个地存储到存储缓冲区中，其中，更新所述数据指向元件和空闲指向元件先于向/从消息缓冲区中拷贝每个消息。

10.根据权利要求1所述的系统，其中，每个写进程，即发布方，重复检查每个读进程的数据指向元件的状态，由接收进程引起的数据指向元件的每次更新能被发送进程并行地访问，其中，由发送进程引起的空闲指向元件和数据指向元件的每次更新能被接收进程并行地访问。

11.一种用于运行于至少两个节点上的至少两个进程之间的进程间通信中的无锁消息收发的方法，该方法包括：

a)提供存储器，以存储进程间消息；

b)在可被多个进程并行访问的所述存储器的共享内存中，设置至少一个存储缓冲区队列；

c)提供写/读进程，用于将消息插入到所述队列和从所述队列取出消息；

d)提供发送进程和接收进程，用于发送、接收所述队列中存储的所述消息；

e)提供与每个进程关联的空闲指向元件，以指向所述队列中的空闲存储缓冲区；

f)提供与进程关联的至少一个数据指向元件，其指向包含所述进程间消息的所述存储缓冲区；

g)提供可通信地彼此耦连的至少两个主节点；

h)提供可通信地与至少一个主节点耦连的至少一个订阅方/发布方节点；

i)从运行于至少一个主节点上的至少一个进程接收至少一个进程间消息；

j)将所接收的进程间消息插入到由所述空闲指向元件指向的所述队列的存储缓冲区中；

k)将空闲指向元件的位置更新到所述队列的下一空闲存储缓冲区，以容纳下一个进程间消息；

l)通过运行于第一主节点上的远程发送进程，异步地发送来自所述队列的至少一个进程间消息；

m)通过运行于第二主节点上的远程接收进程，同步地接收至少一个进程间消息；

n)将所接收的消息插入到第二主节点上的共享内存的队列中；

o)通过多个进程同时从由相应的数据指向元件指向的第二主节点的所述队列的所述存储缓冲区中取出进程间消息；以及

p)将所述数据指向元件的位置更新至包含待由每个读进程读出的消息的下一存储缓冲区。

12.根据权利要求11所述的方法，其中，队列适于以无锁模式工作，其中，将消息插入到消息缓冲区和更新空闲指向元件是互相独立的进程。

13.根据权利要求11所述的方法，其中，发送进程和接收进程是在两个不同的主节点上分开编译的，发送进程与数据指向元件关联的相关性和接收进程与空闲指向元件关联的相关性是借助编译器开关通过两个分立的编译进程并行地组织的。

14.在根据权利要求11所述的方法中，每个写进程异步地将消息插入到主节点的共享内存上存储的队列中，其中，在具有空闲指向元件的共享内存中为空闲的一个或更多个进程被刷新到主内存中。

15.根据权利要求11所述的方法，其中，多个读进程运行，并同步地从队列中读消息，而共享内存中没有多个消息拷贝，其中，如果每个读进程已经读出消息，且其状态通过每个读进程各自的数据指向元件指示，则认为消息是被读出的，或出列的。

16.根据权利要求11所述的方法，其中，写进程检查所有读进程的数据指向元件以确保队列是空闲的，在消息插入到其中之后，检查空闲指向元件是否指向至少一个读进程的数据指向元件，并将消息拷贝到由空闲指向元件指向的消息缓冲区中，并更新空闲指向元件以指向下一个消息缓冲区。

17.根据权利要求11所述的方法，其中，主内存是按进程执行次序被顺序更新的，在更新空闲指向元件之前，至少一个新消息被插入所述主内存中。

18.一种用于运行于至少两个节点上的至少两个进程之间的进程间通信中的消息收发吞吐量优化的系统，该系统包括：

a)可通信地彼此耦连的至少两个主节点；

b)可通信地与至少一个主节点耦连的至少一个订阅方/发布方节点；

c)适于存储进程间消息的存储器；

d)可被多个进程并行访问的所述存储器的共享内存中的至少一个存储缓冲区队列；

e)运行于第一节点上的至少一个写进程，其将至少一个进程间消息插入到所述队列中，

f)运行于所述第一节点上的至少一个远程发送进程，其异步地发送来自所述队列的至少一个进程间消息；

g)运行于第二节点上的远程接收进程，其同步地接收至少一个进程间消息，并将其插入到所述队列中，远程接收充当远程主机中的发布方；

h)至少一个读进程，其使来自所述队列的消息出列；

i)单个非阻塞远程发送进程和远程接收进程，它们发送和接收分块消息；

j)与适于指向所述队列中的空闲存储缓冲区的进程关联的空闲指向元件；以及

j)与适于指向包含进程间消息的存储缓冲区的进程关联的至少一个数据指向元件。

19.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，无需创建用于发送进程间消息的中间缓冲区，数据指向元件指示所述远程发送进程直接从存储缓冲区读出所述进程间消息。

20.根据权利要求18所述的用于消息收发吞吐量优化的系统，数据指向元件指令每个读进程从存储缓冲区读出进程间消息以用于接收该进程间消息，其中，在发送来自所述队列的分块消息之前，每个远程发送进程在所述队列中保留数据缓冲区用于读消息，并在向至少一个远程主节点发送所述消息之后，更新循环队列的所述数据指向元件，指示所述消息缓冲区是释放的，且消息已被读出。

21.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，每个远程接收进程在接收来自所述队列的分块消息之前，在所述队列中保留数据缓冲区用于写消息，并在接收消息之后，更新空闲指向元件，指示所保留的消息缓冲区的读出准备就绪状态。

22.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，队列大小被优化，以在由所述队列中连续排列的空闲指向元件指向的空闲存储缓冲区中存储连续消息，以使得发送进程能够发送所述连续消息缓冲区中存储的分块消息。

23.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，分块消息收发降低远程发送进程和远程接收进程的重复次数。

24.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，所述优化的队列具有指向所述连续排列的消息中最后一个消息的最后一个空闲指向元件，其中，所述最后一个空闲指向元件给发送进程和接收进程指示存储缓冲区中最后一个连续消息的状态。

25.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，每个发送适于具有一个发送中断，每个接收进程适于具有多个接收中断。

26.根据权利要求18所述的用于消息收发吞吐量优化的系统，其中，单个非阻塞远程发送进程和远程接收进程根据可用的空闲缓冲区发送和接收分块消息，发送的和接收的消息通过各自进程的返回值确认。

Images