CN102594891A

CN102594891A - 用于处理远程过程调用请求的方法及系统

Info

Publication number: CN102594891A
Application number: CN2012100371712A
Authority: CN
Inventors: 唐宏伟; 霍志刚; 余璜; 冯圣中
Original assignee: Institute of Computing Technology of CAS
Current assignee: Institute of Computing Technology of CAS
Priority date: 2012-02-17
Filing date: 2012-02-17
Publication date: 2012-07-18

Abstract

本发明提供用于处理远程过程调用请求的方法，将处理来自客户端远程过程调用(RPC)请求的过程划分为多个流水段，每个流水段包括多个线程，每个流水段中的每个线程处理的是相同的子任务，不同的流水段处理不同的子任务。每个流水段中的线程处理的任务简单，对于每一个RPC客户端的请求，都能够快速地响应，从而提高了服务器处理RPC请求的整体响应能力。并且可以通过动态调整每个流水段包含的线程数量来为各个流水段分配资源，以使得各个流水段的负载和处理能力达到平衡。从而充分利用了RPC服务器所在计算机系统的各种资源，包括处理能力、存储资源和网络链路等，可以满足高并发和高吞吐环境的需求。

Description

用于处理远程过程调用请求的方法及系统

技术领域

本发明属于分布式计算领域，尤其涉及远程过程调用。

背景技术

远程过程调用(Remote Procedure Call，RPC)是指在分布式系统中，由本地系统上的进程或线程激活远程系统上的进程或线程，并将控制从本地传递到远程，由远程进程或线程执行特定的过程以完成相应的在本地系统上无法完成的功能。远程过程调用是一种易于编程的分布式编程模型，它隐藏了通信细节，给上层提供与本地过程调用一致的编程接口。

目前比较流行的RPC实现包括Sun RPC、OSF/DCE RPC等。它们关注的是对系统跨平台性的支持、对异构网络环境的支持、安全性特征、故障恢复等问题，同时也采用了包括多线程等在内的技术以提高RPC的并发性。但在一些需要极高并发性和高吞吐率的系统中，这些系统都比较难以达到要求。例如，Linux操作系统中实现的NFS服务器一般支持的客户端数量仅为30台左右，很大程度上是因为在RPC服务器端处理来自客户端的远程过程调用请求的机制限制了其扩展性，在客户端数量超过一定数量以后，RPC服务器端不能及时地响应客户端的请求。

发明内容

因此，本发明的目的在于克服上述现有技术的缺陷，提供一种用于处理远程过程调用请求的方法，可以满足高并发和高吞吐的需求。

本发明的目的是通过以下技术方案实现的：

本发明提供了一种用于处理远程过程调用请求的方法，所述方法包括：

步骤1)接收来自客户端的远程过程调用(RPC)请求；

步骤2)将所收到的RPC请求以流水线的方式进行处理；

其中，所述流水线由多个流水段构成，每个流水段包括一个或多个线程，每个流水段中的每个线程处理的是相同的子任务，不同的流水段中的线程处理的是不同的子任务，前一个流水段的输出作为后一个流水段的输入，各个流水段的子任务组合起来共同完成对来自客户端的RPC请求的处理。

上述技术方案中，所述流水线中的流水段的划分应符合下述条件：

各个流水段的子任务对系统资源的需求应尽量不同；每个流水段的子任务之间没有重叠，且各个流水段的子任务组合起来应完成对来自客户端的RPC请求的处理过程。

上述技术方案中，所述流水线可以包括5个流水段：

流水段1的子任务为与RPC客户端建立通信连接；

流水段2的子任务为从所建立的连接接收RPC请求分片；

流水段3的子任务为将所接收的RPC请求的分片组合成完整的RPC请求包；

流水段4的子任务为基于RPC请求包对RPC请求进行处理；

流水段5的子任务为将对RPC请求处理的结果作为应答返回到客户端。

上述技术方案中，所述步骤2)可以包括以下步骤：

将收到的来自客户端的RPC请求提交给流水段1中的线程进行处理；

流水段1中的线程与该RPC客户端建立通信连接，并在将连接标识符传递到流水段2后，返回继续处理其他的RPC请求；

流水段2中的线程基于连接标识符来从将所建立的连接接收RPC请求分片，在将所接收的分片传递到流水段3后，返回继续处理其他的RPC请求；

流水段3中的线程将所接收的RPC请求的分片组合成完整的RPC请求包并传递到流水段4，然后返回继续处理其他的RPC请求；

流水段4中的线程基于RPC请求包对RPC请求进行处理，并将处理的结果传递到流水段5后，返回继续处理其他的RPC请求；

流水段5中的线程将对RPC请求处理的结果作为应答返回到客户端后，返回继续处理其他的RPC请求。

上述技术方案中，流水段之间的数据传递是通过流水段之间的数据通路来实现的，每个流水段都有一个输入数据通路和一个输出数据通路，每个数据通路既是前一个流水段的输出数据通路也是后一个流水段段的输入数据通路，每个流水段中的所有线程共享该流水段的输入数据通路和输出数据通路。

上述技术方案中，所述数据通路可以为先进先出队列。

上述技术方案中，每个流水段所包含的线程数量可以是固定的。

上述技术方案中，还可以包括动态调整每个流水段所包含的线程数量的步骤。

上述技术方案中，动态调整每个流水段所包含的线程数量的步骤可以包括：周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均待处理任务数，所述每线程平均待处理任务数是由每个流水段的待处理任务的数量除以该流水段的线程的数量得到的。

上述技术方案中，动态调整每个流水段所包含的线程数量的步骤可以包括：周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均处理任务时间，所述每线程平均处理任务时间为每个流水段中的线程处理子任务所需的平均处理时间。

上述技术方案中，动态调整每个流水段所包含的线程数量的步骤可以包括周期性地执行如下操作：

查找流水线中“断流”的流水段，所述“断流”流水段为当前正在空闲或者几近空闲的流水段；

然后，检查该“断流”的流水段的直接前驱阶段是否产生了瓶颈，所述瓶颈是指该流水段待处理的任务多，而线程数量少，以致无法生产出足够多的数据以满足后继流水段的处理需求；

如果发现了瓶颈，则从最下游的“断流”流水段中移出一个线程到该产生瓶颈的流水段；否则进一步查看该前驱流水段的前驱，直至找到产生瓶颈的流水段或到达第一个流水段。

本发明提供了一种远程过程调用系统，所述系统包括客户端和服务器，所述服务器采用由多个流水段构成的流水线来处理来自客户端的RPC请求；其中，每个流水段包括一个或多个线程，每个流水段中的每个线程处理的是相同的子任务，不同的流水段中的线程处理的是不同的子任务，前一个流水段的输出作为后一个流水段的输入，各个流水段的子任务组合起来共同完成对来自客户端的RPC请求的处理。

与现有技术相比，本发明的优点在于：

将处理来自客户端的RPC请求的过程划分为多个流水段，每个流水段包括多个线程。由于每个流水段处理的任务简单，对于每一个RPC客户端的请求，每个流水段中的线程都能够快速地响应，从而可以满足高并发和高吞吐环境的需求。而且属于不同流水段的线程处理不同的任务，充分利用了RPC服务器所在计算机系统的各种资源。

附图说明

以下参照附图对本发明实施例作进一步说明，其中：

图1为流水线并行技术示意图；

图2为根据本发明实施例的流水线阶段划分示意图；

图3为根据本发明实施例的流水线阶段间通信示意图。

具体实施方式

为了使本发明的目的，技术方案及优点更加清楚明白，以下结合附图通过具体实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

为了更好地理解本发明，首先流水线并行技术和对远程过程调用RPC进行简单的介绍。

图1所示的是流水线并行技术的示意图。所谓流水线并行技术，即是指将一个任务的处理划分成多个阶段，每个阶段处理一项子任务，同一个任务中的多个子任务在时间上是严格串行的。由于每个阶段由专门的部件来处理，各个部件同时工作，因此不同任务的不同阶段的子任务是可以同时处理的。如图1所示，具有相同条纹的阶段(子任务)来自于同一项任务。流水线并行技术能充分利用系统中各个部件的处理能力和资源，使每个部件都处于忙碌状态，从而提高系统的并发性和吞吐率。

而远程过程调用系统是一种典型的客户端/服务器模型，它由客户端存根和服务器组成，客户端存根可以由程序员手工编写，也可以由编译器自动生成。RFCl 057对远程过程调用协议的实现提出了详细的规范要求，下面给出一个典型的远程过程调用系统的工作流程示例：

(1).客户端进程/线程调用客户端存根过程；

(2).客户端存根过程将客户端进程/线程提供的远程过程号、调用参数等打包成RPC请求；

(3).客户端存根过程根据客户端进程/线程提供的调用信息查找服务器；

(4).客户端存根过程通过网络把RPC请求发送给服务器，期间，为了提供对异构网络环境的支持，还需要将RPC请求转换成网络表示；

(5).服务器接收到RPC请求后，根据远程过程号查找相应的本地过程；

(6).服务器调用该本地过程，并传递以RPC请求中传递来的参数，控制权交给该本地过程；

(7).本地过程执行完成以后，将相应的客户端标识和执行结果打包成RPC应答，通过网络返回给客户端存根；

(8).客户端存根接收到RPC应答以后，提取出执行结果，并返回给客户端调用进程/线程。

可见，当有多个RPC服务在运行时，每一个RPC服务都需要依赖于多种系统资源，例如CPU、内存、通信链路、磁盘等。但是在某一个RPC服务执行过程中的某一段具体的时间内，并非需要全部的系统资源。例如，当一个RPC服务正在从通信链路接收RPC请求的时候，它仅需要通信链路资源、内存资源和少量的CPU资源，并不需要磁盘，因此，可以把暂时用不到的资源分配给另一个需要的RPC服务。

在本发明的一个实施例中，提供了一种用于处理远程过程调用请求的方法。该方法将接收到的每个远程过程调用请求提交给由多个流水段构成的流水线来进行处理。其中，每个流水段包括一个或多个线程，每个流水段中的每个线程处理的是相同的子任务，不同的流水段中的线程处理的是不同的子任务，前一个流水段的输出作为后一个流水段的输入，各个流水段的子任务组合起来完成对来自客户端的RPC请求的处理过程。而且每个流水段所拥有的线程数量也是可以动态调整的。

更具体地，在收到来自客户端的RPC请求时，将其提交给第一个流水段中的线程进行处理，第一个流水段中的线程在将对该RPC请求的处理结果传递给第二个流水段中的线程后，返回继续处理其他的RPC请求。第二个流水段中的线程基于来自第一个流水段的处理结果继续对该RPC请求进行处理，并在将对该RPC请求的处理结果传递给第三个流水段中的线程后，返回继续处理其他的RPC请求，依次类推，最后一个流水段中的线程将对来自客户机的RPC请求的最终处理结果返回给客户端后，返回继续处理其他的RPC请求。

应指出，流水线所包括的流水段的数量可以根据实际的应用模式或用户需求来进行设置，但流水段的划分应符合下述条件：(a)各个流水段的子任务对系统资源的需求应尽量不同；(b)每个流水段的子任务之间尽可能没有重叠，且各个流水段的子任务组合起来应完成对来自客户端的RPC请求的处理过程。另外，每个流水段的长度也要适中，粒度过大会引起对共享计算机资源的竞争，从而限制并发性，且不利于负载均衡；粒度过小会增加数据在流水线之间传递的开销，使处理逻辑复杂化。

图2给出了根据本发明一个实施例的流水线阶段划分的示意图。如图2所示，将处理RPC请求的过程划分为5个流水段：

流水段1的子任务为：建立连接，即与RPC客户端建立通信连接。

流水段2的子任务为：接收分片。因为某些专用网络支持的包长为2048字节，所以在发送RPC请求时，需要将其分成大小为2048的分片来发送。由此当服务器从该专用网络接收到的是RPC请求的分片。

流水段3的子任务为：组包，即将所接收的RPC请求的分片组合成完整的RPC请求包。

流水段4的子任务为：服务，即对RPC请求的处理。

流水段5的子任务为：应答，即将处理的结果作为应答，将该应答返回到客户端。

其中，流水段1和流水段2中的子任务主要与网络相关，流水段3和流水段4中的子任务主要与处理器相关，流水段5中的子任务主要与网络相关。应指出，以上划分为5段只是一个具体的示例。

在其他实施例中，例如，在不需要进行分片传输的系统中，可以将处理RPC请求的过程划分为4个流水段：流水段1的子任务为建立连接；流水段2的子任务为接收RPC请求数据包；流水段3的子任务为对RPC请求进行处理；流水段4的子任务为将处理的结果作为应答并返回到客户端。又例如，可以将处理RPC请求的过程划分为3个流水段：流水段1的子任务为建立连接并接收RPC请求数据包；流水段2的子任务为对RPC请求进行处理；流水段3的子任务为将处理的结果作为应答并返回到客户端。

继续参考图2，收到RPC请求时，将其提交给流水段1，流水段1中的某个线程与该RPC客户端建立通信连接，并在将连接标识符传递到流水段2后，返回继续处理其他的RPC请求；流水段2中的某个线程基于连接标识符来从将所建立的连接接收RPC请求分片，在将所接收的分片传递到流水段3后，返回继续处理其他的RPC请求；流水段3中的某个线程将所接收的RPC请求的分片组合成完整的RPC请求包并传递到流水段4，然后返回继续处理其他的RPC请求；流水段4中的某个线程基于RPC请求包对RPC请求进行处理，并将处理的结果传递到流水段5后，返回继续处理其他的RPC请求；流水段5中的某个线程将对RPC请求处理的结果作为应答返回到客户端后，返回继续处理其他的RPC请求。

例如，可以为图2所划分的每个流水段建立与其对应线程组，并且该线程组中每个线程处理的都是相同的任务(即该流水段的子任务)。例如，建立以下线程组：

●Rpc_establish_connection(记为Rpc_1，对应流水段1，)

●Rpc_recv_fragment(记为Rpc_2，对应流水段2)

●Rpc_assemble_fragment(记为Rpc_3，对应流水段3)

●Rpc_service(记为Rpc_4，对应流水段4)

●Rpc_returner(记为Rpc_5，对应流水段5)

当收到一个RPC客户端的通信会话请求后，先将其提交到流水段1的线程组Rpc_1，由Rpc_1中的某个可用的线程与该RPC客户端建立通信会话，之后将建立好的通信会话的描述符递交给下一个流水段后，返回继续处理其他的RPC请求；线程组Rpc_2中的某个可用的线程在该建立了的连接会话上接收来自该RPC客户端的分片，并将接收到的分片转发到下一个流水段后，返回继续从其他连接会话上接收RPC分片，依次类推。

可见，在本发明的实施例中，采用了由多个流水段组成的流水线来处理远程过程调用请求。由于每个流水段对应的线程组中每个线程处理的任务简单，对于每一个RPC客户端的请求，每个流水段中的线程都能够快速地响应，从而提高了服务器处理RPC请求的整体响应能力，可以服务于大量的客户端。而且属于不同流水段的线程处理不同的任务，这样可减少了各个服务线程之间的资源竞争，提高了扩展性。

而现有的RPC实现中，虽然有些也利用了多线程的方式来提高系统的并发性，但每个线程分别服务于一个完整的客户请求，要参与从建立网络连接、收包、到请求处理再到返回结果的全过程，也可以说每个线程处理与该客户请求相关的多个任务。这样，一方面，服务的线程数限制了其能够服务的客户端的数量，另一方面，各个服务线程之间由于无序的资源竞争而限制了系统的扩展性。例如，现有的RPC请求处理过程是：当服务器收到一个RPC请求后，为该RPC请求创建一个专用的线程，由该线程负责处理包括建立网络连接、接收网络包、组包、调用并执行应用提供的服务函数以及发送服务处理结果等任务，那么，当出现大量并发的RPC请求时，服务器需要建立大量的并发线程来处理这些请求，这些线程消耗大量的系统资源，并引入大量的资源竞争，比如对网络、磁盘、IO总线等的竞争，进而导致服务器性能急剧下降等。

而在本发明的实施例中，当收到RPC通信会话请求后，并不是为该RPC会话建立单独的线程，而是将该通信会话请求递交给专门负责第一流水段(例如建立RPC通信会话的流水段)中的一个线程，该线程建立了RPC通信会话后，将与该RPC请求相关的信息传递到下一个流水段后，返回继续处理其他的RPC请求。

从上面的描述可以看出，在本发明的实施例中，不是为每个RPC请求分别建立单独的线程，而是采用多个流水段来处理所有来自客户端的RPC请求，每级流水段的线程都能够各司其职，尽可能地做到了流水段之间的资源隔离(比如有的流水段独占网络，有的流水段独占磁盘)，降低了资源竞争。此外，由于每个流水段的任务简单，对于每一个RPC请求都能够快速地响应，从而提高了服务器处理RPC请求的响应能力，能满足高并发，高吞吐等需求。

应指出，在其中建立流水线各个流水段之间的数据通路也是很关键的。数据通路是联系流水线各个流水段的纽带，每个流水段都有一个输入数据通路和一个输出数据通路，一个数据通路既是前一个阶段的输出数据通路也是后一个阶段的输入数据通路。数据在前一个流水段经过线程的处理后，通过输出数据通路传递给后一个流水段的线程进行处理，依次进行直至最后一个流水段，而最后一个流水段输出的数据也是系统最终的处理结果。另外，如果流水线的每个流水段有多个相同的线程同时处理，数据通路还要支持共享和多路复用。每个流水段有若干个线程，同一个流水段的多个线程处理的是来自不同的RPC客户端的相同的任务，每个流水段所拥有的线程的数量不是固定的，会根据各个流水段的负载情况进行动态的调整。数据通路就是在流水段之间进行数据传递的通信介质。由于流水段对应的是线程，流水段之间的通信实际上是线程之间的通信。例如，如果传递的数据量大，可以使用共享内存；如果数量量小，可以用管道；前者的使用需要基于共享内存抽象出数据读写接口，而后者十分简单，直接通过对管道的读、写操作就可以实现数据的传递了。在本实施例中，采用的是先进先出FIFO的队列机制来实现流水段之间的(即线程间)的通信。将数据通路设计为先入先出(FIFO)的队列，队列中的每一项为指向所存储的数据的指针，在相邻两个阶段之间传递数据的指针，而不是数据本身，从而避免了内存拷贝带来的开销。

图3所示的是根据本发明实施例的流水段间通信示意图。这里的XX队列指的就是前面提到的数据通路。如图3所示，Rpc_1和Rpc_2之间建立的是连接队列，Rpc_1将为RPC客户端建立通信连接的标识符保存在连接队列中。Rpc_2从该连接队列中读取连接标识符，基于该连接标识符接收RPC请求分片，并将所接收的分片保存在分片队列中。Rpc_3将从分片队列中获得的RPC请求的分片组合成完整的RPC请求包，保存到请求队列中。Rpc_4从请求队列中读取RPC请求并对RPC请求进行处理，将处理的结果保存到应答队列。Rpc_5从应答队列中提取相应的数据作为应答发送到客户端。由于每个流水段都可能存在多个功能相同的线程，因此，需要对这些队列的操作采用基于互斥锁的保护机制，以保证数据的完整性。

此外，由于整个服务器的资源总量是一定的，尤其是处理器与内存资源，几乎或多或少每个阶段都要使用。而且由于RPC服务器的负载(即RPC请求)情况也是不断变化的，并且流水线的各个阶段之间是相互影响的，从而，调整各个流水段的资源配给以使得每个阶段的负载与其处理能力达到动态平衡、以及整个流水线的各个阶段之间达到动态平衡，是实现系统高并发、高吞吐率的重要保证。

在一个实施例中，采用了静态负载均衡策略，根据流水线各个阶段的任务处理特点，为每个阶段配备固定的处理能力，也就是说每个流水段所拥有的线程数量是固定的。这种策略需要事先知道各个阶段的处理能力需求，适合于RPC请求模式比较单一且固定的应用场景。静态策略的优点在于实现简单，开销小，效率高，但是很难适应RPC请求负载的动态变化。

在又一个实施例中，该方法还可以包括动态调整每个流水段所拥有的线程数量的步骤，以达到各流水段之间的动态平衡。对于每一个流水段来说，其所拥有的线程数越多，意味着该流水段得到的资源也就越多。因此，可以根据系统当前的负载情况来调整每个流水段的线程数，以使得每个阶段的负载与处理能力以及各个阶段之间达到动态平衡。例如，可以采用下面的策略来实现动态的负载均衡：

(1)基于每线程任务数量的负载均衡策略

在进行资源调度时考虑两个因素：每个流水段的输入数据通路中待处理任务的数量和该流水段的线程数量。对于每个流水段来说，其输入队列中的任务数量与当前线程数量是可以准确获得的，将二者相除后得到每个线程的待处理任务数量，找到具有最大的每线程待处理任务数量的流水线阶段，为其增加系统资源，即增加一定数量的线程，从而消除系统瓶颈，实现负载均衡。例如，将每个流水段的待处理任务的数量记为N_{Task_StageM}和将每个流水段的线程的数量N_{Worker_StageM}(其中，M＝1，2，3，4，5，对应五级流水段)，将二者相除后得到每个线程的平均待处理任务数量，作为该流水段的负载指标：

N_{Load_StageM} = \frac{N_{Task_StageM}}{N_{Worker_StageM}}

(M＝1，2，3，4，5，对应五级流水段)

也就是说可以根据每个流水段的负载指标来周期性地调整各个流水段的线程数量，以使得各个流水段具有相同的每线程平均待处理任务数。

(2)基于每线程任务处理时间的负载均衡策略

在“基于每线程任务数量的负载均衡策略”的基础上，进一步地将各流水段对其任务的平均处理时间作为第三个影响因素加以考虑，计算出流水段中每个线程的处理任务的时间，并找出具有子任务的平均处理时间的最大值的流水段，为其增加系统资源，即增加一定数量的线程，这样可以使得系统资源流向更趋于合理。其中，可以通过累计求平均值的方法来计算流水段的子任务的平均处理时间，即，在每个线程完成子任务处理后记录所用时间，并与该流水段段先前累计的子任务处理总时间相加，除以该阶段已处理完成的子任务数，便得到该流水段最新的子任务平均处理时间。最后，具有最大值的流水段，为其增加线程并增加相应的资源。或者，资源调度器可以周期性地调整各个流水段的线程数量，以使得各个流水段具有相同的每线程平均处理任务时间，每线程平均处理任务时间也就是每个流水段中的线程处理子任务所需的平均处理时间。

(3)“逆流而上”负载均衡策略

首先查找流水线中“断流”的阶段，即当前正在空闲或者几近空闲的阶段，然后，逆流而上，检查它的直接前驱阶段，看是否产生了瓶颈，即任务较多，而处理资源很少，从而无法生产出足够多的数据以满足后继阶段的处理需求，如果发现了瓶颈，则从最下游的“断流”流水段中移出一个线程到该流水段；否则进一步查看该前驱流水段的前驱，直至找到瓶颈或到达第一级流水段。这样充分考虑到流水线相邻阶段之间的“生产者——消费者”关系，迅速找到流水线瓶颈，优先考虑各个流水段之间的平衡，从而有效防止流水线“断流”，实现负载均衡

在本发明的又一个实施例中，提供了一种远程过程调用系统。该系统包括客户端和服务器。客户端通过在其上执行的客户端存根将RPC请求发送到服务器。在服务器端，采用由多个流水段组成的流水线来处理来自客户端的远程过程调用请求。也就是说服务器端按照对系统资源的需求情况和RPC处理流程的特点，将处理来自客户端的RPC请求的过程划分为多个流水线阶段。每个流水段包括一个或多个线程，不同的流水段中的线程处理的是不同的子任务，每个流水段中的每个线程处理的是相同的子任务。前一个流水段的输出作为后一个流水段的输入，每个流水段所拥有的线程数量也是可以动态调整的。

更具体地，当服务器端监听到一个来自客户端的RPC请求后，先将其提交给第一个流水段中的线程进行处理，第一个流水段中的线程在将对该RPC请求的处理结果传递给第二个流水段中的线程后，返回继续处理其他的RPC请求。第二个流水段中的线程基于来自第一个流水段的处理结果继续对该RPC请求进行处理，并在将对该RPC请求的处理结果传递给第三个流水段中的线程后，返回继续处理其他的RPC请求，依次类推，最后一个流水段中的线程将对来自客户机的RPC请求的最终处理结果返回给客户端后，返回继续处理其他的RPC请求。

在本发明的又一个实施例中，该系统中还包括资源调度器，所述资源调度器是以线程为单位来给各个流水段分配资源。资源调度器可以通过调整每个流水段的线程数的方式来调整对每个流水段的资源分配比例。

在一个实施例中，资源调度器采用了静态负载均衡策略，其根据RPC服务器流水线各个阶段的任务处理特点，为每个阶段配备固定的处理能力，也就是说每个流水段所拥有的线程数量是固定的。

在又一个实施例中，资源调度器采用了动态的负载均衡策略，其根据系统当前的负载情况动态调整每个阶段的处理能力，以使得每个阶段的负载与处理能力以及各个阶段之间达到动态平衡。例如，可以采用如上面提到的策略来实现动态的负载均衡：(1)基于每线程任务数量的负载均衡策略；(2)基于每线程任务处理时间的负载均衡策略；(3)“逆流而上”负载均衡策略。

在上述本发明具体实施例中，将RPC服务器的处理远程过程调用请求的流程划分为多个流水段，并根据每个流水段的任务处理特点和资源需求，来为各个阶段分配资源，因此充分利用了RPC服务器所在计算机系统的各种资源，包括处理能力、存储资源和网络链路等，可以满足高并发和高吞吐环境的需求。而且进一步地采用了多种负载平衡算法来使得各个流水段的负载和处理能力达到平衡。

虽然本发明已经通过优选实施例进行了描述，然而本发明并非局限于这里所描述的实施例，在不脱离本发明范围的情况下还包括所作出的各种改变以及变化。

Claims

1.一种用于处理远程过程调用请求的方法，所述方法包括：

步骤1)接收来自客户端的远程过程调用(RPC)请求；

步骤2)将所收到的RPC请求以流水线的方式进行处理；

2.根据权利要求1所述的方法，其中，所述流水线中的流水段的划分应符合下述条件：

各个流水段的子任务对系统资源的需求应尽量不同；

每个流水段的子任务之间没有重叠，且各个流水段的子任务组合起来应完成对来自客户端的RPC请求的处理过程。

3.根据权利要求1或2所述的方法，其中所述流水线包括5个流水段：

流水段1的子任务为与RPC客户端建立通信连接；

流水段2的子任务为从所建立的连接接收RPC请求分片；

流水段4的子任务为基于RPC请求包对RPC请求进行处理；

4.根据权利要求3所述的方法，其中所述步骤2)包括以下步骤：

5.根据权利要求1或2所述的方法，其中流水段之间的数据传递是通过流水段之间的数据通路来实现的，每个流水段都有一个输入数据通路和一个输出数据通路，每个数据通路既是前一个流水段的输出数据通路也是后一个流水段段的输入数据通路，每个流水段中的所有线程共享该流水段的输入数据通路和输出数据通路。

6.根据权利要求5所述的方法，其中所述数据通路为先进先出队列。

7.根据权利要求1或2所述的方法，其中每个流水段所包含的线程数量是固定的。

8.根据权利要求1或2所述的方法，还包括动态调整每个流水段所包含的线程数量的步骤。

9.根据权利要求8所述的方法，其中动态调整每个流水段所包含的线程数量的步骤包括：周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均待处理任务数，所述每线程平均待处理任务数是由每个流水段的待处理任务的数量除以该流水段的线程的数量得到的。

10.根据权利要求8所述的方法，其中动态调整每个流水段所包含的线程数量的步骤包括：周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均处理任务时间，所述每线程平均处理任务时间为每个流水段中的线程处理子任务所需的平均处理时间。

11.根据权利要求8所述的方法，其中动态调整每个流水段所包含的线程数量的步骤包括周期性地执行如下操作：

12.一种远程过程调用系统，所述系统包括客户端和服务器，所述服务器采用由多个流水段构成的流水线来处理来自客户端的RPC请求；其中，每个流水段包括一个或多个线程，每个流水段中的每个线程处理的是相同的子任务，不同的流水段中的线程处理的是不同的子任务，前一个流水段的输出作为后一个流水段的输入，各个流水段的子任务组合起来共同完成对来自客户端的RPC请求的处理。

13.根据权利要求12所述的系统，其中，所述流水线中的流水段的划分应符合下述条件：

各个流水段的子任务对系统资源的需求应尽量不同；

14.根据权利要求12或13所述的系统，其中所述流水线包括5个流水段：

流水段1的子任务为与RPC客户端建立通信连接；

流水段2的子任务为从所建立的连接接收RPC请求分片；

流水段4的子任务为基于RPC请求包对RPC请求进行处理；

15.根据权利要求14所述的系统，其中，服务器收到的来自客户端的RPC请求后，将其提交给流水段1中的线程进行处理；

16.根据权利要求12或13所述的系统，其中流水段之间的数据传递是通过流水段之间的数据通路来实现的，每个流水段都有一个输入数据通路和一个输出数据通路，每个数据通路既是前一个流水段的输出数据通路也是后一个流水段段的输入数据通路，每个流水段中的所有线程共享该流水段的输入数据通路和输出数据通路。

17.根据权利要求16所述的系统，其中所述数据通路为先进先出队列。

18.根据权利要求12或13所述的系统，其中每个流水段所包含的线程数量是固定的。

19.根据权利要求12或13所述的系统，还包括资源调度器，用于动态调整每个流水段所包含的线程数量。

20.根据权利要求19所述的系统，其中资源调度器周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均待处理任务数，所述每线程平均待处理任务数是由每个流水段的待处理任务的数量除以该流水段的线程的数量得到的。

21.根据权利要求19所述的系统，其中资源调度器周期性地调整各个流水段中的线程数量，以使得各个流水段具有相同的每线程平均处理任务时间，所述每线程平均处理任务时间为每个流水段中的线程处理子任务所需的平均处理时间。

22.根据权利要求19所述的系统，其中资源调度器周期性地执行如下操作：

如果发现了瓶颈，则从最下游的“断流”流水段中移出一个线程到该产生瓶颈的流水段；否则进一步查看该前驱流水段的前驱，直至找到产生瓶颈的流水段或到达第一级流水段。