CN1744593B - 一种传输链路的选择方法 - Google Patents

Abstract

本发明公开了一种传输链路的选择方法，该方法将负载分担算法和负载数据管理进行分离并分别设置于处理单元的应用层和传输层，通过应用层和传输层来协作完成分布式应用的处理任务分发过程。该方法包括：应用层首先检测是否存在到可以处理该任务的目的处理单元的传输链路，如果存在，则使用该传输链路完成处理任务分发过程；否则，应用层选择适当的负载分担算法，并通过传输接口向传输层请求可用的传输链路；传输层使用负载分担算法在其所维护的处理单元候选集中选择一个合适的处理单元，并建立到该处理单元的传输链路；应用层保存并使用传输层返回的传输链路完成处理任务的分发。本发明实现了处理任务的快速分发，提高了分布式应用的***伸缩性。

Description

一种传输链路的选择方法

技术领域

本发明涉及到计算机分布式应用***的处理单元间通信技术，特别涉及到与多个目的处理单元通信时的传输链路选择的方法。

背景技术

随着信息技术的不断发展，计算机应用***的规模正在加速膨胀，为了满足计算机应用***复杂程度不断上升的需要，应用程序的组件化和模块化已是大势所趋。很多计算机应用***已经出现了越来越专门化的模块分工，将复杂的应用程序划分称为多个模块，由多个处理单元分别处理，其中的各个模块只关注应用***一个很小的方面，例如，使用专门的处理单元接入用户、使用专门的处理单元管理状态数据等等。各个处理单元之间通过各种通信手段进行相互通信，将处理结果结合起来，对外形成一个整体，提供强大的服务功能。在此所述的处理单元也可以理解为通常所说的进程。

上述这种类流水线的作业方式大大提高了计算机应用***的伸缩性，即当计算机应用***中的某个处理单元的性能出现了瓶颈，只要增加该处理单元的处理能力就可以满足***的要求，因此，可以方便的对应用***的处理能力进行实时的调整。

不过，计算机应用***各处理单元的协作是依赖通信平台支持的，因此，上述类流水线的作业方式虽然降低了***的复杂度，提高了***的伸缩性，但同时也增加了各处理单元之间的通信压力，进而可能影响整个***的性能。这样一来，提高各个处理单元之间协作的效率将成为提高计算机应用***整体性能的一个重要的手段。

在这里，如何提高协作效率包括以下两个方面的问题：首先，如何将协作通知以最快的速度发送到目的处理单元；其次，如何在能够处理当前任务的处理单元中获得处理速度最快的目的处理单元。

针对上述提高协作效率的第一个问题，通常可以采用最普通，也是最基础的套接字(Socket)通信模式实现将协作通知以最快的速度发送到目的处理单元的目的。Socket可以有效的实现进程之间快速通信，但是直接应用Socket实现进程间通信限制了***的伸缩性，灵活性较差，而且软件重用能力不好。为此，网络编程人员通常将Socket作为通信的基础模块封装在通信单元中，而在实际的进程间通信过程中，直接调用通信单元，这样可以灵活、简单的实现进程间通信。

针对上述提高协作效率的第二个问题，即解决如何在可以处理当前任务的处理单元中选择处理速度最快的处理单元的问题，一般可以引入负载分担机制，即在进程通信前，先通过负载分担机制选择当前负载最轻的处理单元进行处理。

当前在分布式应用中有效结合上述两方面的解决方案一般是采用分层的形式实现，即抽象出一个传输层来专门负责管理处理单元之间的通信。整个***的应用模块将基于该传输层的通信支持进行开发，传输层向上为应用程序提供通信服务接口，应用模块通过这一接口，使用传输层提供的服务，完成处理单元之间的数据传输。

图1显示了当前一种典型的计算机应用***实现处理单元之间通信的抽象模型。从图1可以看出，该模型的各个处理单元可以抽象成以下几层模块：底层模块、传输层以及应用层。其中，底层模块包括操作***、中间件以及各种通用的模块；传输层负责管理和维护处理单元之间的传输链路，并使用定制的负载分担算法从候选集中选择处理单元；应用层实现业务逻辑，应用传输层服务完成数据通信。

在***的运行过程中，应用层向传输层提交传输请求，传输层分析请求的任务，应用负载分担算法选择一个可以处理本次任务的处理单元，并通过建立和使用到该处理单元的传输链路来完成传输过程。

可以看出，在图1所示的处理单元进行通信的过程中，每一次通信过程都要首先应用已经确定的负载分担算法从可以处理本次任务的处理单元的中选择一个处理单元，然后再通过到该处理单元的传输路径完成数据通信。

这样一来，每一次通信过程所花费的时间就都将包括：检索可以处理本次任务的目的处理单元，并确定到相应处理单元的传输路径所需的时间；以及在该传输路径上传输数据包所用的时间。这里检索和定位传输链路只是辅助处理单元协作，并不是分布式***处理单元协作必须花费的时间。

另外，一个大型计算机应用***的特点是多样的，因此，在传输层应用预先确定的负载分担算法并不总是对所有的通信情况都能有效的发挥作用。例如，在现有技术中，负载分担通常是通过传输层在可以处理本次任务的目的处理单元中随机选择，这种随机选择算法在总体上表现为所有处理单元负载平均的效果，即传输层在候选集中所有的处理单元中平均分配请求处理的任务。这种负载分担算法虽然简单、易于实现，并且可以基本上平均发挥各个处理单元的处理能力，但是，在实际的应用中是有一定局限性的。例如，在***动态加入某个新的处理单元或者升级某个处理单元时，该处理单元的处理能力，包括中央处理器以及内存等，都可能与原有的处理单元有较大的偏差，在这种情况下，随机选择算法显然不能充分发挥新加入或者新升级处理单元的处理能力。造成新加入或者新升级的处理单元无法快速和整个***融合的问题。

发明内容

为了解决上述技术问题，本发明提供了一种传输链路的选择方法，可以最大程度的减少检索处理单元的时间，实现快速的处理任务分发。

本发明进一步的目的是更有效的在处理单元间分配负载，提高各个处理单元的协作性能。

本发明所述传输链路的选择方法，将负载分担算法处理和负载数据管理分离并分别设置于处理单元的应用层和传输层，并在应用层和传输层之间通过传输接口传递负载分担算法信息，协作完成处理任务的分发过程；

该方法包括以下步骤：

a、应用层检测是否存在可以处理本次任务的处理单元的传输链路，如果存在，则使用该传输链路完成本次任务的分发过程，然后结束；否则，执行步骤b；

b、应用层根据应用程序的特点选择适合的负载分担算法；并通过传输接口请求传输层提供合适的传输链路，然后执行步骤c；

c、传输层判断是否存在可以处理本次任务的处理单元，如果存在，则根据应用层选择的负载分担算法从可以处理本次任务的处理单元中选择合适的处理单元，然后，使用到所选择处理单元的传输链路完成处理单元之间的通信；否则，进行异常处理，然后结束。

所述方法进一步包括：在传输层建立传输链路并返回传输层链路标记后，应用层创建应用层路由标记，并通过智能指针建立到该传输链路的关联。

并且，在传输链路状态发生变化时，传输层修改其保存的传输层链路标记状态；应用层路由标记通过智能指针自动获知该传输链路状态的变化。

步骤a所述检测是否存在到可以处理本次任务的处理单元的传输链路的方法具体为：应用层检测应用层路由标记的智能指针是否有效。

步骤b所述的根据应用的特点选择适合的负载分担算法具体为：应用程序根据应用所需的处理器能力，或所需的内存资源，或所需的网络带宽资源，或三者的任意组合选择适合的负载分担算法。

步骤c进一步包括：在所述传输层选择目的处理单元之后，传输层首先判断是否存在到所选择处理单元的传输链路，如果存在，则使用该传输链路完成处理单元之间的通信过程；否则，传输层建立到所选择处理单元的传输链路，然后使用建立的传输链路完成处理单元之间的通信过程。

所述方法进一步包括：处理单元接收其他处理单元广播的负载数据，并根据其他处理单元的负载数据进行分类汇总，生成处理单元候选集合；步骤c所述从可以处理本次任务的处理单元选择目的处理单元具体为：在可以处理本次任务的处理单元候选集合中选择目的处理单元。

所述负载数据包括处理单元可以处理的任务类型、处理单元的处理能力以及处理单元的当前负载量。

步骤c所述的负载分担算法为：当前处理单元的传输层在所有可以处理本次任务的处理单元候选集合中搜索负载最轻的处理单元。

处理单元在进行步骤c所述负载分担之前设置搜索步长值；并在可以处理本次任务的处理单元候选集合中设置一个搜索基准指针，指向搜索起始位置的处理单元；所述步骤b所述的负载分担算法包括以下步骤：

b1、本处理单元在可以处理本次任务的处理单元候选集合中，从所述搜索基准指针所指的处理单元开始，比较搜索步长值个数的处理单元的负载情况，并从中选择负载最轻的处理单元；

b2、将所述搜索基准指针向前移动所述搜索步长值的一半，指向下次搜索起始位置的处理单元。

由此可以看出，应用本发明所述的传输链路选择方法可以获得以下有益效果：

1、本发明通过使用传输链路标记，在处理任务分发时，选择使用应用层路由标记所保存的传输链路，而不用重复检索处理单元，从而减少了传输链路选择的时间，实现了快速的传输链路选择，同时也避免了传输链路的二次建立过程；

2、本发明通过让应用程序实现负载分担算法功能，而在传输层实现负载数据管理的功能，可以充分根据进程的特点灵活的引入各种负载分担算法，从而更有效的发挥各处理单元的处理能力，提高处理单元之间的协作性能，以及分布式应用的***伸缩性。

附图说明

图1显示了目前典型的计算机应用***处理单元之间通信的抽象模型；

图2显示了本发明一个优选实施例所述的应用***实现处理单元之间通信的抽象模型；

图3为本发明一个优选实施例所述的应用层通信方法的流程图；

图4为本发明一个优选实施例所述的处理单元应用层路由标记和传输层链路标记的关系示意图；

图5为本发明一个优选实施例所述的负载分担算法流程图。

具体实施方式

下面结合附图以及具体的实施例对本发明作进一步的详细说明。

为了实现分布式应用***各处理单元更好的协作，本发明的一个优选实施例对现有的负载分担处理方法进行了改进。图2显示了该实施例所述的计算机应用***实现处理单元之间通信的抽象模型。如图2所示，所述实施例将负载分担算法处理和负载数据管理分离并分别设置于处理单元的应用层和传输层，并在应用层和传输层之间通过传输接口(TI，Transport Interface)传递负载分担算法信息，协作完成处理任务的分发过程。

其中，位于应用层的负载分担算法处理模块可以根据应用自身的特点选择适合的负载分担算法。例如，某个应用对处理能力以及内存资源的要求很高，应用程序所设计的负载分担算法就可以选择当前处理能力最强、内存资源最空闲的处理单元；而如果某个进程对带宽资源要求比较高，应用程序所设计的负载分担算法就可以选择到本处理单元传输链路带宽最宽的处理单元。应用层的负载分担算法处理模块甚至可以考虑随着处理单元候选集合中处理单元负载状况的变化更新负载分担算法，比如，如果处理单元候选集合处理单元负载普遍较轻，就没有必要选择太精确的负载分担算法。

而位于传输层的负载数据管理模块用于收集和管理其他处理单元的负载数据，例如，其他处理单元可以处理的任务类型，正在运行的任务数目以及最大处理能力等等，然后对其他处理单元的负载数据进行分类汇总，形成针对各类处理目标的处理单元候选集合，并生成其他处理单元的负载指标。每个处理单元候选集合实时的反映了当前可为某种处理目标服务的处理单元的数量以及状态。

这样，通过图2所述的抽象模型，改变了现有技术中由于负载分担功能在传输层实现而带来的种种限制，在分布式应用***中可以更有效的发挥各个处理单元的处理能力，提高处理单元之间的协作性能。

另外，为了进一步降低建立及选择到目的处理单元的传输链路所需的时间，实现快速的链路选择及通信过程，本发明的优选实施例在处理单元应用层的负载分担算法处理模块引入了应用层路由标记，该应用层路由标记用于记录该处理单元到相应目的处理单元的传输路由，以作为后续传输过程是否重选传输链路的依据。

下面结合图2进行说明，如果处理单元1建立与处理单元2的传输链路，则处理单元1应用层的负载分担算法处理模块将保存一个到处理单元2的应用层路由标记。而如果处理单元1到处理单元2的传输链路出现异常，则处理单元1应用层的负载分担算法处理模块应该释放该到处理单元2的应用层路由标记。这样，在下一次处理单元1与处理单元2的通信过程中，处理单元1的应用层可以首先检测相应的应用层路由标记是否有效，如果该应用层路由标记有效，则处理单元1就可以直接通过该应用层路由标记所记录的已经建立的传输链路进行数据通信，而无需再次启动负载分担过程，从而节省了搜索、选择处理单元的时间，实现了快速的传输链路选择。由此，应用程序就可以充分利用已建立的传输链路进行数据传输，而不需要在每一次的通信过程中都检索并选择处理单元，进而实现了进程间的快速通信。

图3显示了本发明一个优选实施例所述传输链路的选择过程。如图3所示，本发明所述传输链路的选择过程包括如下步骤：

步骤301：应用程序发送传输请求到处理单元应用层的负载分担算法处理模块，该传输请求中包含待其他处理单元处理的任务；

步骤302：负载分担算法处理模块检测是否存在与可以处理步骤301所述任务的处理单元相对应的应用层路由标记，如果有，则执行步骤306；否则，则执行步303；

步303：负载分担算法处理模块选择适合的负载分担算法，使用本次任务的特征信息通过传输接口向传输层请求传输链路；传输层判断是存在相应的处理单元候选集合，如果有，则执行步304；否则，执行步307；

步304：传输层根据选择的负载分担算法，选择适合的处理单元，并判断是否存在到所选择处理单元的传输链路，如果存在，则执行步305；否则，传输层建立到所选择处理单元的传输链路，然后，执行步305；

步305：负载分担算法处理模块保存该应用层路由标记，然后，执行步306；

步306：负载分担算法处理模块使用该应用层路由标记所记录的传输链路完成进程间通信；

步307：应用程序进行异常处理，标志本次处理任务分发过程失败。

为了实现图3所示的方法，必须保证处理单元应用层的负载分担算法处理模块所保存的应用层路由标记实时的反映当前本处理单元与其他处理单元之间传输链路的状态。但是，由于处理单元的分层结构以及***设计的通信单元封装原则，虽然负责管理和维护处理单元之间传输链路的传输层可以实时的获得传输链路的状态，但是传输层没有直接的接口可以通知应用层传输链路的状态已经改变。这样，就很可能会产生应用层的负载分担算法处理模块所保存的应用层路由标记与实际的链路状态不一致的情况。很明显，这将导致通信过程的失败。

为了决这一问，本发明的一个优选实施例在建立传输链路时，处理单元的传输层也建立一个传输层链路标记，记录该处理单元到相应处理单元的传输链路。图4为该优选实施例所述的处理单元应用层路由标记和传输层链路标记关系的示意图。如图4所示，处理单元的传输层链路标记具体为传输层的连接对象，应用层路由标记具体为应用层的路由对象，这两个对象均标记同一个传输链路。其中，应用层的路由对象进一步包括一个指向传输层连接器对象的智能指针，通过该智能指针，保证传输层链路标记和应用层路由标记状态一致，实现传输层传输链路状态向应用层隐式透传的目的，即如果该智能指针不为空，则该应用层路由标记为有效状态；而如果该智能指针为空，则该应用层路由标记为无效状态。

在传输层建立传输链路时，处理单元在传输层和应用层分别建立一个连接器对象、一个路由对象，并且应用层的路由对象的智能指针指向相对应的传输层连接器对象。这两个对象都标记了到对应处理单元的传输链路。这样，在传输链路正常的情况下，应用程序可以通过其应用层路由对象的智能指针找到所标记的传输链路，并通过该传输链路完成数据通信。而当传输链路不可用时，传输层释放相应连接器对象的操作将导致应用层的路由对象变为无效状态。这样应用层路由标记就可以通过检测其智能指针实时的获得相应传输链路的状态。

由此，负载分担算法处理模块通过检测应用层的路由对象的智能指针是否有效就可以实现步骤302所述的检测应用层路由标记是否存在的操作。

另外，在本发明所述方法的步骤304，负载分担算法处理模块可以选择现有技术中的随机分担算法，也可以选择多种其他的负载分担算法，本发明并没有对负载分担算法的选择给予限制。

本发明的一个优选实施例提供了一种负载分担算法以及负载数据管理的方法，该实施例的负载分担算法适于应用对负载分担精度要求较高的情况。另外，该实施例的负载数据管理利用目的处理单元的处理能力以及当前负载情况的负载数据等，在处理单元候选集合中实际负载与处理能力比值最小的处理单元，即当前负载最轻的处理单元。其中，处理单元候选集合是由传输层的负载数据管理模块建立并维护的。

为了实时获得其他处理单元的负载情况，处理能力以及可以处理的任务类型，每个处理单元会周期的广播这些值到其他处理单元的负载数据管理模块，广播的周期越短，传输层链路标记记录的数据就越准确，进而负载分担算法就越有效。但是，另一方面，广播周期的缩短将会导致处理单元之间传送的状态信息量加大，造成网络的负载变重，降低***协作性能。该广播周期一般根据应用所期望的负载信息精确度来设定。

从上述负载分担算法以及负载数据管理方法可以看出，本实施例所述的负载数据管理并不会对处理单元候选集合的大小进行限制，因此，可以在***中不断加入新的处理单元。另外，由于新加入***的处理单元或新升级的处理单元当前负载为零，会在一段时间内成为处理任务分配的主要目标，直到该处理单元的负载与其他处理单元的负载逐渐持平为止，因此本实施例能够保证新的处理单元快速、无缝的融入整个分布式***。

但是，在整个处理单元候选集合中搜索负载最轻的目的处理单元的时间复杂度是线性的，这样就会随着分布式应用***规模的扩展出现算法退化的问题。因此，在本发明的另一个实施例中，其负载分担算法采用了次优搜索的算法，即搜索算法不再在整个处理单元候选集的范围内进行搜索，而是根据事先约定的经验搜索步长值Step，每次仅搜索指定步长Step个数的处理单元，并在这个搜索步长内找出一个负载最轻的处理单元作为该次处理任务分发的目的处理单元。该负载分担算法也适合当前任务分发处理单元负载较高的情况，这样就可以尽快将任务分发出去，降低处理能力占用。

图5为该优选实施例所述的负载分担算法流程图。如图5所示，本发明所述的负载分担算法在可以处理本次任务的处理单元候选集合中，设置一个搜索基准指针，指示本次搜索的起始位置，并通过控制该指针的移动实现候选集中每个处理单元均等的被选择机会；另外算法设定了一个经验搜索步长值Step，本实施例中该值被置为5；本发明所述负载分担算法包括以下步骤：

步骤501：从搜索基准指针所指的处理单元开始，比较步长值Step个处理单元的负载情况，并从中选择一个当前负载与处理能力比值最小的处理单元，即负载最轻的处理单元；

步骤502：将搜索基准指针向前移动步长值的一半，即移动Step/2个处理单元，作为下一次搜索的起始搜索点；

步骤503：建立到该处理单元的传输链路，实现数据传输。

在这一实施例中，通过多次的负载分担搜索过程，搜索基准指针可以在处理单元的候选集合中循环，使得处理单元候选集合中所有的处理单元都能够参与负载分担，因而保证了负载分担算法的公平性，基本实现充分发挥所有处理单元处理能力，实现各个处理单元之间有效的协作的目的。

另外，所述负载分担算法是在预先设定的Step个处理单元之间选择负载最轻的处理单元，而不是在整个处理单元候选集合中检索，这样，就使得检索的时间大大减少，进而提高了应用程序搜索目的处理单元的效率。

需要说明的是，上述处理单元处理能力为虚拟的处理能力，这个处理能力可能是***的标称指标，也可能是***的一个配置参数，甚至有可能是在一个硬件***上实现多个处理单元的情况下，将该硬件***的实际处理能力以某种方式分配到上述多个处理单元时，每个处理单元所配置的处理能力。

由上述实施例可以看出，本发明所述的方法通过将负载分担算法处理功能移到处理单元的应用层，并且在传输层增加负载数据管理的功能，可以充分根据应用的特点灵活的引入各种负载分担算法，从而更有效的发挥了处理单元的处理能力，提高了处理单元之间的协作性能。

另外，本发明所述方法通过为传输链路设立标记的方法，可以在数据传输的时候使用保存在应用层路由标记的传输链路，而不用二次检索目的处理单元，从而减少了选择传输链路的时间，实现了快速有效的处理单元间协作。

以上举优选的实施例，对本发明的目的、技术方案和优点进行了进一步的详细说明，所应理解的是，以上所述为本发明的优选实施例而已，并不用以显示本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种传输链路选择的方法，其特征在于，该方法将负载分担算法处理和负载数据管理分离并分别设置于处理单元的应用层和传输层，并在应用层和传输层之间通过传输接口传递负载分担算法信息，协作完成处理任务的分发过程；

该方法包括以下步骤：

a、应用层检测是否存在可以处理本次任务的处理单元的传输链路，如果存在，则使用该传输链路完成本次任务的分发过程，然后结束；否则，执行步骤b；

b、应用层根据应用的特点选择适合的负载分担算法；并通过传输接口请求传输层提供合适的传输链路，然后执行步骤c；

c、传输层判断是否存在可以处理本次任务的处理单元，如果存在，则根据应用层选择的负载分担算法从可以处理本次任务的处理单元中选择合适的处理单元，然后，使用到所选择处理单元的传输链路完成处理单元之间的通信；否则，进行异常处理，然后结束。

2.如权利要求1所述的方法，其特征在于，所述方法进一步包括：在传输层建立传输链路并返回传输层链路标记后，应用层创建应用层路由标记，并通过智能指针建立到该传输链路的关联。

3.如权利要求2所述的方法，其特征在于，在传输链路状态发生变化时，传输层动态修改其所保存的传输层链路标记状态；应用层路由标记通过智能指针自动获知该传输链路状态的变化。

4.如权利要求1、2或3所述的方法，其特征在于，步骤a所述检测是否存在到可以处理本次任务的处理单元的传输链路的方法具体为：应用层检测应用层路由标记的智能指针是否有效。

5.如权利要求1所述的方法，其特征在于，步骤b所述的根据应用的特点选择适合的负载分担算法具体为：应用程序根据本次任务所需的处理器能力，或所需的内存资源，或所需的网络带宽资源，或三者的任意组合选择适合的负载分担算法。

6.如权利要求1所述的方法，其特征在于，步骤c进一步包括：在所述传输层选择目的处理单元之后，传输层首先判断是否存在到所选择处理单元的传输链路，如果存在，则使用该传输链路完成处理单元之间的通信过程；否则，传输层建立到所选择处理单元的传输链路，然后使用建立的传输链路完成处理单元之间的通信过程。

7.如权利要求1所述的方法，其特征在于，所述方法进一步包括：处理单元接收其他处理单元广播的负载数据，并根据其他处理单元的负载数据进行分类汇总，生成处理单元候选集合；

步骤c所述从可以处理本次任务的处理单元选择目的处理单元具体为：在可以处理本次任务的处理单元候选集合中选择目的处理单元。

8.如权利要求7所述的方法，其特征在于，所述负载数据包括处理单元可以处理的任务类型、处理单元的处理能力以及处理单元的当前负载量。

9.如权利要求7所述的方法，其特征在于，步骤c所述的负载分担算法为：当前处理单元的传输层在所有可以处理本次任务的处理单元候选集合中搜索负载最轻的处理单元。

10.如权利要求7所述的方法，其特征在于，处理单元在进行步骤c所述负载分担之前设置搜索的步长值；并在可以处理本次任务的处理单元候选集合中设置一个搜索基准指针，指向位于搜索起始位置的处理单元；

所述步骤b所述的负载分担算法包括以下步骤：

b1、本处理单元在可以处理本次任务的处理单元候选集合中，从所述搜索基准指针所指的处理单元开始，比较搜索步长值个数的处理单元的负载情况，并从中选择负载最轻的处理单元；

b2、将所述搜索基准指针向前移动所述搜索步长值的一半，作为下一次搜索的起始搜索点。

Images