CN101326493B - 用于多处理器服务器中的负载分配的方法和装置 - Google Patents

Abstract

一种用于在具有多个处理器(304、306等)的应用服务器(300)中处理对多媒体服务的引入请求的方法和装置。从用户(A)接收要求处理用户特定数据的服务请求(R)。从所接收的服务请求中提取用户的身份或其它相容的用户有关参数。然后，应用使用所提取的身份或其它用户有关参数作为输入的调度算法，来选择关联该用户并且为该用户本地存储用户特定数据(306m)的处理器(306)。然后，最终将该服务请求传送给所选择的处理器以便通过处理所述用户特定数据来处理该服务请求。

Description

用于多处理器服务器中的负载分配的方法和装置

技术领域

本发明一般涉及用于在多处理器服务器中的处理器之间分配负载的方法和装置。特别是，本发明与在处理服务请求时降低延迟和复杂度有关。

背景技术

现今，可利用能够使用IP(因特网协议)进行基于分组的多媒体通信的各种通信设备，包括固定或移动的计算机和电话。多媒体服务通常需要以不同的格式和结合(包括音频、视频、图象、文本、文档、动画等)表示媒体的编码数据的基于IP(因特网协议)的传输。

称作“IP多媒体子系统”(IMS)的网络体系结构已经由第三代合作伙伴计划(3GPP)发展为用于处理分组域中的多媒体服务和通信会话的开放的标准。IMS是实现基于IP传输的服务的平台，或多或少独立于所使用的接入技术，并且基本上不限于任何特定的服务。因此，IMS网络用于控制多媒体会话，但不用于通过接入网络和任何中间传输网络(包括因特网)路由的有效载荷数据的实际传输。

图1是通过IMS服务网络的方式提供多媒体服务时的基本方案的示范性图解说明。移动终端A连接到无线接入网络100，并且在包括一个或多个多媒体服务的通信会话S中与连接到另一个接入网络102的固定计算机B进行媒体通信。同样也可以存在链接接入网络100和102的中间骨干网络(未示出)。

IMS网络104连接到无线接入网络100并且处理对于终端A的会话，其中网络100、104通常由相同的运营商拥有。在这个例子中，相应的IMS网络106代表终端B处理会话，并且两个IMS网络104和106可以由不同的运营商控制。作为备选的方案，两个通信终端当然也可以连接到相同的接入网络和/或可以属于相同的IMS网络。终端A也可以改为与服务器通信，例如，用来从内容提供商下载一些媒体或信息。此外，如果终端正在被访问的接入网络内漫游，那么多媒体服务由终端的“归属”IMS网络(即在其中该终端作为用户而注册的网络)来处理。

显示在图1中的会话由各个IMS网络中的特定节点管理，在网络104中通常表示为“会话管理节点”108。这些节点通常包括S-CSCF(服务呼叫会话控制功能)，I-CSCF(问询呼叫会话控制功能)和P-CSCF(代理呼叫会话控制功能)。各个IMS网络104、106还包括(或连接到)用于实现不同的多媒体服务的应用服务器110。此外，主数据库单元HSS(归属用户服务器)112还存储用户和认证数据以及服务信息。IMS网络106基本类似于网络104。当然，IMS网络104、106包含许多其它的节点和功能(为了简化的目的，这里没有示出)，这些节点和功能与本发明没有特殊关联。

称作“SIP”(根据标准IETF RFC 3261：会话初始化协议)的规范用于处理IMS网络中的会话。SIP是用于信令的应用层协议，可以用于建立多媒体会话以及通常用于处理多媒体会话。因而SIP标准可以由IMS网络和终端用来建立和控制IP多媒体通信。

这样，显示在图1中的应用服务器110用于向用户提供特定的多媒体服务，并且可以由IMS网络104的运营商或外部“第三方”服务提供商拥有或管理。许多服务，例如所谓的“存在服务(presence service)”，可以包括不同的组和联系人列表特征并且可以提供关于其它用户的信息，例如，关于他们当前的位置或状态的信息。任何这样的信息由各自的应用服务器110保存，这与预订的应用服务器的服务的用户有关。用户还可以根据他/她的配置文件以及当前的位置和状态来接收消息和数据。用户配置文件可以是个人的并且由优先选择、兴趣和爱好以及更多的临时性因素(例如用户的可用性以及当前心情)来确定。

应当很容易地理解这样的服务要求在应用服务器中处理相当大的数量的可检索的用户特定数据，并且在本说明中，术语“用户特定数据”用于表示与预订由应用服务器提供的服务的用户以某种方式关联的任何信息。WO 2005/088949描述了如何获得用户特定数据以及用户特定数据如何提供给用户。因此，在应用服务器中，需要频繁地检索和更新这样的用户特定数据，例如，以响应服务请求。因此，希望服务提供商能够有效地利用和控制包括在它们的应用服务器中的硬件和软件工具的资源。

此外，可能有必要不时地随着来自服务请求改变的需求来重新配置应用服务器。可以添加或移除用户以及可以引入、修改或删除服务。反映在引入请求的数量上的特定服务的普及性，同样可以随时间改变。从而，在应用服务器中同样要求可扩缩性。

为了应付服务请求和大量的信息的需求，应用服务器通常包括多个具有基本相似的性能和功能性的处理器。于是，所谓的负载均衡器通过根据某些调度算法对各个请求选择处理器，用来在处理器中分配引入请求的负载。为了有效地利用可用的计算和存储资源，应付热点和避免瓶颈，这样做是必要的。然而，还有可能从一个或多个数据库中发现和检索用户特定数据，这通常要求使用指针或参考。

WO 2003/069474披露了用于在服务器系统中的多个服务器之间分配来自用户的引入服务请求的负载的解决方案，服务器系统中的多个服务器分为适合于处理任务的主服务器和适合于存储任务的次服务器。在该上下文中，处理任务基本上是用户独立的，而存储任务基本上是用户特定的。当由服务器系统中的接入节点接收服务请求时，通过使用第一调度算法(例如，轮询算法)随机地分配任何主服务器。然后，在处理请求之后，所选择的主服务器通过使用第二调度算法(例如，使用用户身份作为输入的散列算法)分配用于存储任务的特定的次服务器。以这样的方式，处理负载将在主服务器之间均匀分配，用户特定存储负载将仅被指引到保存有与请求用户有关的信息的服务器。

然而，具有高性能的应用服务器通常包括多个相同的处理器(有时被称为“机群”)，只要是在处理服务请求时，需要各个处理器从数据存储中检索用户特定信息。为了避免所存储的用户数据的复制，大的公共数据库通常由所有的处理器使用。

图2说明了在IMS网络中提供一个或多个特定的多媒体服务的SIP应用服务器200的常规体系结构。应用服务器200包括负载均衡器202，多个相互类似的处理器204，以及公共用户数据库206。数据库206为所有用户或对于由应用服务器200提供的多媒体服务注册的用户存储有关的用户特定数据。这样，为用户A存储的信息在某方面与用户A有关，关于用户他/她自己或包括在对那个用户A定义的组中的其它用户。

最初在负载均衡器202中接收来自用户的引入服务请求，这应用了一些适当的调度算法以便或多或少随机地选择处理器204用来处理请求。在图中，负载均衡器202中的调度算法恰巧将第一所示请求R1指引到处理器1并且将第二所示请求R2指引到处理器3。例如，请求R1和R2可以涉及相同的订户/用户。因为各个请求R1、R2通常要求一些用户有关信息，所以处理器1和2必须从公共数据库206中检索这样的相关信息，如双箭头所示。以这种方式，处理器204的任何一个可以通过访问数据库206来处理来自所有注册的订户/用户的请求。

然而，由于所需的从数据库中检索信息的步骤，具有大的公共数据库的解决方案增加了对请求的响应时间。而且，如果有必要重传(当UDP(用户数据报协议)用于传输SIP消息时，可能会有这种情况)，则重传的消息很有可能被指引到与第一次选出的不同的处理器。因此，同样有必要将用户当前的事务和/或对话信息存储在公共数据库中，这自然会在那个数据库上产生更多的负载。

发明内容

本发明的目的是解决上文列出的问题，并且对引入的服务请求提供处理负载的有效的分配。这个目的和其它目的能够通过提供根据所附的独立权利要求的方法和装置来获得。

根据一个方面，提供了一种在具有多个处理器的应用服务器中处理对多媒体服务的引入请求的方法。首先在第一处理器中从用户接收服务请求，所述服务请求要求用户特定数据的处理。然后从接收到的服务请求中提取用户的身份或其它相容的用户有关参数。其次，使用提取的身份或其它用户有关参数作为输入来应用调度算法，以便选择关联该用户并且为该用户本地存储用户特定数据的第二处理器。服务请求最终传送给所选的第二处理器以便通过处理所述用户特定数据来对其进行处理。

优选地，在第一处理器的无状态(stateless)前端部分中接收服务请求，并且将该服务请求传送给第二处理器的有状态(stateful)后端部分。调度算法可以应用于设置在第一处理器的前端部分和第一处理器的有状态后端部分之间的分配器。分配器可以是设置在应用服务器中的处理器的无状态前端部分和有状态后端部分之间的中央分配器，或者是仅设置在第一处理器的前端和后端部分之间的本地分配器。

当信令协议用来处理请求时，无状态前端部分可以在所述信令协议的网络层运行，而有状态后端部分可以在信令协议的更高层运行。

用户特定数据的处理可以包括对这样的数据的任何的检索、修改和/或存储行为。

应用服务器可以连接到IMS网络，并且SIP信令可以用于接收的服务请求。然后，分配器可以相对于SIP堆栈设置在无状态网络层和有状态更高层(包括应用层)之间。当应用服务器连接到IMS网络时，HTTP信令同样可以用于所接收的服务请求。

根据另一个方面，在具有多个处理器的应用服务器的第一处理器中提供了一种装置，用来处理对多媒体服务的引入请求。该装置包括用于接收来自用户的服务请求的部件，要求处理用户特定数据的部件，以及用来从接收到的服务请求中提取用户A的身份或其它相容的用户有关参数的部件。该装置还包括使用所提取的身份或其它用户有关参数作为输入来应用调度算法的部件，用来选择关联所述用户并且为那个用户本地存储用户特定数据的第二处理器的部件，以及用来将服务请求传送给所选择的第二处理器以便通过处理所述用户特定数据来处理服务请求的部件。

接收、提取和传送部件优选地在适合于接收服务请求并将服务请求传送给所选择的第二处理器的有状态后端部分的第一处理器的无状态前端部分实现。应用部件可以在分配器中实现，分配器设置在第一处理器的所述前端部分和第一处理器的有状态后端部分之间。分配器可以是中央分配器，设置在应用服务器中的所述多个处理器的无状态前端部分和有状态后端部分之间；或本地分配器，仅设置在第一处理器的所述前端和后端部分之间。当信令协议用来处理所述请求时，所述无状态前端部分可以在所述协议的网络层运行，而所述有状态后端部分可以在协议的更高层运行。

用户特定数据的处理可以包括为对这样的数据的任何检索、修改和/或存储行为。

应用服务器可以连接到IMS网络，并且SIP信令可以用于接收的服务请求。然后，分配器相对于SIP堆栈设置在无状态网络层和有状态更高的层(包括应用层)之间。当应用服务器连接到IMS网络时，HTTP信令同样可以用于接收的服务请求。

根据另一个方面，提供了具有多个处理器的应用服务器，用来处理对多媒体服务的引入请求。各个处理器包括：适合于接收服务请求的无状态前端部分，适合于处理服务请求的有状态后端部分，以及用于本地存储用户特定数据的存储单元。分配器还设置在前端和后端部分之间，适合于对来自用户的服务请求应用调度算法，要求使用身份或其它的用户有关参数作为输入来处理用户特定数据，用来选择关联所述用户以及对那个用户本地存储用户特定数据的另一个处理器。

分配器可以是设置在应用服务器中处理器的无状态前端部分和有状态后端部分之间的中央分配器，或仅设置在各个单个处理器的前端和后端部分之间的本地分配器。

本发明的更多可能的特征和优势将在下文的详细描述中作解释。

附图说明

现在将更详细地并参照附图来描述本发明，其中：

图1是包括IMS网络的通信方案的示意性纵览，其中可以使用本发明。

图2是根据现有技术的应用服务器的框图。

图3是根据一个实施例的应用服务器的框图。

图4是根据另一个实施例的应用服务器的框图。

图5是根据再一个实施例的应用服务器的框图。

图6是根据图5的实施例的应用服务器的备选框图。

图7是根据再一个实施例的用来处理服务请求的过程的流程图。

具体实施方式

简单地说，本发明包括本地存储用户特定数据的一组处理器，以及用于将关于特定用户的服务请求指引到为那个用户存储数据的处理器的机构。图3说明了根据一个实施例的应用服务器300和用于处理来自用户A的服务请求的过程。应用服务300可以连接到使用SIP信令的IMS网络，例如，如图1中所示的。

应用服务器300包括：充当用于引入服务请求的接入节点的负载均衡器302以及其中仅示出两个处理器304、306分别具有身份x和y的多个相似的处理器。各个处理器304、306等包括用于本地存储用户特定数据的存储单元或存储器。这样，存储单元304m位于处理器x中，存储单元306m位于处理器y中。

处理器中的各个本地存储单元(例如，高速缓存型存储器)可以在容量上明显小于容纳所有用户数据的大的公共数据库，因为在各个本地存储单元中仅存储用户特定数据总量的一小部分。在这个例子中，存储单元304m为与处理器x相关联的用户的第一子集存储数据，以及存储单元306m为与处理器y相关联的用户的第二子集存储数据，包括其中示出的用户A。从而，相同的处理器将为特定的用户本地处理所有的用户特定数据。

在第一步骤3:1，从负载均衡器302中接收来自用户A的服务请求。在下一个步骤3:2，负载均衡器302应用第一调度算法，例如，轮询算法，用来或多或少随机地选择任何处理器来接收和处理服务请求。在这个例子中，负载均衡器302恰巧选择处理器x，304，在步骤3:4中将请求传送到那个处理器。应当注意，负载均衡器302可按与图2的常规的负载均衡器202相同的方式很好地运行。

如果接收处理器x然后检测到所接收的请求要求关于用户A的用户特定数据的检索、更新和/或存储，那么就首先确定所选择的处理器x是否实际关联用户A。很有可能，如果应用服务器300包括多于两个或三个的处理器，则不会发生这种情况。因此，在下一个步骤3:5，基于用户A的身份或能够从请求中提取的其它相容的参数，处理器x应用第二调度算法来选择一个与用户A相关联的处理器。第二调度算法适合于始终对各个特定的用户提供相同的结果。例如，散列型算法可使用用户A的身份或其它的用户有关参数作为输入。

在这个例子中，处理器x选择与用户A相关联的处理器y306，并且在步骤3:6中该请求被进一步传送到那里。作为对用户A的正确的处理器，现在可以通过为用户A存储在存储单元306m中的用户特定数据来处理该请求，并且在最后的步骤3:7，根据请求和/或服务的性质任意地提供某类响应或其它行为。

以这样的方式，不要求用户特定数据的请求被均匀地分配在处理器之间，而实际上要求用户特定数据的请求转发给与请求用户相关联的处理器。应当注意，当前的解决方案不排除公共数据库306的附加使用，如图所示，例如，用来保存某些更持久和/或更重要类型的用户特定数据。例如，一些种类的数据可以复制到本地存储部件和公共数据库中，使得这些数据长期来讲很容易地检索并安全地存储。在该上下文中，访问本地存储器306m要比访问公共数据库快得多。因此与常规的解决方案相比，本解决方案提供了更大的灵活性，更短的延迟并且降低了在公共数据库中对存储容量的需求(如果确实需要)。

图4更详细地说明了包括多个处理器的基于SIP的应用服务器400(其中仅显示了第一处理器400x和第二处理器400y)，但是本发明通常不限于SIP的使用。下文中，根据另一个实施例，将描述引入服务请求R如何能从处理器400x转发到处理器400y。假定使用第一调度算法的负载均衡器302最初恰巧将服务请求R从请求用户指引到处理器400x。这样，负载均衡器302基本上具有与上述图3描述的相同的功能。

在这个实施例中，各个处理器逻辑上分成SIP前端部分402x、y和SIP后端部分406x、y，并且具有位于前端和后端部分之间的分配器功能模块404x、y。处理器400x和400y还分别包括具有有限尺寸的本地存储单元408x和408y。

SIP前端部分402x、y和SIP后端部分406x、y根据SIP协议堆栈中不同的层来运行，使得前端部分402x、y在协议中的网络层中是“无状态”运行的，而后端部分406x、y在协议中的更高层(通常包括事务层、解析层、会话层和上下文层)中是“有状态”运行的。这个技术意味着无状态前端部分402x、y的运行不受用户特定数据的改变影响，同时有状态后端部分406x、y的运行可能也是如此。因此，SIP后端部分主要处理SIP事务和对话。

SIP堆栈的顶部是服务器400中执行一个或多个应用程序的实际的应用层(未示出)，可以认为它属于后端部分406x、y。在应用层和其余的SIP堆栈之间是应用层接口API，例如，SIP Servlet API或一些基于JAVA的通信接口。SIP结构是技术中公知的，而没有必要在本发明中作进一步描述以便理解本发明。对于除了SIP外的协议(例如HTTP)，处理器同样有可能类似地分成无状态前端部分和有状态后端部分。

通过使用以用户身份或其它相容的用户有关参数作为输入的第二调度算法，在各个处理器中的分配器功能模块404x、y适合于将请求重定向到与请求用户相关联的正确的处理器。因此，当显示的引入请求R到达处理器400x中的SIP前端部分402x时，检测到该请求要求用户特定数据并且分配器404x应用第二调度算法来为请求用户找到正确的处理器，即，在这个例子中是处理器400y。请求返回到前端部分402x，然后前端部分402x将请求转发到根据第二调度算法选择的处理器400y。

从而，请求R被传送给处理器400y，并且进入到在网络层运行的SIP前端部分402y，然后SIP前端部分402y最终将该请求传送给SIP后端部分406y以便通过存储单元408y中的用户特定数据根据更高的协议层来进一步处理。另一方面，如果在第一处理器400x中检测到请求R不要求用户特定数据，则该请求将保留在处理器400x中并且被直接传送到后端部分406x用于处理，而无需应用第二调度算法。

图5说明了根据另一个实施例基于SIP的应用服务器500的备选配置。与先前的实施例一样，服务器500包括多个处理器，其中仅示出了第一处理器500x和第二处理器500y，使用第一调度算法的负载均衡器302恰巧将服务请求R从请求用户指引到处理器500x。与先前图4的实施例一样，处理器包括在SIP协议堆栈中的不同的层运行的无状态SIP前端部分502x、y和有状态后端部分506x、y，以及本地存储单元508x、y。然而在这个实施例中，中央分配器504位于服务器中的多个前端部分和后端部分(包括部分502x、y和504x、y)之间。

中央分配器504适合于将请求从任何处理器重定向到与请求用户相关联的正确的处理器。这样，当引入请求R到达处理器500x中的SIP前端部分502x时，检测该请求要求用户特定数据。所以请求被转发到分配器504，在分配器504中应用第二调度算法来为请求用户找到正确的处理器，即，在这个例子中的处理器500y。在这个实施例中，此刻请求被直接传递到处理器500y的SIP后端部分506y，用来通过存储单元508y中的用户特定数据来作进一步处理。

因此，在处理该请求之后，可以将响应或其它的消息通过所选择的处理器500y中SIP前端部分502y来发送给例如请求用户。虽然本实施例已经使用SIP信令作了描述，但是当使用其它的信令协议时，例如HTTP(超文本传递协议)，同样可以应用本实施例。如果使用了HTTP，则可能有必要从最初的接收处理器500x的前端部分502x发送响应，如图中虚线指示的。因此，在HTTP中要求保持最初由负载均衡器302响应接收请求而给到请求用户的通信地址。

图6是与上述图5描述的实施例略有不同的图解说明，其中中央分配器600提供在应用服务器中的多个处理器的所有的无状态SIP前端部分602与所有有状态SIP后端部分604之间的请求分配链接。这样，来自任何处理器的SIP前端部分602的请求(要求存储在与请求用户相关联的特定处理器中的用户特定数据)可以通过中央分配器功能模块600按上述图5描述的方式重定向到正确的处理器。

在上述图4-6描述的实施例中，分配器404x、y和中央分配器504、600还可以包括规定其中使用的调度算法的一组预定的规则(未示出)。例如，这些规则可以确定在接收的服务请求中应当使用什么参数作为算法的输入，这可能取决于消息和/或协议类型等。

上述实施例中的分配器404x、y和中央分配器504、600还可以从中央管理员(未示出)等接收配置信息，例如，在应用服务器中是否改变处理器配置或者一些用户特定数据是否应当从本地存储单元中移动或删除。用于选择正确的处理器的散列算法还可由于改变的处理器的数量而改变。因此，分配器404x、y和中央分配器504、600将一直保持到现在并对引入服务请求提供正确的结果。

最后，现在将参考图7中的流程图来描述通常处理来自连接到多媒体服务网络的多处理器应用服务器中的请求用户的服务请求的过程。与先前描述的实施例一样，应用服务器中的各个处理器包括本地存储单元，其中不同的处理器对不同的用户存储用户特定数据。此外，多媒体服务网络可以是使用SIP信令的IMS网络，但是本发明通常不限于此。

在第一步骤700，在应用服务器中(例如，通过轮询调度算法)或多或少随机选择的处理器中接收请求，即，不考虑请求用户的身份。在下一步骤702，确定对于处理该请求(即，包括对这样的数据的任何检索、修改和/或存储行为)是否要求用户特定数据。如果要求，则在步骤704中从该请求中提取请求用户的身份或其它相容的用户有关参数，并且在随后的步骤706，基于所提取的用户身份或其它用户有关参数来应用调度算法，例如散列算法来找到正确的处理器。

然后在步骤708，确定最初接收处理器是否实际上是与请求用户相关联的处理器，即，所应用的调度算法是否导致了那个处理器或另一个处理器。如果接收处理器是正确的处理器，(虽然这是不太可能的)，则在步骤710中可以进一步处理请求，而不用将请求传送给另一个处理器。如果接收处理器不是正确的处理器，则在步骤712中，将请求传递给在步骤706中通过所应用的调度算法选择的处理器。应当注意，如果在步骤702确定实际上不要求用户特定数据来处理该请求，则可以由最初的接收处理器来处理该请求，如从步骤702指向到步骤710的箭头所指示的。

本发明(例如，根据上述图3-7的实施例)当应用在包括多个处理器的机群的用于多媒体服务的应用服务器中时，可以提供一些优势。通过使用处理器中的本地存储单元而不依赖于公共数据库，降低了响应或其它行为的延迟。在通用数据库中对存储容量的需求，如果确实需要，也会降低。

这个解决方案还提供了关于处理器配置以及处理器配置的改变的灵活性，而不会危害到安全性和可靠性。因为一个处理器和相同的处理器将对特定的用户处理所有的用户特定数据，可以在处理器之间均匀地分配存储和处理负载，同时保持一致性。而且，通过UDP的SIP重传将不是问题，因为它们总是到达相同的与请求用户相关联的处理器。最后，可以提高多媒体服务的性能并且促进应用服务器的管理。

虽然已经针对特定示意性实施例描述了本发明，但是通常该描述的目的仅在于说明本发明的概念而不应当视为对本发明的范围的限制。例如，当描述上述实施例时始终使用了SIP信令协议和IMS的概念，但是基本上可以使用用于实现多媒体通信的任何其它的标准和服务网络。此外，本发明不限于任何的特定服务，而是可用于在请求时执行任何类型的服务。本发明由所附的权利要求定义。

Claims (20)

1.一种在具有多个处理器的应用服务器中处理对多媒体服务的引入请求的方法，包括以下步骤：

-在所述多个处理器中的第一处理器中接收来自用户的服务请求，所述服务请求要求用户特定数据的处理；

-从所接收的服务请求中提取所述用户的身份或其它相容的用户有关参数；

-应用使用所提取的身份或其它用户有关参数作为输入的调度算法，以便选择关联所述用户并且为那个用户本地存储用户特定数据的所述多个处理器中的第二处理器，其中，所述调度算法适合于始终对各个特定的用户提供相同的结果；以及

-将所述服务请求传送给所选择的第二处理器，以便通过处理所述用户特定数据来处理所述服务请求。

2.如权利要求1所述的方法，其中在第一处理器的无状态前端部分接收所述服务请求，并且将所述服务请求传送给第二处理器的有状态后端部分。

3.如权利要求2所述的方法，其中在设置在第一处理器的所述前端部分和第一处理器的有状态后端部分之间的分配器中应用所述调度算法。

4.如权利要求3所述的方法，其中所述分配器是设置在应用服务器中的所述多个处理器的无状态前端部分和有状态后端部分之间的中央分配器。

5.如权利要求3所述的方法，其中所述分配器是仅设置在第一处理器的所述前端和后端部分之间的本地分配器。

6.如权利要求2-5中任一项所述的方法，其中信令协议用来处理所述服务请求，并且所述无状态前端部分在所述信令协议的网络层中运行，以及所述有状态后端部分在信令协议的更高层中运行。

7.如权利要求1-5中任一项所述的方法，其中所述用户特定数据的处理包括对这样的数据的任何检索、修改和/或存储行为。

8.如权利要求3-5中任一项所述的方法，其中所述应用服务器连接到IP多媒体子系统网络，并且会话初始化协议信令用于所接收的服务请求，所述分配器相对于会话初始化协议堆栈设置在无状态网络层和包括应用层的有状态更高层之间。

9.如权利要求2-5中任一项所述的方法，其中所述应用服务器连接到IP多媒体子系统网络，并且超文本传递协议信令用于所接收的服务请求。

10.一种用于处理对多媒体服务的引入请求的具有多个处理器的应用服务器的第一处理器中的装置，包括：

-用于接收来自用户的服务请求的部件，所述服务请求要求用户特定数据的处理；

-用于从所接收的服务请求中提取所述用户的身份或其它相容的用户有关参数的部件；

-用于应用使用所提取的身份或其它用户有关参数作为输入的调度算法来选择关联所述用户并且为那个用户本地存储用户特定数据的所述多个处理器的第二处理器的部件，其中，所述调度算法适合于始终对各个特定的用户提供相同的结果；以及

-用于将所述服务请求传送给所选择的第二处理器以便通过处理所述用户特定数据来处理所述服务请求的部件。

11.如权利要求10所述的装置，其中所述接收、提取和传送部件在第一处理器的无状态前端部分中实现，所述前端部分适合于接收服务请求并将所述服务请求传送给所选择的第二处理器的有状态后端部分。

12.如权利要求11所述的装置，其中所述应用部件在设置在第一处理器的所述前端部分和第一处理器的有状态后端部分之间的分配器中实现。

13.如权利要求12所述的装置，其中所述分配器是设置在所述应用服务器中的所述多个处理器的无状态前端部分和有状态后端部分之间的中央分配器。

14.如权利要求12所述的装置，其中所述分配器是仅设置在第一处理器的所述前端和后端部分之间的本地分配器。

15.如权利要求11-14中任一项所述的装置，其中信令协议用于处理所述服务请求，并且所述无状态前端部分在所述信令协议的网络层中运行，以及所述有状态后端部分在所述信令协议的更高层中运行。

16.如权利要求10-14中任一项所述的装置，其中所述用户特定数据的处理包括对这样的数据的任何检索、修改和/或存储行为。

17.如权利要求12-14中任一项所述的装置，其中所述应用服务器连接到IP多媒体子系统网络，并且会话初始化协议信令用于所接收的服务请求，所述分配器相对于会话初始化协议堆栈设置在无状态网络层和包括应用层的有状态更高层之间。

18.如权利要求11-14中任一项所述的装置，其中所述应用服务器连接到IP多媒体子系统网络，并且超文本传递协议信令用于所接收的服务请求。

19.一种用于处理对多媒体服务的引入请求的具有多个处理器的应用服务器，各个处理器包括：

-适合于接收服务请求的无状态前端部分，

-适合于处理服务请求的有状态后端部分，以及

用于本地存储用户特定数据的存储单元，

其中，

-分配器设置在所述前端和后端部分之间，所述分配器适合于对来自用户的服务请求应用调度算法，要求使用身份或其它的用户有关参数作为输入来处理用户特定数据，以选择关联所述用户以及为那个用户本地存储用户特定数据的所述多个处理器的另一个处理器，其中，所述调度算法适合于始终对各个特定的用户提供相同的结果。

20.如权利要求19所述的装置，其中所述分配器是设置在所述应用服务器中的所述多个处理器的无状态前端部分和有状态后端部分之间的中央分配器，或仅设置在各单个处理器的前端和后端部分之间的本地分配器。

Images