首页> 中国专利> 对媒体服务器中的分布式媒体资源进行负载平衡和切换

对媒体服务器中的分布式媒体资源进行负载平衡和切换

摘要

一种对多个服务器上的媒体资源进行负载平衡的方法和系统。可以从请求第一媒体处理资源的客户端接收第一请求,该请求具有根据第一协议的格式。该第一请求可以根据第一协议转换成第一转换请求。可以从包括多个服务器的第一服务器分区,选择负载最小的第一服务器,该多个服务器中的每一个提供请求的第一媒体处理资源。根据第二协议,将第一转换请求转发到该第一服务器。

著录项

  • 公开/公告号CN101322385A

    专利类型发明专利

  • 公开/公告日2008-12-10

    原文格式PDF

  • 申请/专利权人 国际商业机器公司;

    申请/专利号CN200680045823.X

  • 发明设计人 W·L·努斯比克尔;

    申请日2006-12-08

  • 分类号

  • 代理机构中国国际贸易促进委员会专利商标事务所;

  • 代理人李向英

  • 地址 美国纽约

  • 入库时间 2023-12-17 21:06:40

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2022-11-18

    未缴年费专利权终止 IPC(主分类):H04L29/08 专利号:ZL200680045823X 申请日:20061208 授权公告日:20130130

    专利权的终止

  • 2013-01-30

    授权

    授权

  • 2009-02-04

    实质审查的生效

    实质审查的生效

  • 2008-12-10

    公开

    公开

说明书

享有著作权内容的权利保留

该专利文献的公开部分包含受到著作权保护的内容。著作权人不反对任何人对专利文献或专利公开进行复制,因为其出现在专利与商标局的文献或记录中,但对著作权的其他方面进行保留。

技术领域

本发明涉及分布式资源管理,具体涉及分布式媒体资源的管理。

背景技术

自动语音识别器(ASR)和文本到语音合成器(TTS)是一般以自动交互系统执行的语音资源,例如用于电话呼叫中心的自动语音响应系统。ASR和TTS合成器是消费性资源,通常必须由构成语音服务器解决方案的多台机器共同执行。为了减少硬件成本,语音资源通常在多个客户端上共享,只有在它们被实际需要时才进行分配。

媒体处理资源控制协议(MRCP)是向请求媒体处理资源的客户端设备,例如ASR和TTS合成器提供一种机制以控制网络中的这种资源的协议。尤其是,MRCP定义了控制媒体处理资源的所需请求、响应和事件。不幸地是,MRCP标准只依赖于客户端以分布客户端请求。事实上,MRCP没有由服务器执行的对多个节点上的媒体处理资源进行分布的方法。此外,访问资源的客户端也不清楚哪些服务器资源可用,哪些服务器资源当前正在被使用。因此,负载平衡的最普遍的方法是,客户端顺序地向多个服务器发送请求,直到建立客户端会话。然而,这种方法不能适当地平衡服务器的负载,这样会降低硬件的效率。

因而,提供一种技术,可以使服务器群对自己的媒体处理资源进行分布,并对这些资源进行负载平衡将是有益的。

发明内容

本发明涉及对多个服务器中的媒体资源进行负载平衡的方法和系统。可以从请求第一媒体处理资源的客户端接收第一请求,该请求具有根据第一协议的格式。第一请求可以被转换(morph)为具有根据第二协议的格式的第一转换请求。可以从包括多个服务器的第一服务器区中选出负载最小的第一服务器,所述多个服务器中的每个服务器提供所要求的第一媒体处理资源。可根据第二协议将第一转换请求转发至第一服务器。

本发明的另一实施例包括机器可读存储器,其可被编程用于使机器执行本文描述的多个步骤。

附图说明

参考附图可以更加详细地在下文描述本发明的优选实施例,其中:

图1示出了根据本发明的一个实施例对媒体处理资源仅此负载平衡的系统框图。

图2是示出了根据本发明的另一个实施例的平衡媒体处理资源的方法流程图。

具体实施方式

本发明的说明书和权利要求共同限定了被认为新颖的本发明的特点,可以相信结合附图考虑对本发明的说明,可以更好的理解本发明。根据要求,在此公开了本发明的详细实施例,应当理解的是公开的实施例仅仅是本发明的一种示范,本发明可以以多种形式进行来实施。因而,在此公开的具体结构和功能细节不应被解释为限制,而仅仅是权利要求的基础,并作为教导本领域技术人员,在实践中以多变的方式实现本发明的任何合适的详细结构的基础。此外,在此使用的术语和短语并不是要进行限制,而是提供一种对于本发明可理解的描述。

在此公开的实施例涉及可用于对多个服务器中的媒体资源控制协议资源进行负载平衡的方法和系统。例如,请求媒体处理资源的MRCP消息可以用协议转换器/客户端通过TCP/IP套结字接受,并被转换为标准超文本传输协议(HTTP)消息。该HTTP消息而后被转发到负载平衡器。在一组每个服务器都提供的请求媒体处理资源的服务器中,负载平衡器可以选择负载最小的服务器,并将根据HTTP协议将转换的请求转发到所选择的服务器。当负载平衡器接收到下一个请求时,该负载平衡器可以再次从服务器组中选择负载最小的服务器,并将下一个请求发给该服务器。第二次选中的服务器可以是也可以不是先前被选中的服务器。

图1是示出了包括服务器群102的系统100的框图。服务器群102可以包括多个服务器,例如第一服务器104、第二服务器106、第三服务器108和第四服务器110。服务器104、106、108和110中的每一个可以是基于协议的服务器,如MRCP服务器。服务器104、106、108和110可以任何合适的方式联网。例如,服务器可以通过局域网(LAN)、广域网(WAN)、因特网或其他任何通信网络联网。

每一个服务器104、106、108和110都可以提供媒体处理资源。例如,第一服务器104和第二服务器106中的每个都可以提供第一组媒体处理资源112。类似地,第三服务器108和第四服务器110都可以提供第二组处理资源114。媒体处理资源112、114可以是自动语音识别器(ASR)和文本到语音合成器(TTS)、发音人确认器、双音多频识别器,或任何其他可以处理媒体请求的资源。例如,第一组媒体处理资源112可能包括能产生女性声音的文本到语音(TTS)合成器,第二组媒体处理资源114可能包括能够产生男性声音的TTS合成器。

系统100可以包括多个客户端,如客户端120。客户端120可以是任何可以通过网络连接到服务器群102的、并且服务器群102向其提供媒体处理资源的设备。例如,客户端112可以是计算机、电话、移动电话、个人数字助理、游戏控制器、交互式设备或任何其他可以通过如LAN、WAN、因特网或任何其他通信网络,访问由服务器群102提供的媒体处理资源的设备。尽管仅示出了一个客户端120,但系统100可以包括任何数量的访问媒体处理资源112、114的客户端。事实上,在此描述的对媒体处理资源112、114进行分布的方法,便于多个客户端同时使用媒体处理资源112、114。

客户端120通过传送如请求150的第一消息到可通信地链接到服务器群120的转换控制器122,与服务器群102进行通信。该请求150具有根据适当的通信协议的格式。此外,该客户端120可以响应于第一消息,接收如事件156的第二消息。在一种设置中,消息可以根据MRCP具有一定的格式,并在客户端120与转换控制器122之间进行传送。

为了根据MRCP第一版进行消息通信,客户端120可以利用在TCP/IP上运行的如实时流协议(RTSP),与转换控制器122建立用户会话。以这种方式进行的消息通信称为“数据封装(tunneling)”。为了根据MRCP第二版进行消息通信,客户端120可以利用会话初始化协议(SIP)建立用户会话。与RTSP相反,在建立SIP用户会话之后,消息直接通过TCP/IP转发,而没有被数据封装。

转换控制器122可以以硬件、软件或硬件和软件的组合来实现。转换控制器122可以以在一个处理系统中的集中方式或以不同元素处于多个相互连接的处理系统中的分布的方式来实现。尽管转换控制器122在图1中为独立于服务器群102的组件,但其也可以作为服务器群102的组件包括在其中。

该转换控制器122可以包括接收请求150的协议转换器/客户端124,并将请求转换为转换的请求152。该转换的请求152具有的格式可以根据的协议不同于原请求150的格式所根据的协议。例如,协议转换器/客户端124可以将MRCP请求转换为HTTP请求。为了对请求150进行转换,请求中MRCP的特定代码可以被相关的HTTP特定代码所取代。下文表1示出了在转换之前包含在请求150中的代码的例子。

表1-请求示例

ANNOUNCE rtsp://localhost/media/synthesizer RTSP/1.0

CSeq:1

Session 1.IBM.9.22.74.38

Date:Tue,15 FEB 2005 11:28:01 est

Content-Type:application/mrcp

Content-Length:149

SPEAK 100 MRCP/1.0

voice-name:Andrew

Content-Type:application/synthesis+ssml

Content-Length:45

<?xml version=″1.0″?>

<speak>123.</speak>

为了对表1所示的请求进行转换,协议转换器/客户端124可以以如下方式改变消息的RTSP部分中的代码:

替换

″ANNOUNCE rtsp://localhost/media/synthesizer RTSP/1.0″

″POST/synthesizerServlet HTTP 1.1″

″Host:myserver.bocaraton.ibm.com″

″user-agent=Java/1.4.1″

″accept=text/html,image/gif,image/jpeg,*;q=.2,*/*;q=.2″

″connection=keep-alive″.

在这种设置中,消息体的MRCP部分可以保持不变。下文中表2示出了通过该方式对第一请求150进行转换后生成的转换请求152的例子。

表2-转换请求示例#1

POST/synthesizerServlet HTTP 1.1

Host:myserver.bocaraton.ibm.com

user-agent=Java/1.4.1

accept=text/html,image/gif,image/jpeg,*;q=.2,*/*;q=.2

connection=keep-alive

CSeq:1

Session 1.IBM.9.22.74.38

Date:Tue,15 FEB 2005 11:28:01 est

Content-Type:application/mrcp

Content-Length:149

SPEAK 100 MRCP/1.0

voice-name:Andrew

Content-Type:application/synthesis+ssml

Content-Length:45

<?xml version=″1.0″?>

<speak>123.</speak>

在另一个设置中,协议转换器/客户端124可以以如下方式改变消息的RTSP部分中的代码:

替换

″ANNOUNCE rtsp://localhost/media/synthesizer RTSP/1.0″

″POST/synthesizerServlet HTTP 1.1″

″Host:myserver.bocaraton.ibm.com″

″user-agent=Java/1.4.1″

″accept=text/html,image/gif,image/jpeg,*;q=.2,*/*;q=.2″

″connection=keep-alive″

并删除

″Content-Type:application/mrcp″

″Content-Length:149″.

在该设置中,可以以如下方式改变消息中的MRCP部分中的代码

替换

“SPEAK 100 MRCP/1.0”

“MRCPMethod:Speak”

以这种方式对代码的转换,对RTSP和MRCP消息进行了组合,其将“SPEAK 100”改变为“MRCPMethod:Speak”。此外,从消息的RTSP部分中移去的内容类型和内容长度标头的功能,可以由事先包含在消息MRCP部分的类型代码来执行。下文表3示出了根据该例,通过对请求150进行转换产生的转换请求的例子152。

表3-请求示例#2

POST/synthesizerServlet HTTP 1.1

Host:myserver.bocaraton.ibm.com

user-agent=Java/1.4.1

accept=text/html,image/gif,image/jpeg,*;q=.2,*/*;q=.2

connection=keep-alive

CSeq:1

Session 1.IBM.9.22.74.38

Date:Tue,15 FEB 2005 11:28:01 est

MRCPMethod:Speak

voice-name:Andrew

Content-Type:application/synthesis+ssml

Content-Length:45

<?xml version=″1.0″?>

<speak>123.</speak>

对上述处理进行反转,协议转换器/客户端124也可以将响应于转换请求产生的事件154,转换为具有根据MRCP的格式的转换事件156。例如在第一事件154中HTTP特定码可以用相关的MRCP特定代码代替。

该协议转换器/客户端124可以作为服务器104、106、108和110的客户端。例如,协议转换器/客户端124可以作为HTTP客户端。尤其是,协议转换器124可以将转换的请求152转发至负载平衡器130。负载平衡器130包括将请求路由至服务器104、106、108和110的调度程序132。特别是,调度程序132可以将转换的请求152路由至服务器104、106、108和110中的其中一个,其具有媒体处理资源112、114适于对转换请求152作出响应的,并且是具有这些媒体处理资源112、114的服务器组的中负载最小的。

例如,调度程序132可以将资源选择规则134应用于转换请求152,以对适于对转换请求152进行响应的如第一分区140或第二分区142的服务器分区进行确定。例如,调度程序132可以将资源选择规则134施于转换请求152的统一资源标识符的模式(pattern)和/或内容类型标头中,以确定合适的媒体处理资源112,114。该调度程序132而后可以参考分区标识符136来确定哪个分区(即第一分区140或第二分区142)包含提供标识资源的服务器。

在一个更具体的实施例中,转换请求152可以包括包含“voice=Lisa”和“content type=TTS”的内容类型标头。此外,指示“voice=Lisa”和“content type=TTS”的标识符可以包含在转换请求152的URI中。响应于接收转换请求152,调度程序132可以应用资源选择规则134,确定提供“Lisa”TTS的媒体处理资源类型是媒体处理资源112。调度程序可以参考标识符136来选择包括第一服务器104和第二服务器106的第一分区140。接着,调度程序132可以参考对应于每个服务器104、106的路由信息的路由清单,并询问每个路由器104、106确定哪个服务器负载最小。

如果某一特定服务器不再可用,例如服务器脱机,那么可以将该服务器从路由清单上移去。因此,调度程序152可以基本忽略脱机服务器。当服务器再次联机时,服务器可以再次将它添加到路由清单上。以这种方式,负载平衡器130在负载平衡以外,也可以提供切换。

在确定哪个服务器负载最小时,调度程序将转换请求152转发到该服务器。例如,如果第一服务器负载最小,那么调度程序132可以选择第一服务器104上媒体处理资源112的URI。该调度程序132然后通过向媒体小服务程序116转发转换请求152,调用第一服务器上的104上媒体小服务程序116。媒体小服务程序114、116可以是以合适的中间设备平台来实现的HTTP小服务程序,该平台支持在多个服务器节点上以分布式的方式表示小服务程序。这种平台的一个例子是J2EE,但本发明并不限于此。

为了实现与选择的处理资源104的亲和(affinity),协议转换器/客户端120可以支持与cookies的会话和/或统一资源定位器的重写。该负载平衡器130可以包括亲和支持(affinity support)138,以在需要时保持协议/客户端120与媒体处理资源104的亲和。例如,可以对负载平衡器130进行配置,被动地允许cookies在期望的条件下绕过负载平衡路由,例如,当对媒体处理资源修改未完成(outstanding)的请求时。也可通过cookies亲和对亲和支持进行配置,为协议转换器/客户端120在需要时获取服务器的类同。

媒体小服务程序116对转换请求152进行解析,并将解析后的请求152转发到选中的媒体处理资源112。从转换请求152中解析出的信息可以包括URI的回收小服务程序,以指示将响应于转换请求152由媒体处理资源产生的事件154转发到回收小服务程序126。该解析信息也可以包括会话标识符,以指示事件154应转发到哪个客户端120。

该回收小服务程序可以可通信地链接协议转换器/客户端124,该回收小服务程序126可以从事件154解析会话标识符,并将事件154转发到协议转换器/客户端124,指示该哪个响应156应转发给适当的客户端120。例如,回收小服务程序126可以提供客户端120的URI。该协议转换器/客户端124然后根据第一协议将事件154转换为转换事件156,并将事件156转发到客户端120。例如,该协议转换器/客户端124可以根据MRCP转发转换事件156。

当从客户端120或任何其他客户端接收第二请求时,可以重复对该源请求150的上述处理。如果第二请求要求与第一请求相同的媒体处理资源112,且该第一服务器104仍然是负载最小的,该转换请求可以再次被转发到第一服务器104。但是,如果在第一分区140中不再是负载最小的服务器,可以选择另一个负载最小的服务器。例如,如果现在第二服务器106是第一分区140中负载最小的服务器,那么可以选择第二服务器106,并向其转发第二转换请求。如果第二请求要求不同于第一请求的媒体处理资源,如媒体处理资源114,那么将第二转换请求转发给另一个具有请求的媒体处理资源114的服务器,如第三服务器108。如果第三服务器108是包含在第二分区142中的最小负载服务器,那么通过第四服务器110从第二分区142中,选择第三服务器108。

图2是示出了根据本发明的另一个实施例的平衡媒体处理资源负载的方法200。在步骤205开始,可以从请求第一媒体处理资源的客户端接收第一请求,该请求具有根据第一协议的格式。在步骤210,该第一请求可以被转换为具有根据第二协议的格式的第一转换请求。在步骤215,可以从包括多个服务器的服务器分区,选择负载最小的第一服务器,多个服务器中的每一个都提供请求的第一媒体处理资源。前进到步骤220,可以根据第二协议向第一服务器转发第一转换请求。

在步骤225,可以从客户端接收第二请求。可以将第二请求转换为具有根据第二协议的格式的第二转换请求,如步骤230所示。参考确定框235,如果第二处理请求要求第一媒体处理资源,该方法可以继续到确定框240。如果第一服务器仍是第一分区中的最小负载服务器,该符合第二协议的第二转换请求可以转发到第一服务器。但是,如果第一服务器不再是最小负载服务器,可以从第二分区选择是最小负载服务器的第二服务器,如步骤250所示。前进到步骤260,可以根据第二协议,将第二转换请求转发到第二服务器。

再次参考确定框235到255,如果不是由第二请求选择第一媒体处理资源,那么可以从包括多个服务器的第二服务器分区中,选择负载最小的第二服务器,该多个服务器中的每一个都提供了请求第二多媒体处理资源。再次参考步骤260,可以根据第二协议,将第二转换请求转发到第二服务器。

本发明可以以硬件、软件或硬件和软件结合的形式来实现。本发明可以在一个处理系统中以集中的方式实现,也可以以不同元素分散在多个互连的处理系统的分布式的方式实现。任何处理系统或其他适于执行在此描述的方法的设备都可以适用。硬件和软件的一般结合可以是通用处理系统,其具有当被加载和执行时控制处理系统,以使该系统能执行在此描述的方法的应用程序。本发明也可以被嵌入到应用产品中,其包括了可以执行在此描述的本发明方法的所有特征,并在被加载到处理系统中时能够执行这些方法。

本文中的术语“计算机程序”、“软件”、“应用程序”、变形和/或其组合,意味着以任何语言、代码和符号对一组指令的表达,该指令意在使具有信息处理能力的系统可以直接执行特定功能或在经如下一个或两个步骤后执行特定功能:a)转换为另一种语言、代码或符号;b)以不同材质形式的再现。例如,应用程序可以包括但不限于子程序、函数、过程、对象方法、对象执行、可执行应用、小应用程序、小服务程序、源代码、目标代码、共享库/动态加载库和/或其他设计用于在处理系统中执行的程序序列。

在此使用的术语“一”和“一个”定义为一个和一个以上。在此使用的术语“多个”定义为两个或两个以上。在此使用的术语“另一个”定义为至少第二个或更多。在此使用的术语“包括”或“具有”定义为包含(即,开放型语言)。在此使用的术语“耦结”定义为连接,不必是直接地并且不必是机械地,即通过通信通道或路径可通信地链接。

本发明在不背离精神和及其基本特性的情况下,可以以其他方式来实现。因此,应当参考下文的权利要求而不是前述的说明书来表示本发明的范围。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号