CN101854299A - 一种发布/订阅系统的动态负载平衡方法 - Google Patents

Abstract

本发明公开了一种发布/订阅系统的动态负载平衡方法。所述系统包括由多个服务器组成的对等覆盖网络，网络中的各个服务器均作为接入服务器接收订阅和事件信息，并通过全局路由表确定该信息所属的事件渠道后将其转发至该事件渠道进行处理；该系统在运行过程中进行动态负载平衡，动态负载平衡包括：负载过重的服务器从本地选择转移负载并在其他服务器中选择负载接收服务器，将该转移负载发送至该负载接收服务器。本发明可用于金融服务、新闻服务、传感器网络、RFID应用等多个领域。

Description

一种发布/订阅系统的动态负载平衡方法

技术领域

本发明涉及一种基于渠道的发布/订阅系统的动态负载平衡方法。

背景技术

发布/订阅系统(publish/subscribe)是一种信息交互和共享的中间件。在发布/订阅系统中，主要有三个参与方，发布者以事件(event)的形式产生数据，并将事件发布到系统中；订阅者通过订阅(subscription)向系统声明它们感兴趣的事件；发布/订阅系统将事件与系统中已收到的订阅进行匹配，并且向订阅了该事件的订阅者发出事件通知。系统的主要接口包括发布事件(publish)、添加订阅(subscribe)、取消订阅(unsubscribe)和事件通知(notify)。发布/订阅系统的基本结构如图1所示。通过发布/订阅系统，发布者和订阅者之间的交互在空间、时间和控制流上完全解耦。

大规模分布式的发布/订阅系统具有客户/多服务器体系结构，其中的服务器也称为事件代理服务器(Event Broker)或者代理(Broker)，这些服务器组织成为一定的拓扑结构，如图2所示。每个服务器都可以作为接入服务器接收订阅者的添加订阅消息和发布者的发布事件消息。在发布/订阅系统中，一个关键技术就是事件/订阅路由算法，路由算法负责将系统中的事件消息、订阅消息、取消订阅消息按照一定的规则从接入服务器转发到目的服务器。

发布/订阅系统在金融服务、新闻服务、传感器网络、RFID应用等多个领域有很大的实际应用价值，普适环境下大规模多种类事件给发布/订阅系统带来了更多的系统效率和自适应问题。当系统规模很大，订阅和事件数目很多时，系统整体处理的负担加重，同时可能造成某些服务器负载过重，形成性能瓶颈；网络中事件/订阅路由消息过多，容易造成网络拥塞。因此，需要设计实现高效的事件/订阅路由算法，提高系统的灵活性与可伸缩性，满足大数据量处理和适应负载动态变化的需求。

发布/订阅系统通常建立在一个由服务器组成的覆盖网络(Overlay)上，其中，服务器通常被组织成层次结构或者平面结构，覆盖网络结构一般是静态的，拓扑结构的改变比较少，服务器之间通过底层的通信协议进行通信。

在现有的一些事件/订阅路由算法中，有一类称为渠道路由，其中，一个渠道与某种特定的事件类型关联。渠道路由方法对于接收到的每一个订阅和事件，都会计算出相应的渠道，并将其传递给那些渠道进行处理。也就是说，给定一个订阅，系统将会计算出关于该订阅所属的渠道，这些渠道将负责存储该订阅并将满足该订阅的所有事件转发至订阅者；给定一个事件，也会计算将返回一个这个事件所属的渠道，该渠道负责将该事件与系统中的订阅匹配，并转发给相关订阅者。采用渠道路由，系统中的每个服务器只需保存系统中的一部分订阅，每一个事件到达时只访问系统中的一部分服务器，这样，降低了整个网络中需要转发的消息数目和总的计算开销。Meghdoot(Gupta，A.，Sahin，O.D.，Agrawal，D.，and Abbadi，A.E.Meghdoot：content-based publish/subscribe over P2P networks.InProceedings of the 5th ACM/IFIP/USENIX international Conference on Middleware，Toronto，Canada，18-22 October，2004.Middleware Conference，vol.78.Springer-Verlag New York，NewYork，NY，pp.254-273.)和Hermes(Pietzuch，P.R.and Bacon，J.Peer-to-peer overlay brokernetworks in an event-based middleware.In Proceedings of the 2nd international Workshop onDistributed Event-Based Systems，San Diego，California，08-08 June，2003.DEBS′03.ACM，New York，NY，pp.1-8.)等系统使用了这种路由算法。

对于渠道的划分方法，主要包括两种，分别是事件空间划分(Event Space Partitioning，ESP)和订阅集合划分(Filter Set Partitioning，FSP)。

在事件空间划分方式下，系统所能处理的整个事件空间被划分成多个互不相交的子事件空间，这些子事件空间分配到网络中的服务器，由它们进行管理。一个订阅如果与某些服务器所管理的事件空间有重叠，那么该订阅就存放在这些服务器上；一个事件可以看成是事件空间中的一个点，它将被转发至所属的唯一事件空间所在的服务器上进行匹配。基于事件空间划分的主要优点在于每个事件至多只会转发到网络中的一个服务器，从而降低了网络中的事件流量。它的不足在于，如果一个订阅与多个子事件空间都有重叠，那么它可能被传递到多个服务器，从而增加了系统中总的订阅消息流量。另外，由于一个订阅可能存放在多个服务器中，使得订阅的更新也变得复杂。Tarkoma(Tarkoma，S.Dynamiccontent-based channels：meeting in the middle.In Proceedings of the Second internationalConference on Distributed Event-Based Systems，Rome，Italy，01-04 July，2008.DEBS′08，vol.332.ACM，New York，NY，pp.47-58.)给出了一种基于事件空间划分的动态渠道路由算法。

在订阅划分的方式下，每一个订阅只被一个服务器管理，相似的订阅将会被存放在同一个服务器上。每个服务器上的订阅集合用一个概要订阅(Summary Subscription)表示，不同服务器的概要订阅可能重叠。如果一个事件被某些服务器的概要订阅所确定的空间包含，那么该事件将会被转发至这些服务器上进行处理。显然，订阅划分方式与事件空间划分方式相比降低了订阅消息的流量，而增加了事件消息的流量。Zhang(Zhang，C.，Krishnamurthy，A.，Wang，R.Y，and Singh，J.P.Combining flexibility and scalability in apeer-to-peer publish/subscribe system.In Proceedings of the ACM/IFIP/USENIX 2005international Conference on Middleware，Grenoble，France，01-01 November，2005.G.Alonso，Ed.Middleware Conference.Springer-Verlag New York，New York，NY，pp.102-123.)给出了基于订阅划分的渠道路由算法。

目前，发布/订阅系统中的负载平衡问题现有的研究还比较少。Cheung(Alex YeungCheung，A.K.and Jacobsen，H.Dynamic load balancing in distributed content-basedpublish/subscribe.In Proceedings of the ACM/IFIP/USENIX 2006 international Conference onMiddleware，Melbourne，Australia，01-01 November，2006.M.Henning and M.van Steen，Eds.Middleware Conference.Springer-Verlag New York，New York，NY，pp.141-161.)基于PADRES(Li，G.and Jacobsen，H.Composite subscriptions in content-based publish/subscribesystems.In Proceedings of the ACM/IFIP/U SENIX 2005 international Conference onMiddleware，Grenoble，France，01-01 November，2005.G.Alonso，Ed.Middleware Conference.Springer-Verlag New York，New York，NY，pp.249-269.)给出了一个负载平衡框架、负载估计算法和负载划分算法。我们注意到PADRES的路由方法是基于广告的，而在现有的渠道路由研究中，系统的负载平衡问题研究的还相对较少，例如如何衡量服务器上的负载、如何衡量每个订阅所产生的负载等问题仍然没有一个明确的定义，内容空间的划分标准以及划分优劣的评价仍然没有一个统一的衡量标准。

发明内容

针对上述的现有的路由算法中存在的问题和不足，本发明的目的是提供一种发布/订阅系统的动态负载平衡方法，该方法采用高效的路由算法，使得网络中的各个服务器的处理负载均衡，同时降低事件传递开销，减少事件的处理延迟。

所述发布/订阅系统包括由多个服务器组成的对等覆盖网络(Broker Overlay)，网络中的各个服务器均作为接入服务器接收订阅和事件信息(订阅信息主要包括订阅和取消订阅，事件信息主要包括发布事件)，并通过全局路由表确定该信息所属的事件渠道后将其转发至该事件渠道进行处理；该系统在运行过程中进行动态负载平衡，动态负载平衡包括：负载过重的服务器从本地选择转移负载并在其他服务器中选择负载接收服务器，将该转移负载发送至该负载接收服务器。

本发明涉及的发布/订阅系统将事件空间划分为多个子事件空间，并将其映射为渠道，再将事件渠道划归到不同的服务器负责，当事件或订阅到达服务器后，该服务器检查它属于哪些渠道，然后转发至目的渠道进行处理。在路由协议的执行过程中，系统会实时的监测各个渠道的负载，进而监测网络中各个服务器的负载状况，并采用相应的负载平衡策略调整渠道的部署，平衡各服务器之间的处理负载。原子路由协议的整体目标是使得网络中的各个服务器的处理负载均衡，同时降低网络开销，减少事件的处理延迟。

该方法主要包括以下几个方面：

1)网络拓扑结构的建立。系统中的所有服务器组织成为一个覆盖网络，在这个覆盖网络中，每个服务器都可以与其他服务器直接通信，而不管它们底层是否直接连通；各个服务器都是对等的，都可以作为接入服务器接收订阅者的添加订阅消息和发布者的发布事件消息。

2)系统的初始化。将系统所能处理的所有事件组成的事件空间表示的渠道称为全事件渠道，在系统初始化时，选择一个服务器作为初始化服务器，将全事件渠道放置在初始化服务器上。初始化服务器建立本地渠道表，表中只有一项，即全事件渠道。初始化服务器生成一个全局路由表，每个表项是渠道到服务器的映射，即<渠道，服务器>，表示渠道的放置位置。初始化的全局路由表只有一项，即<全事件空间渠道，初始化服务器>，将全局路由表包装到一个渠道初始化消息中，传递至网络中的所有其他服务器。网络中的服务器接收到渠道初始化消息后，在本地建立本地渠道表和全局路由表。在初始化时，除了初始化节点，其他服务器的本地渠道表均为空。

3)处理订阅。系统初始化后，网络中的任意一个服务器都可以作为订阅者的接入服务器接收订阅消息/取消订阅消息。某个服务器作为接入服务器接收到了从订阅者发出的订阅消息/取消订阅消息，那么该服务器首先查询全局路由表，得到该订阅所属的渠道集合，进而得到该订阅应该在哪些服务器上处理。如果需要在本地的某些渠道进行处理，则在本地渠道上对订阅消息/取消订阅消息进行处理；如果还需要转发至其他服务器上，那么将该消息转发至目的服务器，并且在转发消息中加入该订阅属于的在目的服务器上的渠道的标识。

如果某个服务器接收到了从其他服务器转发过来的订阅消息/取消订阅消息和订阅/取消订阅属于的本地渠道的标识，那么服务器不需要再查询全局路由表，直接将订阅/取消订阅交给本地渠道处理。

4)处理事件。系统初始化后，网络中的任意一个服务器都可以作为发布者的接入服务器接收事件。某个服务器作为接入服务器接收到了从发布者发出的事件消息，那么该服务器首先查询全局路由表，得到该事件所属的渠道(事件只可能属于某一个事件渠道)，进而得到该事件应该在哪个服务器上处理。如果需要在本地的渠道进行处理，则在本地渠道上对订阅消息/取消订阅消息进行处理；如果事件需要被在其他服务器上的渠道处理，那么将该消息转发至目的服务器，并且在转发消息中加入该事件属于的在目的服务器上的渠道的标识。

如果某个服务器接收到了从其他服务器转发过来的事件消息和事件属于的本地渠道的标识，那么服务器不需要再查询全局路由表，直接将事件交给本地渠道处理。如果有订阅与事件匹配了，那么将向订阅了该事件的订阅者发送事件通知。

5)监测负载状态。当渠道处理属于它的事件时，会调用渠道所在服务器上的匹配模块，将事件与订阅进行匹配。在事件进行匹配时，将记录由于该事件匹配在该事件渠道上产生的负载。服务器上的负载等于放置在该服务器上的各个渠道负载之和，所以进而可以得到服务器上的负载。各个服务器在系统运行时会定期的向所有邻居发送自己的负载信息；服务器接收它的邻居发送过来的负载信息，从而得知整个网络的负载状况。

6)负载平衡过程。服务器在得知整个网络的负载状况之后，如果发现自己的负载过重，那么将以一定的概率触发负载平衡过程。负载过重的服务器作为负载移出服务器，从负载较低的邻居服务器中选择出负载接收服务器，并在负载移出服务器的本地渠道中选择出可以转移出去的渠道。在选择负载接收服务器和负载移出渠道时，需要考虑不同的因素，使得转移开销尽量小，负载平衡效果较优，并且在选择的过程中，可能涉及渠道的分割或者合并。在选择出负载接收服务器和负载移出渠道后，在负载移出服务器和负载接收服务器之间就会建立负载转移会话，转移渠道进而转移负载。

进一步地，上述步骤5)所述的监测负载过程具体为：

负载平衡算法的执行过程分成一个个时间片T，在每个时间片内监测本地负载和其他服务器的负载，并根据自身与其他服务器的负载状况决定是否启动负载平衡过程。

在每个时间片T内，服务器会接受其他服务器传递过来的负载交换消息，并且在时间片结束的时候，根据本地服务器的负载信息，生成一个负载交换消息，发送给网络中其他所有服务器。服务器会根据邻居的负载信息以及自己的负载信息计算出包括网络中平均负载水平等数据，分析自己的负载平衡状态，如果发现本地服务器负载过重，那么将以一定概率调用负载平衡算法，开始平衡过程。

对于一个渠道，在匹配属于该渠道的某个事件时，测试到的订阅的数目(不论该订阅是否与事件匹配成功，只要在匹配过程中参与了测试就计算在内)，称为匹配这个事件的开销，在时间片T内渠道处理的所有事件的开销之和就是渠道在时间片T内的负载，服务器在时间片T内的负载等于该服务器上各个事件渠道的负载之和。

具体的负载检测流程可按下列实例进行：

0.各个服务器在初始化时默认自己的负载状况是低负载状态；

1.从网络中的其他服务器接收到负载信息交换消息，得到其他服务器的负载信息；

2.对于从邻居服务器接收到的每一个负载交换消息，根据它们是否负载过重，分别放入两个链表中保存；

3.在时间片末，计算出自己的负载值。如果已经得到所有邻居的负载消息，那么计算出平均负载；

4.根据自己的负载状态，生成一个新的负载交换消息，将这个消息发送给网络中的其他服务器；

5.如果当前服务器处于负载过重的状态，那么以一定概率调用负载调度算法，平衡服务器之间的负载；

6.时间片T结束，继续1。

进一步地，负载平衡过程，即上述步骤6)，分为两个阶段：负载调度(选择出负载接收服务器和负载转移渠道)和负载转移。负载调度使用一组评估函数选择出负载接收服务器和需要转移的渠道，在评估函数的执行过程中可能会分割/合并本地已有的渠道。负载转移定义了在负载移出服务器和负载接收服务器之间的通信协议，将移出渠道和相关订阅由负载移出服务器转移到负载接收服务器上，完成负载平衡过程。

本发明采用基于渠道的路由方法，能够将事件的处理责任分布到网络中的不同服务器上，在处理订阅和事件消息时，至多在网络中转发一次，即可由接入服务器转发至目的服务器进行处理，从而减少了网络中的消息流量，降低网络负载；事件在网络中的服务器上仅需要匹配一次，就可以得到对它感兴趣的订阅者。同时，本发明中为渠道路由算法加入了负载平衡机制，系统一直监测整个网络的负载状况，在负载不平衡的情况发生时，可以启动负载平衡的过程，平衡服务器之间的负载。与现有的渠道路由协议相比，可以防止热点区域的产生，进而降低事件的处理延迟，提高事件的处理效率。

附图说明

图1是现有发布/订阅系统的基本结构示意图；

图2是现有的服务器拓扑结构示意图，其中1-事件服务器，2-发布者/订阅者；

图3是本发明的渠道路由服务器覆盖网络示意图；

图4是事件空间与订阅关系示意图；

图5是服务器状态转换示意图。

具体实施方式

下面通过具体实施例对本发明作更为详细的描述。

本发明将系统中的服务器组织成为一个对等覆盖网络，在这个覆盖网络中，服务器之间可以直接通信。在系统建立之初，首先任意选择一个服务器作为初始化服务器，在这个服务器上部署上全事件渠道，建立全局路由表，并将这个全局路由表转发至网络中的其他服务器；然后各个服务器可以作为接入服务器接收用户的订阅或者事件消息，通过查询全局路由表，可以得到订阅或者事件应该被哪些服务器处理。在系统正式运行时，部署在每个服务器上的负载平衡模块会不断的监测各个服务器上的负载并在服务器之间交换负载信息，在负载不平衡的状况发生时，开始负载平衡过程，调度负载，使得各个服务器之间的处理负载分布均匀。

[1].首先详细介绍本发明中服务器覆盖网络的建立。不考虑网络中的服务器是如何硬件连通的，在覆盖网络层任意两个服务器之间是可以连通的，每一个服务器都知道网络中所有服务器的IP地址。一个服务器可以通过IP地址和另外的任何一个服务器进行通信，消息的传输使用TCP完成。底层的物理链路发生改变，不影响应用层上两个服务器之间的通信，只要它们之间仍有可以连接的通路。网络拓扑结构如图3所示，服务器之间的物理连接使用虚线表示，当服务器A与服务器D之间的物理链路断开时，A向D发送的消息可以通过路径A→C→E→D到达服务器D。

另外，服务器上的网络接口模块使用MINA(Apache MINA Project.http://mina.apache.org/)网络框架开发，负责服务器间接收/发送各种消息，包括事件消息、订阅消息、路由表更新消息、渠道转移消息、负载监测消息等。网络接口模块包括消息接收队列和消息发送队列，在接收消息队列不为空时，系统按照消息到达的先后顺序，对消息队列中的消息逐一进行处理；在发送队列不为空时，系统按照进入队列的先后顺序逐一将消息发送出去。消息接收队列/消息发送队列包括两种，一种是常规消息接收/发送队列，用于接收/发送普通的事件、订阅和取消订阅消息，另外一种是高优先级队列，用于接收/发送事件渠道初始化消息、负载平衡相关的消息等具有高优先级的消息。在高优先级队列不为空时，系统总是先处理高优先级队列中的消息，然后才是常规队列中的消息。

[2].下面详细介绍本发明涉及的订阅、事件和事件空间的定义以及它们之间关系的定义。

基于内容的发布/订阅系统中的谓词、订阅、事件项、事件定义如下：一个谓词f定义为一个四元组，即f＝(type，attr，op，cons)，其中type表示该谓词的取值类型，attr表示属性名称，op表示谓词所允许使用的操作符，cons表示该谓词在该属性上的约束值。一个订阅F是若干谓词的合取，可以表示为F＝f₁∧f₂∧...∧f_n。一个事件项α是一个三元组，即α＝(type，attr，value)，其中type是取值类型，attr是属性名称，value是事件项的取值。一个事件是若干事件项的合取，所以，一个事件e可以表示为e＝α₁∧α₂∧...∧α_k。

对于谓词f＝(type，attr，op，cons)，我们定义L(f)为f的约束值域，即在属性attr上满足f的所有类型为type的值的集合。对于事件项α＝{type_e：attr_e，val_e}和谓词f＝{type：attr，op，val}，我们说事件项α满足谓词f，即f＞α，当且仅当type＝type_e∧attr＝attr_e∧val_e∈L(f)。

一个订阅F＝f₁∧f₂∧...∧f_n，事件e＝α₁∧α₂∧...∧α_k，事件e满足订阅F，即e∈F，当且仅当

f_i＞α_j。

另外，谓词之间、订阅之间还存在着覆盖关系，下面给出谓词之间和订阅之间覆盖关系的定义。

对于谓词f₁＝{type₁：attr₁，op₁，val₁}和谓词f₂＝{type₂：attr₂，op₂，val₂}，如果满足f₂的事件项一定满足f₁，那么称f₁覆盖f₂，即f₁＞f₂。形式化的描述为：f₁＞f₂，当且仅当，

覆盖关系是自反的，f₁覆盖f₁自身。

一个订阅F¹＝f₁ ¹∧f₂ ¹∧...∧f_m ¹，，另一个订阅F²＝f₁ ²∧f₂ ²∧...∧f_n ²，如果满足F²的事件一定满足F¹，那么称订阅F¹覆盖订阅F²，即

形式化的描述为：

当且仅当，

f_i ¹＞f_j ²。

本发明采用事件空间划分的机制，将内容空间进行划分，进而将划分后的事件空间映射为事件渠道。事件空间的表示也类似订阅，可以表示为Es＝f₁∧f₂∧...∧f_is∧...∧f_n，其中谓词f_i(1≤i≤n)表示了在某种属性上的约束，用于限定事件空间在该属性维度上的范围。如果某属性不出现在事件空间的表达式中，表明该属性在该事件空间上值可以取值域中的任一个。所以，如果定义事件空间的表达式中的谓词数目为0，则对所有的属性的取值都没有限制，那么该事件空间就是全事件空间，为了简单起见，记为WES。

事件空间E_s覆盖事件e表示为e∈Es；事件空间E_s覆盖订阅F表示为

事件空间E_s与订阅F有重叠表示为

一个事件空间E_s＝f₁ ^Es∧f₂ ^Es∧...∧f_n ^Es，事件e＝α₁∧α₂∧...∧α_k，事件空间E_s覆盖事件e(或者说事件e在事件空间ES中、事件e属于事件空间ES)，即e∈Es，当且仅当

f_i ^Es＞α_j(1≤i≤n，1≤j≤k)。事件空间E_s＝f₁ ^Es∧f₂ ^Es∧...∧f_n ^Es和订阅F＝f₁ ^F∧f₂ ^F∧...∧f_m ^F，事件空间E_s覆盖订阅F，即

当且仅当f_i ^Es＞f_j ^F。事件空间E_s＝f₁ ^Es∧f₂ ^Es∧...∧f_n ^Es，一个订阅F＝f₁ ^F∧f₂ ^F∧...∧f_m ^F，二者存在重叠关系，即当且仅当

如果一个订阅F被一个事件空间E_s覆盖或者与E_s有重叠关系，那么就称订阅F属于事件空间E_s。

图4给出了一个二维的事件空间，它被分割成了6个子事件空间E₁，E₂，E₃，E₄，E₅，E₆，其中订阅Sub₁，Sub₂和Sub₃属于E₁，Sub₃，Sub₄，Sub₅和Sub₆属于E₂，Sub₆，Sub₇和Sub₈属于E₃，Sub₉属于E₄，Sub₁₀和Sub₁₁属于E₅，Sub₁₀和Sub₁₂属于E₆。并且在图4中，矩形之间的包含表示了订阅之间的覆盖关系，矩形之间的重叠表示了订阅与事件空间、订阅与订阅之间的重叠关系。同时也可以看出，一个订阅可能会属于多个事件空间。

[3].下面介绍本发明中事件渠道的定义。

一个事件渠道ch(Event Channel，或简称为渠道)包含这个渠道的事件空间Es和属于Es的订阅的集合S。在事件渠道上除了保存有该渠道上的事件空间和订阅的集合之外，还包括采样统计时间片内落在该渠道上的事件的集合等，这些信息都是为了后续监测渠道上的负载和进行渠道分割等操作设置的。另外，在表示时，可以将渠道简化表示为CH＝<Es，S>这种二元组的形式。

定义EC为所有事件渠道的集合，即全事件渠道。一个事件渠道被放置到唯一的服务器上，一个服务器上可以放置有多个事件渠道。每个事件渠道都包含有一个唯一的id作为它在网络中的唯一标识，这个id是建立这个事件渠道的服务器赋给的(初始化时或者渠道分割或合并时)，包括服务器的标识和服务器本地的一个序列号，所以id是全局唯一的。

[4].下面介绍服务器上的本地渠道表(localTable)和全局路由表(routingTable)。

在服务器上保存着两个表，一个表称为本地渠道表(localTable)，表项为事件渠道，记录着放置在这个服务器上的渠道，另外一个表称为全局路由表(routingTable)，表项为事件渠道到服务器的映射，记录着渠道在服务器上的放置位置。每个服务器的localTable是各不相同的，而routingTable都是一样的。

当订阅消息到达某一个服务器(即，接入服务器)时，接入服务器上通过查询routingTable得到它属于的那些事件渠道，并将该消息转发到相应的渠道进行处理；一个渠道ch接收到订阅消息后，将会把该订阅添加至本地的订阅管理结构中，并根据添加结果，将订阅保存在自己的订阅集合S(使用哈希表实现)中。如果有事件消息到达接入服务器时，路由模块会判断出该事件属于哪个渠道，然后将该事件转发到该渠道进行处理；渠道接收到事件后，会将其进行匹配，并且记录相关的匹配结果和产生的负载。

在系统初始化时，在初始化服务器(initializer broker，ibrk)上部署着全事件渠道EC，routingTable中只有一项，即<EC，ibrk>，并将这个路由表传递给系统中的所有服务器。初始化完成后，系统可以接收订阅和事件，通过查询路由表，将其转发给相应渠道进行处理；并且根据服务器间交换的负载信息，移动渠道，平衡负载。

[5].下面介绍在本发明中渠道路由的属性模式的约定。

在渠道路由中，对订阅和事件有一些约束，例如，系统必须已知所需要处理的所有属性的集合，所有事件和订阅的属性都从这个集合中选取，事件中必须包含的属性的集合也是已知的等。

对于系统所处理的事件和订阅，规定它们的表达式要满足一定的模式(schema)，这个模式规定了系统所处理的事件/订阅的属性种类和约束，包括系统中所能处理的所有属性的集合，事件中必须包含的属性等。

系统所使用的模式更加规范的描述为：S＝{A₁，A₂，...A_i，...，A_n}，其中每一个A_i(1≤i≤n)表示了一个属性，每一个属性包含了属性名称，属性类型和属性值域三个方面的信息，可以表示为{name，type，min，max}。每一个属性由它们唯一确定的属性名称确定，属性的类型是系统所支持的数据类型，例如在本发明的发布/订阅系统中支持数值、字符串和RFID编码(Beihong Jin，Shuang Yu，Xinchao Zhao，Zhenyue Long，Yifeng Qian：Subscribing andMatching RFID-Related Events.ICEBE 2007.pp.41-47.)三种数据类型等，min和max描述了该属性的值域的取值范围。系统中所有的参与方都遵循这个模式。系统中使用的订阅中出现在谓词中的属性集合是模式中规定的属性集合的子集，事件可以表示成为事件中只包含模式中的属性的一个子集。一个事件可以不包含有模式中所列举的所有属性，但是总有一些属性是必选的，在定义系统的属性模式时，也给出了系统中事件需要的必选属性和可选属性。在本发明中给出特征属性(Distinguishing Attributes，DA)集合的概念，DA＝{DA₁，DA₂，...，DA_m}，也就是所谓的必选属性。事件中的属性集合必须包含特征属性集。并且，用于表示或划分事件空间的属性，也必须从DA集合中选取，这样，可以保证事件总是事件空间中的一个点，从而只能属于唯一的一个事件空间，进而只能被唯一的一个事件渠道处理。在系统初始化的时候，这个模式就已经预先在各个服务器上配置好了。

选择划分事件空间的属性需要满足下列条件：首先这些属性是从DA集合中选取的，而且，可以给这些候选属性设定优先级，选取划分事件空间的属性时更倾向于使用数值类型，然后是RFID编码类型，最后才是字符串型。同时，给出了一个特征属性attr的流行度的概念：

属性的流行度用于定义同种类型的特征属性的优先级，一个属性的流行度值越大，说明关注这个属性的订阅越多，那么它的优先级就越高，在划分事件空间时就越倾向于选取它。

[6].下面，给出在本发明的路由算法中动态负载平衡的问题定义。

假设在系统中包含有n个服务器，渠道总数是m(m的值是可以根据渠道分割或者合并的结果动态变化的)。令g_i表示一个服务器，1≤i≤n。假设在服务器g_i上有m_i个事件渠道。令ch_ik表示在服务器上g_i的第k渠道，1≤i≤n并且1≤k≤m_i。渠道ch_ik的负载是d_ik，c_i是g_i的处理能力。g_i的处理能力可通过测试服务器的处理能力给出。

定义dc_i作为一个服务器g_i的负载水平(Load Level)，

令

是网络中n个服务器负载水平的平均值，即

δ的值是所有服务器的负载水平的标准差。使用一个参数δ去衡量不同的负载转移策略的效果，希望δ的值在渠道转移之后变小。

假如一个渠道要从服务器g_i转移到g_j，那么转移开销mig_cost{ch_ik→g_j}可以定义为

其中mig_chsize_ikj(ch_ik)是需要转移的渠道的大小，可以用需要转移出去的订阅数目衡量它，bw_ij是服务器g_i与g_j之间的网络带宽。

在网络中包含n个服务器、m个渠道的情况下，希望能够找到一种使得δ和mig_cost的值最低的转移策略。

服务器负载过重和负载过轻的定义如下：如果

那么负载过轻，它的负载状态即为UNDERLOADED；如果

那么负载过重，负载状态为OVERLOADED。Δd是一个根据应用或经验设定的值。

如果一个服务器的负载非常接近

并且通过移动渠道不能到达更好的状态，那么它为负载平衡状态，即STABLE，它的负载水平满足

如果服务器处于负载平衡状态，那么负载调度算法将不会被调用。可以定义

其中δ∈(0，1)，δ在实际使用时可以选取0.1，作为Δd的一个参考值。

如果一个服务器的负载状态为OVERLOADED，即负载过重状态，负载调度算法则可能被调用。当负载调度算法执行时，调度算法中各个参与方的状态设置为BUSY，表明它正处在负载调度算法执行过程中。图5给出了服务器的状态转换图。

[7].下面介绍在本发明中对渠道上以及服务器上的负载的估算。

定义在采样统计时间片T内服务器brk上的负载等于该服务器上各个事件渠道的负载之和：

${\mathrm{LD}}_{\mathrm{brk}}=\underset{{\mathrm{ch}}_i\&Element;{\mathrm{CH}}_{\mathrm{brk}}}{\mathrm{\&Sigma;}}{\mathrm{LD}}_{{\mathrm{ch}}_i}$

系统将一直监测各个事件渠道上的负载，记录每个采样统计时间片T内的负载。

一个事件渠道ch上的负载计算公式定义为：

${\mathrm{LD}}_{\mathrm{ch}}=\underset{e\&Element;\mathrm{ch}}{\mathrm{\&Sigma;}}{\mathrm{sub}}_e$

sub_e表示服务器在匹配一个事件e时测试到的订阅的数目(不论e是否匹配该订阅，只要在匹配过程中测试了的订阅就计算在内；原子订阅匹配模块只会测试属于渠道ch的订阅，不属于ch的订阅都已经被过滤，不会被测试)，用这个数值表示匹配该事件所需要的资源开销。采用将订阅匹配的开销与订阅数目联系起来的负载定义方式的好处是，在划分出去事件空间的时候，可以通过观察划分出去某一部分事件空间可以使多少订阅划分出去，得到对负载移出服务器和负载接收服务器上负载的影响。

[8].下面介绍本发明中的负载系统的平衡算法。

负载平衡算法的执行过程分成一个个时间片T(即前面提到的采样统计时间片)，在每个时间片内监测本地负载和其他服务器的负载，并根据自身与其他服务器的负载状况决定是否启动负载平衡过程。

服务器在每个时间片T内都交换负载信息，根据这些信息，可以在发生负载过重或者负载不平衡的时候触发负载调度算法，平衡负载。

服务器之间交换的消息称为负载信息交换消息(Load Information Exchange Message，LIEM)。一个LIEM消息包含4个属性：(1)服务器的唯一标识，(2)该服务器负载平衡的状态，可以是UNDERLOADED，STABLE，OVERLOADED，或者BUSY，(3)该服务器的负载水平dc，(4)该服务器的处理能力c。

在每个时间片T内，服务器会接受其他服务器传递过来的LIEM消息，并且在时间片结束的时候，根据本地服务器的负载信息，生成一个LIEM消息，发送给网络中其他所有服务器。服务器会根据邻居的负载信息以及自己的负载信息计算出包括网络中平均负载水平等数据，分析自己的负载平衡状态，如果发现本地服务器负载过重，那么将以一定概率调用负载平衡算法，开始平衡过程。

[9].下面给出动态负载平衡算法的流程描述。

0.各个服务器在初始化时默认自己的负载状况是UNDERLOADED；

1.从网络中的其他服务器接收到负载信息交换消息LIEM，得到其他服务器的负载信息；

2.对于接收到的每一个LIEM(发送者为gj)，如果gj的状态是UNDERLOADED，那么就把它加入到链表uNodeList(如果gj已经保存在oNodeList之中，那么需要先把它从oNodeList中删除)，如果状态是OVERLOADED，那么把它加入到链表oNodeList中(同样，如果已经保存在uNodeList中，需要先把它从uNodeList中删除)，这两个数据结构将在负载调度算法中用到；

3.在时间片末，计算出自己的dc值。如果已经得到所有邻居的负载消息，那么计算出平均负载

，并根据前面给出的服务器状态定义，更新自己的负载状态为UNDERLOADED/OVERLOADED/STABLE；

4.生成一个新的负载交换消息，将这个消息发送给网络中的其他服务器；

5.如果当前服务器处于OVERLOADED的状况，那么以一定概率调用负载调度算法，开始负载调度过程，平衡服务器之间的负载；

6.时间片T结束，继续1。

对于时间片T的选择，有这样的考虑：如果时间片太短，那么在较短的时间内我们将不能得到正确的事件分布信息，从而不能得到正确的负载分布信息，这样得出的结果往往会造成系统负载转移的抖动，在具体选择T的初始值时，需要考虑系统所在的应用场景，对事件流的模式变化周期有一个估计值，并根据此估计值设置T的初始值。如果在负载平衡算法当中发现负载调度算法非常频繁的执行(例如连续多次检测到在每两个时间片T内就会调用一次负载调度算法)，那么系统就需要自动的将T适当延长(例如延长至原值的150％)，以能够得到更加准确的事件流信息，防止抖动的发生。并且，在本地服务器发现自己是OVERLOADED状态时，并不会立刻启动负载调度算法，而是以一定的概率调用负载调度算法(例如在实现时以50％的概率调用)，以防止抖动的发生。

另外，服务器g_i在得到网络中的某个服务器g_j的LIEM消息之后，更新本地的uNodeList和oNodeList两个数据结构时，可以不参看它们的负载状态，而是将g_j的负载水平dc_j与自己的dc_i比较，如果dc_i大于dc_j，那么就将g_j放置在uNodeList中，如果dc_i小于dc_j，则把g_j放置在oNodeList中，以取得更好的负载平衡效果。

[10].下面介绍本发明中的负载调度算法，该算法首先使用一组评估函数选择出负载接收服务器和需要转移的渠道，在评估函数的执行过程中可能会分割/合并本地已有的渠道。然后将选择出的渠道转移到负载接收服务器上，完成负载平衡过程。下面的内容分别介绍了负载评估函数、渠道分割/合并的策略和调度算法。

首先介绍负载调度算法中的负载评估函数。

在发生负载不平衡时进行负载调度，需要确定哪些渠道可以被转移、被转移到哪些服务器上。在渠道转移的过程中，还存在着转移开销，包括从负载移出服务器上选择出要转移的渠道、将渠道及其订阅转移至负载接收服务器上、在负载接收服务器上添加订阅、最后将由于渠道转移而将不再需要的订阅从负载移出服务器上删除等过程的开销。网络中服务器的处理能力可能是不相同的，那么把一个渠道从一个服务器转移到另外一个服务器，即使渠道负载是一样的，但对不同的负载接收服务器，造成的负载改变是不同的。

为了将前面提到的各种因素都考虑进去，并比较不同因素的影响，定义了分级函数(leveling function)，

其中x∈[0，1]，并且

是取整操作符，L是层次的数目，是可以根据需要作出改变的值。这个分级函数可以将x划分到L个层次中。

评估函数包括四个，f₁～f₄，用于找到较好的将负载(渠道)从负载较重的服务器上转移出去的策略。其中，f₁用于评价选择不同的本地渠道作为转移渠道对负载平衡的影响；f₂用于评价选择不同的服务器作为负载接收服务器对负载平衡的影响；f₃用于评价在已经选择出某个负载接收服务器时，选择不同的转移渠道对负载转移开销的大小；f₄用于评价在已经选择出某个负载接收服务器时，选择不同的转移渠道对订阅靠近事件源放置的影响。

负载转移策略的确定分为两个步骤：(1)利用f₂和f₃选定接收负载的服务器；(2)利用f₁，f₃和f₄选定合适的转移出去的渠道。

下面介绍f₁的推导。

为了评估在负载过重的服务器g_i上的某个渠道ch_ik(1≤k≤m_i)转移到某个已经确定的接收负载的目的服务器g_j的效果，定义了第一个评估函数f₁(g_i，g_j，ch_ik)，用于评价选择不同的本地渠道作为转移渠道，对负载平衡的影响。f₁由以下过程推理得出：

如果要比较δ值在ch_ik转移之前和之后的变化，我们只需要保证

$\sqrt{\frac{{\left(\frac{d_i}{c_i}\text{-}\stackrel{\&OverBar;}{\mathrm{dc}}\right)}^2+{(\frac{d_j}{c_j}-\stackrel{\&OverBar;}{\mathrm{dc}})}^2+S}{n}}\&GreaterEqual;\sqrt{\frac{{(\frac{d_i}{c_i}-\frac{x}{c_i}-\stackrel{\&OverBar;}{\mathrm{dc}})}^2+{(\frac{d_j}{c_j}+\frac{x}{c_j}-\stackrel{\&OverBar;}{\mathrm{dc}})}^2+S}{n}}---\left(1\right)$

并且希望

$F\left(x\right)={((\frac{d_i}{c_i}-\stackrel{\&OverBar;}{\mathrm{dc}})-\frac{x}{c_i})}^2+{((\frac{d_j}{c_j}-\stackrel{\&OverBar;}{\mathrm{dc}})+\frac{x}{c_j})}^2---\left(2\right)$

的值最小，其中x是转移出去的渠道上的负载。

解(1)式得到

从而得到， $x\&le;\frac{2(c_j^2(d_i-\stackrel{\&OverBar;}{\mathrm{dc}}\&CenterDot;c_i)-c_i^2(d_j-\stackrel{\&OverBar;}{\mathrm{dc}}\&CenterDot;c_j))}{(c_i^2+c_j^2)}.$

另外，由

所以如果将一个渠道ch_ik转移出去之后，如果d_ik在

之间，那么δ的值在转移之后会变小。而且，选择出需要转移的渠道时，我们尽量选择那些d_ik最接近

的值，这样能够取得更好的负载平衡效果。所以我们定义：

其中，

这样，我们就可以对g_i上的每一个渠道给出一个等级(rank)值，通过这个rank值测定把它们转移出去的优劣。

但是，如果负载过重的服务器上找不到任何渠道ch_ik，满足

那么必须要对渠道进行分割，然后再选择。例如系统在初始化时，只有唯一的一个渠道ch_i1，并且部署在该初始化服务器g_i上，那么d_i＝d_i1，dc_i＝d_i1/c_i，

如果已经选择出来某个服务器g_j作为接收负载的服务器，那么解(1)式之后得到

更加特殊的，假设每个服务器的处理能力都是相同的c，则x≤d_i＝d_i1，那么就必须要对已有的渠道进行分割，将分割后的渠道划分出去。这时，我们将选择服务器上负载最大的那个渠道，然后将其分割成两个部分，使得分割出的那一部分负载最接近上面给出的是需要对渠道进行分割的一种情况，另外，假如在g_i上存在k个渠道，满足

即这些渠道的负载之和与

的差别小于某个限定值ε(实现时ε可选取为0.1*)，那么可以将这些渠道合并，成为一个新的渠道，转移出去。

下面介绍f₂的推导。

为了从负载较轻的服务器中，选择出合适的服务器作为接收负载的服务器g_j(j≠i)，根据服务器上的负载和处理能力，定义了f₂(g_i，g_j，ch_ik)，其中ch_ik是g_i上的一个渠道。f₂根据非合作博弈论(Non-Cooperative Game Theory，John Nash.Equilibrium points in n-persongames.Proc.of the National Academy of Sciences，36，pp.48-49，1950.)得到，用于评估选择不同的服务器作为负载接收服务器的好坏。如果某个服务器总是选择负载最轻的服务器最为负载接收服务器，那么不同的服务器之间很容易会产生选择冲突，而且，可能会导致更加不平衡的状况产生。因此，每一个负载过重的服务器需要根据它的负载需求来选择接收负载的目标服务器。对于负载较重的服务器，在本发明中为它们定义了rank_o值，对于负载较轻的服务器，我们定义了rank_u值，rank_o和rank_u值的定义如下：

${\mathrm{rank}}_o=({\mathrm{dc}}_i-\frac{d_{\mathrm{ik}}}{c_i})/\mathrm{Max}({\mathrm{dc}}_o-\frac{d_{\mathrm{ik}}}{c_o})---\left(3\right)$

${\mathrm{rank}}_u=\mathrm{Min}({\mathrm{dc}}_u+\frac{d_{\mathrm{ik}}}{c_u})/({\mathrm{dc}}_j+\frac{d_{\mathrm{ik}}}{c_j})---\left(4\right)$

其中Max(dc_o-d_ik/c_o)是所有负载较重的服务器中dc_i-d_ik/c_i值最大的那个，Min(dc_u-d_ik/c_u)是所有负载较轻的服务器中dc_j+d_ik/c_j值最小的那个。

一个负载过重的服务器，它评测得到的级别为rank_o，它更愿意选择那些负载级别接近rank_u的节点作为负载接收服务器，所以f₂定义如下：

f₂(g_i，g_j，ch_ik)＝1-|lev(rank_o)-lev(rank_u)|，

其中， ${\mathrm{rank}}_o=({\mathrm{dc}}_i-\frac{d_{\mathrm{ik}}}{c_i})/\mathrm{Max}({\mathrm{dc}}_o-\frac{d_{\mathrm{ik}}}{c_o}),$ ${\mathrm{rank}}_u=\mathrm{Min}({\mathrm{dc}}_u+\frac{d_{\mathrm{ik}}}{c_u})/({\mathrm{dc}}_j+\frac{d_{\mathrm{ik}}}{c_j}).$

下面介绍f3的推导。

根据渠道转移开销

转移渠道的开销与转移出去的渠道的大小以及两个相关服务器之间的带宽相关，由此定义出f₃(g_i，g_j，ch_ik)。首先，从g_j上的m_i个渠道中和所有的负载较轻的服务器中选择出最小的负载转移开销

然后，将可能从g_i转移到g_j上的渠道ch_ik的转移开销与最低的转移开销进行对比，得到评估结果。bw_ij是g_i和g_j之间的带宽，bw_i max表示g_j到所有负载较低服务器的带宽中的最大值。

mig_chsize(ch_ik)是转移出去渠道的大小，使用需要转移出去的订阅的数目来衡量，f₃定义如下：

$f_3(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\min \_\mathrm{mig}\_\cos t}{\mathrm{mig}\_\cos t\{{\mathrm{ch}}_{\mathrm{ik}}\&RightArrow;g_j\}}\right),$

其中， $\min \_\mathrm{mig}\_\cos t=\frac{\min \_\mathrm{mig}\_\mathrm{chsize}\left({\mathrm{ch}}_{\mathrm{iq}}\mathrm{on}{g}_i\right)}{{\mathrm{bw}}_{i\max }},$

$\mathrm{mig}\_\cos t\{{\mathrm{ch}}_{\mathrm{ik}}\&RightArrow;g_j\}=\frac{\mathrm{mig}\_\mathrm{chsize}\left({\mathrm{ch}}_{\mathrm{ik}}\right)}{{\mathrm{bw}}_{\mathrm{ij}}}.$

下面介绍f₄的推导。

由于原子路由同时也为复合路由(Peter R.Pietzuch，Brian Shand，and Jean Bacon.Composite Event Detection as a Generic Middleware Extension.IEEE Network Magazine，Special Issue on Middleware Technologies for Future Communication Networks，18(1)，pp.44-55，January/February，2004.)提供支持，希望尽量使事件的检测结构的放置靠近事件发布者，那么需要考虑将渠道放置在靠近事件发布者的服务器上，将事件渠道放置在接近事件的发布者的接入服务器上。

在g_i上的每一个事件渠道ch_ik上，保存了采样统计时间片T内到达渠道的事件数目n_ik，另外还设置了一个数组，保存了这些事件中分别由网络中的哪个服务器转发过来的数目，例如，由服务器g_j转发过来事件的数目记为n_ikj，如果当前服务器本身就是事件的接入服务器，那么也相应记为n_iki。在渠道路由策略下，事件由接入服务器进入系统，至多被转发一次就可以到达目的渠道进行处理，那么我们可以记录服务器g_j作为事件的接入服务器的概率为acc_rate_ikj＝n_ikj/n_ik。所以f₄定义如下：

$f_4(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{ikj}}}{\max \{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{iqj}},{\mathrm{ch}}_{\mathrm{iq}}\mathrm{ison}{g}_i\}}\right),$ 其中 $\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{ikj}}=\frac{n_{\mathrm{ikj}}}{n_{\mathrm{ik}}}.$

综上，四个评估函数f₁～f₄定义如下：

其中，

f₂(g_i，g_j，ch_ik)＝1-|lev(rank_o)-lev(rank_u)|        (6)

其中， ${\mathrm{rank}}_o=({\mathrm{dc}}_i-\frac{d_{\mathrm{ik}}}{c_i})/\mathrm{Max}({\mathrm{dc}}_o-\frac{d_{\mathrm{ik}}}{c_o}),$ ${\mathrm{rank}}_u=\mathrm{Min}({\mathrm{dc}}_u+\frac{d_{\mathrm{ik}}}{c_u})/({\mathrm{dc}}_j+\frac{d_{\mathrm{ik}}}{c_j});$

$f_3(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\min \_\mathrm{mig}\_\cos t}{\mathrm{mig}\_\cos t\{{\mathrm{ch}}_{\mathrm{ik}}\&RightArrow;g_j\}}\right)---\left(7\right)$

其中， $\min \_\mathrm{mig}\_\cos t=\frac{\min \_\mathrm{mig}\_\mathrm{chsize}\left({\mathrm{ch}}_{\mathrm{iq}}\mathrm{on}{g}_i\right)}{{\mathrm{bw}}_{i\max }},$

$\mathrm{mig}\_\cos t\{{\mathrm{ch}}_{\mathrm{ik}}\&RightArrow;g_j\}=\frac{\mathrm{mig}\_\mathrm{chsize}\left({\mathrm{ch}}_{\mathrm{ik}}\right)}{{\mathrm{bw}}_{\mathrm{ij}}};$

$f_4(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{ikj}}}{\max \{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{iqj}},{\mathrm{ch}}_{\mathrm{iq}}\mathrm{on}{g}_i\}}\right)---\left(8\right)$

其中， $\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{ikj}}=\frac{n_{\mathrm{ikj}}}{n_{\mathrm{ik}}}.$

[11].在使用上面的评估函数选择负载接收服务器和转移出去的渠道过程中，可能会涉及到渠道的分割/合并，所以下面介绍事件渠道的分割/合并策略。

首先介绍如何分割事件渠道。

已知特征属性集合DA＝{DA₁，DA₂，...，DA_m}，一个事件渠道ch＝<E_s，S>，其中ES＝f_DA1∧f_DA2∧...∧f_DAk，1≤k≤m是事件空间；f_DAi(1≤i≤k)是在某个特征属性上的约束。另外已知该事件渠道上的负载LD，需要划分出去的负载为ΔLD。需要选取出属性作为划分属性，将渠道分割，并且分割出来的两个新的渠道，其中之一的负载等于ΔLD。

首先，我们需要从特征属性中选取出作为划分属性的属性。对特征属性集合中的属性首先按照类型、流行度进行排序，得到特征属性的优先级顺序，然后试图从优先级最高的属性开始，选择它作为划分属性对渠道进行划分；如果选择出来的属性不合适划分，那么将会选择优先级排序结果中的下一个属性，作为划分属性，继续进行划分，直到找到合适的划分方式。

对于数值和RFID编码类型的属性，由于它们的谓词都可以表示成为一个区间的形式，所以，可以将它们原来的值域划分为连续的区域。而对于字符串类型，尤其是引入了取前缀，取后缀，取子串等复杂的字符串操作符之后(Beihong Jin，Xinchao Zhao，Zhenyue Long，Fengliang Qi，Shuang Yu，Effective and Efficient Event Dissemination for RFID Applications，The Computer Journal，doi：10.1093/comjnl/bxn063)，很难找到一种很好的划分字符串的方式，目前采取的方式是划分字符串集合。

如果某个属性DA_str＝{name，type，valDomain}是字符串类型的属性，需要划分的渠道中的事件空间表示为E_s，采用DA_str作为划分属性时的具体规则如下：

如果DA_str还没有加入到事件空间的表达式中，即

那么统计包含落在所在事件渠道上的事件在该属性上的值，得到一个值的集合valSet，然后如果需要使用该属性进行划分，那么将这个集合进行分割，例如分成valSet1和valSet2。valSet1部分作为分割出去的事件空间在该属性上的字符串约束，称为类型1的字符串约束；另外一个渠道在该属性上的约束该属性上的约束为valDomain/valSet1，称为类型2的字符串约束，记录为{valSet2，valDomain/ValSet1}。并且如果有新到来的事件包含DA_str属性，那么就把新的值加入到valSet2中，以备以后划分使用。

如果DA_str已经是事件空间表达式中的一个属性，并且是类型1的约束，那么就直接把集合分割就可以了，分割出来的属性都是类型1的字符串约束；如果是类型2的约束，表示为{valSet2，valDomain/ValSet1}，那么就从valSet2中分割出来新的集合valSet3和valSet4，其中valSet3作为一个新的渠道在该属性上的约束，当然该约束是属于类型1的字符串约束，另外一个渠道在该属性上的约束就表示为{valSet4，valDomain/(ValSet1∪valSet3)}，同样是类型2的字符串约束，并且如果有新到来的事件包含DA_str属性，那么就把新的值加入到valSet4中，以备以后再次划分使用。

有了前面给出的特征属性的优先级的定义，下面我们说明如何使用这些特征属性划分事件空间。假如特征属性按照优先级排列为DA＝{DA₁，DA₂，...，DA_m}，那么在每个采样统计时间片T内，每个渠道都对落入这个渠道的事件给出一个记录<e_i，num_i>，并将所有的事件记录保存到一个队列中。事件记录在这个队列中是有顺序的，排在最前面的是在按照落入这个渠道的在属性DA₁上值最小的那个事件，如果两个事件在DA₁上值相同，那么就按照下一个属性DA₂上的值的大小关系排序，如果仍旧相同则采用下一个属性上的值进行比较，以此规则，使得所有的事件有序记录在队列中。对数值和RFID编码类型的属性，只需要比较它们的值的大小就可以了；对于字符串类型的属性，我们就根据它们字符串值的大小进行排序。num_i记录了事件e_i在事件空间上产生的负载。

假如这个事件队列为{<e₁，num₁>，<e₂，num₂>，...<e_n，num_n>}，那么可以知道，渠道ch上的总负载LD_ch＝∑num_i，如果需要划分出去的负载为ΔLD，并且

那么前k个事件就是我们需要划分出去的那些，它们在DA＝{DA₁，DA₂，...，DA_m}上的属性约束构成的子空间就是我们要划分出去的空间的大小。而且，我们可以从DA选择出来划分属性：如果前k个事件是需要划分出去的那些，我们找到一个值j，满足1＜＝j＜＝m，并且对于任何i，i＜j，事件e_k与e_k+1在第i个属性上的值相等，在第j个属性上的值不相等。那么选择SDA＝{DA₁，...，DA_j}这个集合作为划分属性。如果划分属性是数值或者RFID编码数据类型，直接根据e_k在这个属性上的数值分割事件渠道；如果划分属性是字符串类型，那么就将e₁，e₂，...，e_k事件在这个属性上的值放入一个集合strSet，然后根据这个集合划分事件渠道，具体操作为，对于strSet中的每一个字符串str，如果事件渠道上在这个属性上的约束(也表示成了一个字符串集合valSet)包含了str，那么就将str从valSet中删除，并且把str加入到分割出的新事件渠道的约束集合valSet’中。

下面我们给出一个分割渠道的例子，DA＝{a，b}，并且a的优先级比b的高，渠道表示为ch＝{a∈[0，100]，b∈[50，80]}，T时间内落在该事件渠道上的事件记录如下：

<e₁＝{a＝10，b＝50}，3>

<e₂＝{a＝15，b＝50}，1>

<e₃＝{a＝20，b＝60}，5>

<e₄＝{a＝20，b＝60}，5>

<e₅＝{a＝40，b＝65}，2>

<e₆＝{a＝50，b＝65}，4>

<e₇＝{a＝70，b＝70}，2>

<e₈＝{a＝90，b＝80}，6>

那么可以得到在T时间内渠道上的负载为LD＝28，如果要划分出的负载为ΔLD＝14。由于

所以，将前四个事件(e₁，e₂，e₃，e₄)作为新的事件空间中的属性，而且在这个例子中，只需要划分属性a的值域就可以了，可以把ch分割成为两个渠道ch₁＝{a∈[0，20]，b∈[50，80]}和ch₂＝{a∈[21，100]，b∈[50，80]}。在这个例子当中，如果<e₅＝{a＝20，b＝65，2>，那么我们除了使用a属性之外，还需要使用b值进行划分；在更加特殊的情况下，如果所有的事件在属性a上的值都相等，那么我们就选择b属性作为唯一的划分属性。

另外还有可能出现的极端情况是，假如到来的事件都是同一个事件，那么无法选择任何属性作为渠道分割的属性，并且无论怎样分割渠道都不可能平衡负载。在这个事件分布非常极端的情况下，可以采取渠道复制的方式，将整个渠道复制到其他的服务器上去，并且标记为该渠道已经被复制和复制的目标服务器；在新的事件到达时，使用一个随机函数随机选择一个服务器作为服务器，通过这种方式进行负载平衡。

下面介绍如何合并事件渠道。

如果已知特征属性结合DA＝{DA₁，DA₂，...，DA_m}，也根据渠道中的事件空的各个特征属性的值进行排序。对于数值和RFID编码类型属性，可以按照区间范围的低值进行排序，对于字符串类型，由于它的表示方式是集合类型，所以可以不管它的顺序，默认类型1的字符串约束优先级高于类型2的。如果在系统运行时，发现服务器上的某个渠道ch在连续n个时间片内的负载值都小于某一个限定的值，那么我们就可以将它与在排序中的邻居渠道进行合并；如果在负载转移过程中，需要从服务器上转移出去多个渠道，也可以将这些需要转移出去的渠道进行合并。

例如两个相邻的事件渠道的事件空间E_s1＝{a∈[10，20]}，E_s2＝{a∈[21，50]}可以合并成一个新的渠道，它的事件空间表示为E_s＝{a∈[10，50]}。对于字符串类型，可以看做是集合的合并。

在本发明中规定事件空间只能划分为连续的区域，所以如果在试图合并两个渠道的事件空间时，如果合并出来的区域并不连续，那么就不能合并这两个渠道，例如如果E_s2＝{a∈[30，50]}，就不能跟E_s1＝{a∈[10，20]}合并。

[12].下面介绍负载调度算法。

负载调度算法的目标是综合f₁～f₄四个因素，得出一个比较优的渠道转移方案。选择出一个较好的渠道转移策略的过程分为两步，第一步根据：

${\mathrm{rank}}_1(\mathrm{\&omega;},g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{\&omega;}\&CenterDot;f_2(g_i,g_j,\mathrm{avg}\left(g_i\right))+(1-\mathrm{\&omega;})\&CenterDot;\mathrm{lev}\left(\frac{{\mathrm{bw}}_{\mathrm{ij}}}{{\mathrm{bw}}_{i\max }}\right)---\left(9\right)$

其中，选择出接收负载的服务器；

第二步根据：

rank₂(ω₂，g_i，g_j，ch_ik)＝α·f₁(g_i，g_j，ch_ik)+β·f₃(g_i，g_j，ch_ik)+γ·f₄(g_i，g_j，ch_ik)    (10)

选择出g_i上应该转移的渠道。

其中ω∈[0，1]和α，β，γ(α，β，γ∈[0，1]，α+β+γ＝1)是权重系数。第一步中并没有考虑f₂使用的渠道，而是使用avg(g_i)作为计算rank₁的一个参数。上述两个式子计算出的值都限制在(0，1)区间，得到的值越大，表明级别越高。第二步通过使用已选择出来的负载接收服务器，选择出g_i上需要转移的事件渠道，这时同时考虑了转移该渠道后对负载平衡的影响、负载转移开销和订阅就近放置三个方面的因素。同时需要注意的是，在第二步的时候可能涉及到渠道的分割。

在第一步计算时，设置了一个优先级队列candidate_list用于选择负载接收服务器，candidate_list的大小就是最多选择的接收服务器的数目。首先根据rank₁式子，计算出在uNodeList中服务器的等级值，根据计算出的等级高低放入candidate_list，然后从candidate_list选择第一个服务器(其级别最高)作为负载接收服务器g_j。然后检查如果将g_i上负载最小的渠道转移至g_j上，gj是否会变成负载过重。如果不会负载过重，那么就进入第二步，检查每一个候选服务器，并根据rank2计算出来的值，选择出需要转移的渠道。如果在第一步时，发现如果将g_i上负载最小的渠道转移至g_j上，如果g_j变成负载过重，那么就必须要进行渠道的分割操作了，另外，如果在第二步计算rank₂时，在计算f₁时，如果找不到任何渠道ch_ik，满足

也需要进行渠道分割操作。

在选择出负载接收服务器和可以转移的渠道之后，负载移出服务器就向负载接收服务器发送负载转移请求，试图与之建立负载转移会话。如果负载接收服务器回复可以接收负载，那么负载转移会话建立，将事件渠道以及与之相关的订阅由负载移出服务器转移到负载接收服务器；如果负载接收服务器不能接收负载，那么负载移出服务器将会从candidate_list中选择出来下一个服务器作为负载接收服务器，并且计算出可以转移出去的渠道，继续向新的负载接收服务器发送负载转移请求。

[13].下面介绍本发明中负载调度的全部过程描述。

1当服务器发现自己负载过重时(并且以一定的概率得出自己可以执行负载调度过程)，首先将自己的状态置为BUSY，表明它正处在负载调度过程中，并且生成本地渠道表的一份副本channel_list。注意在更新本地和全局路由表操作之前，负载移出服务器的本地渠道表和全局路由表都保持不变。

2负载移出服务器开始调用rank₁函数，计算candidate_list。在使用rank₁计算candidate_list时，如果channel_list中只有唯一的一个事件渠道ch，那么必定需要分割ch。如果要分割ch，则将ch从channle_list中删除，然后按照它的负载值分割成几乎相等的两部分的标准分割，生成两个新的渠道ch₁和ch₂，将这个分割信息记录在一个数据结构splitInfos中。splitInfos中的每一项是被分割的渠道的id到渠道分割信息ChSplitInfo的一个映射，每一个ChSplitInfo中记录着被分割的父渠道和由此渠道分割出来的两个子渠道。另外，为了使用方便，同时将ch₁和ch₂放入集合newedChannels中，如果ch已经存在于newedChannels中，那么就把ch从中删除。

3如果candidate_list不为空，那么从candidate_list选择出来第一个服务器作为负载接收服务器(这个服务器的级别最高)，并将其从队列中删除，向其发送负载转移请求消息。如果candidate_list为空，说明没有任何服务器可以作为负载接收服务器，负载平衡过程不能继续下去，那么负载移出服务器将自己的状态由BUSY置为OVERLOADED，终止负载平衡过程，继续等待下一次负载平衡的机会。

4服务器接收到负载转移请求消息后，如果服务器处于UNDERLOADED状态，那么它可以接受负载，就回复消息给负载移出服务器，说明它可以作为负载接收服务器，并将自己的状态设置为BUSY，说明它正参与负载调度过程；如果服务器处于BUSY、OVERLOADED、STABLE等状态时，则说明不能接收更多的负载，那么就回复消息给负载移出服务器，说明它不能作为负载接收服务器。

5负载移出服务器接收到负载请求消息的回复消息后，那么它将：

5.1如果回复消息的服务器不能作为负载接收服务器，那么继续3。

5.2如果回复消息的服务器可以作为负载接收服务器，那么将选定此服务器作为负载接收服务器，并且选择合适的渠道作为负载接收渠道的阶段。

在这个阶段，将调用rank₂函数，在rank₂函数中，将调用f₁和f₃。在f₁的计算时将计算出最佳的负载移出量，即f₁推导过程中给出的

值。根据f₁计算出各个事件渠道的优先级，并按照优先级由高到低进行排列，放入这个一个候选渠道队列ch_candidate_list(注意，在1中如果负载移出服务器上只有1个事件渠道的情况下，已经发生了，如果从ch_candidate_list中的找不出前k个事件渠道，满足其中alpha是允许的误差值，可以取那么就需要对某些渠道进行分割，这时候必然存在那么就分割ch_candidate_list中第k+1个渠道ch，其中分成一部分负载为

分给出来的两个新的渠道ch1和ch2，同样的将ch从channel_list中删除，同时更新splitInfos和newedChannels两个数据结构，记录渠道分割信息。然后再次调用f₁函数，更新ch_candidate_list，直到可以从ch_candidate_list中的找不出前k个事件渠道，满足

否则继续向前面一样分割事件渠道。这样，根据f₁，可以对每一个待选的事件渠道给出对应的优先级值，同样经过f₃，也对每一个待选的事件渠道给出对应的优先级值。经过rank₁计算之后，得到每一个事件渠道的选择优先级别队列localch_candidate_list，从localch_candidate_list中的找出前k个事件渠道，满足

其中

就是beta是允许的误差值，这k个事件渠道就是要转移出去的渠道，记录在transferChannels集合中。

6负载移出服务器向负载接收服务器转移渠道和负载。

6.1负载移出服务器向负载接收服务器发送渠道转移消息。负载移出服务器将选择出来的转移渠道包装在一个渠道转移消息内，发送至负载接收服务器，负载接收服务器在接收到该消息后，将会在其localTable中添加转移过来的渠道，在渠道建立成功之后将会给负载移出服务器发送渠道建立成功的回复。

6.2负载移出服务器在接收到负载接收服务器的渠道建立成功消息之后，将会发送订阅转移消息，把属于转移渠道的那些订阅发送到负载接收服务器上，在发送的消息中，还包含了这些订阅属于哪些渠道的信息。负载接收服务器收到订阅转移消息后，将会在订阅属于的那些渠道中添加这些订阅，在订阅添加成功后将向负载移出服务器发送订阅转移完成消息。

7负载移出服务器更新本地的localTable和routingTable。负载移出服务器在接收到转移订阅已经在负载接收服务器上建立完成之后，它开始更新本地事件渠道表localTable和全局路由表routingTable。首先负载移出服务器将根据选择出来的转移渠道transferChannels以及渠道分割信息记录(splitInfos和newedChannels)计算出5个集合，包括：localAdd，是需要在localTable中添加的渠道(某些本地渠道被分割后仍然放置在本地的那些渠道)；localDel，是需要在localTable中删除的渠道(已经被分割或者已经被转移)；globalAdd是需要从routingTable中添加的渠道(由于渠道分割而新生成的渠道)；globalUpdate，是需要在routingTable中更新的渠道(它们的放置位置发生了变化)；globalDel，是需要在routingTable中删除的渠道(它们已经被分割，不再存在)。使用这5个集合分别更新本地的localTable和routingTable。更新的过程将对两个表加锁，此时不能进行与这两个表相关的操作。

8负载移出服务器在更新完localTable和routingTable后，将那些已经被转移出去的订阅，并且不再说任何本地渠道表中的订阅从本地服务器上清除。

9负载移出服务器将globalAdd、globalUpdate和globalDel集合包装成为全局路由表更新消息，发送给所有的其他服务器，使其能够更新自己的routingTable。

10网络中的其他服务器接收到全局路由表更新的消息之后，更新本地的routingTable。更新的过程会对routingTable加锁，这样新来的消息将不能查routingTable，直到更新完成。注意到不参与负载平衡过程的服务器只是自己本地的routingTable，不需要更新本地的localTable，而负载接收服务器同样也只需要更新本地的routingTable，不需要更新本地渠道表localTable，因为在它处理渠道转移消息的时候本地localTable，将转移的渠道添加了进去。服务器在更新完成之后，向负载移出服务器发送事件空间更新完成消息。

10负载移出服务器接收到所有服务器的全局路由表更新完成消息之后，向负载接收服务器发送负载平衡过程完成消息，通知其负载平衡过程结束。负载移出服务器将本地负载状态由BUSY设置为STABLE，结束负载平衡过程。

11负载接收服务器接收到负载完成消息后，将自己的负载状态由BUSY设置为STABLE。

[14]下面介绍本发明的全部消息类型及其处理。本发明有如下16种类型的消息：

1、RoutingTableInit消息，路由表初始化消息。在系统初始化时，由初始化服务器向网络中的其他所有服务器发送，用于初始化接收该消息的服务器的全局路由表routingTable和本地渠道表localTable。消息格式为：(RoutingTableInit：routingTable)，其中routingTable为全局路由表，包括了全部的渠道到服务器的放置位置映射信息。

2、ReplyRoutingTableInit消息，确认全局路由表已经在服务器中创建完毕。这个消息是服务器对ReplyRoutingTableInit消息的回复。消息格式为：(ReplyRoutingTableInit：)，由于这个消息只是一个确认信息，在服务器接收到RoutingTableInit消息并建立好全局路由表和本地渠道表后，通知初始化服务器建立完成，所以消息体中不必包含其他内容。

3、Subscription消息，订阅消息。表示一个订阅请求，消息格式为(Subscription：subExp，subscriber，dispatchSign，chID)，其中subExp是订阅的字符串形式，subscriber是订阅者的标识，dispatchSign是订阅处理的标记，可取SUBSCRIBE_NEW或SUBSCRIBE_DISPATCHED，chID是渠道标记。如果订阅消息是从订阅者直接发送过来的，那么dispatchSign的取值为SUBSCRIBE_NEW，chID标记无意义，接入服务器在接收到这样的消息后，将查询全局路由表routingTable，进而确定出订阅应该由哪些渠道处理，如果渠道在本地，则在本地处理该订阅，如果需要转发到在其他服务器上的渠道进行处理，则生成新的订阅消息，并将dispatchSign设置为SUBSCRIBE_DISPATCHED，将chID设置为该订阅属于的那个渠道的id；如果订阅消息是从网络中的其它服务器传来的，则该订阅消息必定是dispatchSign为SUBSCRIBE_DISPATCHED，在chID中已经包含了该订阅属于的本地渠道，则直接将该订阅交由本地渠道进行处理。特殊的情况是，如果渠道所在的服务器正在处于负载平衡过程中，并且是负载移出服务器，那么该订阅消息将不会被渠道处理，将生成一个重传消息Reforward，具体操作将在下面Reforward消息的介绍中给出。

4、UnSubscription消息，取消订阅消息。表示取消订阅请求，消息格式为(UnSubscription：unsubExp，unsubscriber，dispatchSign，chID)，其中unsubExp是订阅的字符串形式，unsubscriber是订阅者的标识，dispatchSign是订阅处理的标记，可取UNSUBSCRIBE_NEW或UNSUBSCRIBE_DISPATCHED，chID是渠道标记。如果取消订阅消息是从订阅者直接发送过来的，那么dispatchSign的取值为UNSUBSCRIBE_NEW，chID标记无意义，接入服务器在接收到这样的消息后，将查询全局路由表routingTable，进而确定出该取消订阅消息应该由哪些渠道处理，如果渠道在本地，则在本地处理该订阅，如果需要转发到在其他服务器上的渠道进行处理，则生成新的取消订阅消息，并将dispatchSign设置为UNSUBSCRIBE_DISPATCHED，将chID设置为该订阅属于的那个渠道的id；如果取消订阅消息是从网络中的其它服务器传来的，则该取消订阅消息必定是dispatchSign为UNSUBSCRIBE_DISPATCHED，在chID中已经包含了该订阅属于的本地渠道，则直接将该取消订阅消息交由本地渠道进行处理。特殊的情况是，如果渠道所在的服务器正在处于负载平衡过程中，并且是负载移出服务器，那么该取消订阅消息将不会被渠道处理，将生成一个重传消息Reforward，具体操作将在下面Reforward消息的介绍中给出。

5、Event消息，事件消息。表示事件消息的到达，消息格式为(Event：eventExp，dispatchSign，chID)，其中eventExp是订阅的字符串形式，dispatchSign是事件处理的标记，可取EVENT_NEW或EVENT_DISPATCHED，chID是渠道标记。如果取事件消息是从发布者直接发送过来的，那么dispatchSign的取值为EVENT_NEW，chID标记无意义，接入服务器在接收到这样的消息后，将查询全局路由表routingTable，进而确定出该事件应该由哪个渠道处理，如果渠道在本地，则在本地处理该事件，如果需要转发到在其他服务器上的渠道进行处理，则生成新的事件消息，并将dispatchSign设置为EVENT_DISPATCHED，将chID设置为该事件属于的那个渠道的id；如果事件消息是从网络中的其它服务器传来的，则该订阅消息必定是dispatchSign为EVENT_DISPATCHED，在chID中已经包含了该事件属于的本地渠道，则直接将该事件交由本地渠道进行处理。特殊的情况是，如果渠道所在的服务器正在处于负载平衡过程中，并且是负载移出服务器，那么该事件消息将不会被渠道处理，将生成一个重传消息Reforward，具体操作将在下面Reforward消息的介绍中给出。

6、LIEM(Load Information Exchange Message)消息，负载信息交换消息。各个服务器每隔一段时间向所有其他服务器通过LIEM发送自己的信息。消息格式为：(LIEM：brokerID，brokerStatus，brokerD，brokerDC)，其中，brokerID为发送服务器的标识；brokerStatus为当前发送服务器所处状态，取值为UNDERLOADED、STABLE、OVERLOADED或者BUSY；brokerD为服务器的负载值，brokerDC为服务器的负载水平值。

7、RequestLoadBanlance消息，请求负载平衡消息。由负载移出服务器发出，询问可作为负载接收服务器的候选节点是否可以接收负载，执行负载平衡过程。这个消息是当服务器负载过重且监控机制允许其发起负载平衡过程时发送，对方节点是在rank₁函数中计算得到。格式为：(RequestLoadBanlance：brokerD，brokerDC)，其中brokerD是负载移出服务器的负载，brokerDC是负载移出服务器的负载水平，用于接收服务器确认自己是否可以参与负载平衡过程。

8、ReplyRequestLoadBanlance消息，对RequestLoadBanlance请求的回复消息。消息格式为：(ReplyRequestLoadBanlance：status)，其中status为当前节点所处状态，如果status的取值为UNDERLOADED，则说明该服务器可以作为负载接收服务器，如果负载接收服务器接收到了这样的消息后，则可以与负载接收服务器之间建立负载平衡会话，进行进一步的操作；否则，则说明该服务器本身正处在其他服务器的负载平衡过程或者负载过重，不适合接收新的负载平衡请求，负载移出服务器接收到这样的回复消息后，将向下一个候选服务器发送RequestLoadBanlance消息。

9、ChannelTransfer消息，渠道转移消息。由负载移出服务器向负载接收服务器发送，表示服务器间进行渠道转移。格式为：(ChannelTransfer：channels)，其中channels是转移渠道的信息集合，每个渠道信息包括渠道的标识和渠道的表示。

10、RelplyChannelTransfer消息，渠道转移消息的回复消息。由负载接收服务器在接收到ChannelTransfer消息并在本地建立渠道表localTable中建立完新的渠道后向负载移出服务器发送。消息格式为：(RelplyChannelTransfer：replySign，channelIDs)，其中replySign为当前节点渠道建立是否成功的表示，其值为REPLY_SUCCESS(渠道建立成功)或REPLY_FAIL(渠道建立失败)两种形式；channelIDs为负载接收服务器在本地建立的若干渠道的标识信息集合。

11、SubscriptionMove消息，转移订阅消息。这个消息是负载移出服务器收到RelplyChannelTransfer消息，确认了相应渠道已经在负载接收服务器建立成功后，将渠道对应的订阅信息进行转移时发送的。消息格式为：(SubscriptionMove：subscriptionType，chSubSet)，其中subscriptionType为订阅基本格式信息，标识转移的是原子订阅还是复合订阅；chSubSet包含了相应渠道的标识该渠道对应的所有订阅。

12、ReplySubscriptionMove消息，SubscriptionMove消息的回复消息。由负载接收服务器向负载移出服务器发送，用于确认发送过来的订阅在本地已经创建完毕。消息格式为：(ReplySubscriptionMove：)，由于这个消息只是一个确认信息，所以不必包含其他内容。负载移出服务器在接收到负载接收服务器将订阅建立成功的消息之后，将更新本地的渠道表localTable和存放在本地的全局路由表routingTable。

13、UpdateRoutingTable消息，更新全局路由表消息。由负载移出服务器在收到ReplySubMove消息，确认需要转移出的订阅已经在负载接收服务器创建成功后，并更新完本地的localTable和routingTable后，向网络中的所有其他服务器发送的全局路由表更新请求。消息格式为：(UpdateRoutingTable：deleteChs，updateChs)，其中deleteChs为应该在接收方服务器routingTable中删除的渠道信息；updateChs为经过转移过程后应该在路由表中更新的渠道信息，包括新建立的渠道(直接添加)和重定向的渠道(渠道的放置位置发生了变化，更新放置的服务器)。

14、ReplyUpdateGlobal消息，确认全局路由表已经更新的消息，接收到UpdateRoutingTable的服务器向负载移出服务器发送，表明服务器已经更新完全局路由表。消息格式为：(ReplyUpdateGlobal：)，由于这个消息只是一个确认信息，所以不必包含其他内容。

15、CompleteLoadBalance消息，负载平衡过程结束的消息。负载移出服务器接收到所有其他节点路由表更新的确认后，向负载接收服务器发送，接负载接收服务器收到后自行将服务器状态转换为STABLE。消息格式为：(CompleteLoadBalance：)，由于这个消息只是一个确认信息，所以不必包含其他内容。

16、Reforward消息，负载平衡过程中消息重传请求。这个消息是保证负载平衡过程正确性的关键。负载移出服务器在负载平衡过程中，如果接收到订阅、取消订阅或事件消息应该被其本地渠道处理，并且属于需要转移的事件渠道，那么这些消息也可能需要被负载接收服务器处理，以保证在负载接收服务器上不丢失任何信息，这时候负负载移出服务器需要根据其所处的负载平衡过程阶段进行分别处理。在负载平衡过程中，标识出三个重要的时间点，首先是负载平衡开始时刻记为<1>时刻，其次是渠道转移完成时刻(这时需要转移的事件渠道已经在负载接收服务器建立)记为<2>时刻，最后是渠道相关的订阅转移完成的时刻(这时订阅已经在负载接收服务器建立，并且负载移出服务器的本地渠道表和全局路由表已经更新完成)记为<3>时刻。<1>时刻和<3>时刻之间是负载平衡过程的主要时间阶段，在这段时间内，负载移出服务器对接收到的属于转移渠道的订阅、取消订阅和事件消息需要特殊考虑：

在<1>时刻到<2>时刻之间，负载移出服务器仍然可以正常的处理订阅、取消订阅和事件消息，因为在负载移出服务器上的渠道并没有受到负载平衡过程的影响。但是此时由于转移渠道还没有在负载接收服务器上建立，所以属于负载接收服务器的这些渠道的暂时不能进行订阅添加、取消操作，需要对新来的与转移渠道相关的订阅、取消订阅消息在负载移出服务器上记录，在<2>时刻将这些消息包装成为Reforward消息重传给负载接收服务器。这个时候由于本地订阅未发生转移，事件消息仍然可以到来可以类似负载平衡过程前在本地进行进行正确处理，而且不需要保存并重传至负载接收服务器。

在<2>时刻和<3>时刻之间，由于需要转移的渠道已经在对方节点建立，并且负载移出服务器在<2>时刻接收到渠道建立成功消息之后就立刻发送订阅转移消息，将与转移渠道相关的订阅发送给负载接收服务器，并且如果有在<1>与<2>时刻之间需要重传的订阅、取消订阅消息，那么在发送完转移订阅消息之后，就将这些消息组织成为Reforward消息进行重传。之后，与属于转移渠道的订阅、取消订阅、事件消息可以直接重传到相应节点上进行处理，并且由于消息是按照到达序列顺序发送的，亦可以保证消息的正确处理顺序。

Reforward消息格式为：(Reforward：chID，messages)，其中chID表示该订阅、取消订阅或者事件消息属于的渠道的标识，messages可能为一条消息也可能为多条消息，其中每条消息格式为：(sign，message_prefix)，其中sign为消息类型标志，取值范围为SUBSCRIBE_MESSAGE(订阅消息)，UNSUBSCRIBE_MESSAGE(取消订阅消息)，EVENT_MESSAGE(事件消息)；message_prefix为消息体，如果为订阅消息或是取消订阅消息，那么这其中还包含订阅者的标识。

Claims (6)

1.一种发布/订阅系统的动态负载平衡方法，其特征在于，该系统包括由多个服务器组成的对等覆盖网络，网络中的各个服务器均作为接入服务器接收订阅和事件信息，并通过全局路由表确定该信息所属的事件渠道后将其转发至该事件渠道进行处理；所述动态负载平衡方法包括：负载过重的服务器从本地选择转移负载并在其他服务器中选择负载接收服务器，将该转移负载发送至该负载接收服务器。

2.如权利要求1所述的发布/订阅系统的动态负载平衡方法，其特征在于，服务器保存本地渠道表和全局路由表，本地渠道表记录服务器本地的事件渠道全局路由表记录事件渠道在服务器上的放置位置。

3.如权利要求1所述的发布/订阅系统的动态负载平衡方法，其特征在于，负载接收服务器收到转移负载后，若该转移负载的订阅或事件消息属于本地渠道，则直接将该转移负载交给该本地渠道处理。

4.如权利要求1所述的发布/订阅系统的动态负载平衡方法，其特征在于，该系统通过下列方法触发所述动态负载平衡：

a)系统初始化时，服务器默认为低负载状态；

b)服务器之间按设定的周期共享各自的负载信息；

c)服务器收到其他服务器的负载信息后计算平均负载并确定自身是否负载过重；

d)负载过重的服务器按设定的概率触发所述动态负载平衡。

5.如权利要求1所述的发布/订阅系统的动态负载平衡方法，其特征在于，负载过重的服务器通过下列方法在其他服务器中选择负载接收服务器：

服务器根据rank₁式对其他服务器中负载过轻的服务器排序，得到序列candidate_list，按照candidate_list中的顺序选择服务器作为负载接收服务器：

${\mathrm{rank}}_1(\mathrm{\&omega;},g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{\&omega;}\&CenterDot;f_2(g_i,g_j,\mathrm{avg}\left(g_i\right))+(1-\mathrm{\&omega;})\&CenterDot;\mathrm{lev}\left(\frac{{\mathrm{bw}}_{\mathrm{ij}}}{{\mathrm{bw}}_{i\max }}\right),$ $\mathrm{avg}\left(g_i\right)=\frac{\underset{k=1}{\overset{m_i}{\mathrm{\&Sigma;}}}{d}_{\mathrm{ik}}}{m_i},$

其中ω∈[0，1]，是权重系数；g_i表示当前服务器，g_j表示其他服务器之一，ch_ik表示g_i中的第k个渠道；m_i表示g_i上的事件渠道数；bw_ij表示g_i与g_j之间的网络带宽，bw_imax表示g_i到所有负载较低服务器的带宽中的最大值；

f₂(g_i，g_j，ch_ik)＝1-|lev(rank_o)-lev(rank_u)|，

其中 ${\mathrm{rank}}_o=({\mathrm{dc}}_i-\frac{d_{\mathrm{ik}}}{c_i})/\mathrm{Max}({\mathrm{dc}}_o-\frac{d_{\mathrm{ik}}}{c_o}),$ ${\mathrm{rank}}_u=\mathrm{Min}({\mathrm{dc}}_u+\frac{d_{\mathrm{ik}}}{c_u})/({\mathrm{dc}}_j+\frac{d_{\mathrm{ik}}}{c_j});$

c_i和c_j分别表示g_i和g_j的处理能力，dc_i和dc_j分别表示g_i和g_j的负载水平，d_ik是ch_ik的负载，Max(dc_o-d_ik/c_o)表示负载较重的服务器中(dc_i-d_ik/c_i)值最大的服务器，Min(dc_u-d_ik/c_u)表示负载较轻的服务器中(dc_j+d_ik/c_j)值最小的服务器；

lev表示分级函数，

x∈[0，1]，

表示取整操作符，L表示层次数目。

6.如权利要求1所述的发布/订阅系统的动态负载平衡方法，其特征在于，负载过重的服务器通过下列方法从本地选择转移负载：

根据rank₂式对本地渠道排序，按照得到的序列选择渠道作为转移渠道：

rank₂(ω₂，g_i，g_j，ch_ik)＝α·f₁(g_i，g_j，ch_ik)+β·f₃(g_i，g_j，ch_ik)+γ·f₄(g_i，g_j，ch_ik)，

其中α，β，γ是权重系数，α、β、γ∈[0，1]，α+β+γ＝1；g_i表示当前服务器，g_j表示其他服务器之一，ch_ik表示g_i中的第k个渠道；c_i和c_j分别表示g_i和g_j的处理能力，d_ik是ch_ik的负载，m_i表示g_i上的事件渠道数；

其中，

d_i和d_j分别表示g_i和g_j的负载水平，

表示网络中服务器负载水平的平均值，

f₂(g_i，g_j，ch_ik)＝1-|lev(rank_o)-lev(rank_u)|，

其中，

dc_i和dc_j分别表示g_i和g_j的负载水平，Max(dc_o-d_ik/c_o)表示负载较重的服务器中(dc_i-d_ik/c_i)值最大的服务器，Min(dc_u-d_ik/c_u)表示负载较轻的服务器中(dc_j+d_ik/c_j)值最小的服务器，

$f_3(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\min \_\mathrm{mig}\_\cos t}{\mathrm{mig}\_\cos t\{{\mathrm{ch}}_{\mathrm{ik}}\&RightArrow;g_j\}}\right),$

其中，min_mig_cost表示g_i的各个渠道中最小的负载转移开销，mig_cost{ch_ik→g_j}表示ch_ik到g_j的转移开销；

$f_4(g_i,g_j,{\mathrm{ch}}_{\mathrm{ik}})=\mathrm{lev}\left(\frac{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{ikj}}}{\max \{\mathrm{acc}\_{\mathrm{rate}}_{\mathrm{iqj}},{\mathrm{ch}}_{\mathrm{iq}}\mathrm{on}{g}_i\}}\right),$

lev表示分级函数，

x∈[0，1]，

表示取整操作符，L表示层次数目。

Images