专利名称：一种实现重定向的方法和系统的制作方法
技术领域：
本发明涉及通信领域，具体涉及一种实现重定向的方法和系统。
背景技术：
随着IPTV(网络电视)系统的发展，IPTV用户数越来越多，服务内容也爆炸式增长，IPTV网络中的服务节点也在不停增长。当用户的服务节点由于资源不足而无法满足用 户的服务请求时，会通过IPTV的重定向机制将用户请求重定向到另一个可以提供服务的 节点上，保证了用户的请求能够得到满足。目前IPTV系统中的这种重定向机制，主要依靠数据库来保持各个节点的资源状 况。当前节点无法提供服务时，可以查询数据库中各节点的资源状况，以找到可以提供服 务的资源。随着用户请求数的急剧上升，数据库的查询也越来越频繁，造成数据库性能下 降，用户请求无法得到及时回应。更严重的是，一旦数据库崩溃，这种节点间重定向将无法 进行，原本连接起来的各个节点将成为孤岛，导致大量用户请求失败，造成用户体验严重下 降。
发明内容
有鉴于此，本发明的主要目的在于提供一种实现重定向的方法和系统，避免因数 据库的问题而导致用户请求的失败，提高用户满意度。为达到上述目的，本发明的技术方案是这样实现的一种实现重定向的方法，该方法包括将业务数据库MSDB的媒体业务服务器MSS信息同步到MSDB以外的共享内存中；用户终端设备UE需要重定向时，根据共享内存中的MSS信息确定UE可用的MSS。同步所述MSS信息的过程包括向MSDB发送数据同步请求，MSDB根据该数据同步请求反馈所请求的数据，将该数 据保存到已创建的所述共享内存中。 所述确定UE可用的MSS的过程包括接收因UE需要重定向而发起的重定向请求，通过解析该请求中的服务字段以获 取请求类型和内容ID，从所述共享内存中获取完整的可服务UE的MSS的地址和端口信息。该方法进一步包括对所述共享内存中保存的数据进行索引创建，创建过程包括以请求类型和内容 ID为关键字来创建HASH索引，将HASH索引保存到本进程堆内存中。该方法进一步包括将所述可用的MSS通知给所述UE，由UE针对被通知的可用MSS进行重定向。一种实现重定向的系统，该系统包括同步单元、重定向决策单元；其中，所述同步单元，用于将MSDB的MSS信息同步到MSDB以外的共享内存中；所述重定向决策单元，用于在UE需要重定向时，根据共享内存中的MSS信息确定UE可用的MSS。 所述同步单元在同步所述MSS信息时，用于 向MSDB发送数据同步请求，触发MSDB根据该数据同步请求反馈所请求的数据；并 将MSDB所反馈的数据保存到已创建的所述共享内存中。所述重定向决策单元在确定UE可用的MSS时，用于接收因UE需要重定向而发起的重定向请求，通过解析该请求中的服务字段以获 取请求类型和内容ID，从所述共享内存中获取完整的可服务UE的MSS的地址和端口信息。
所述同步单元进一步用于对所述共享内存中保存的数据进行索引创建，进行索引 创建时用于以请求类型和内容ID为关键字来创建HASH索引，将HASH索引保存到本进程堆内存中。所述重定向决策单元，进一步用于将所述可用的MSS通知给所述UE，触发UE针对被通知的可用MSS进行重定向。本发明实现重定向的方法和系统，可有效避免因数据库的问题而导致用户请求的 失败，因而能明显提高用户满意度。
图1为本发明一实施例的实现重定向的系统图；图2为本发明一实施例的实现重定向的流程图；图3为本发明实现重定向的流程简图。
具体实施例方式参见图1，图1为本发明一实施例的实现重定向的系统图，该系统包括媒体业 务服务器(MSS, Media Service Server)、媒体业务控制服务器(MSCS, Media Service Control Server)、用户终端设备(UE，User Equipment)、业务数据库(MSDB，Media Service Database)。其中，MSS作为IPTV系统中节点的服务请求控制单元，用于接收UE发送的RTSP服 务请求；同时还用于在本业务服务器无法提供服务的情况下向MSCS发送重定向请求；还能 够向UE返回可提供服务的MSS访问链接。UE用于向MSS发送RTSP服务请求，根据MSS返回的RTSP服务应答，向可用的MSS 重新发起RTSP服务请求。MSCS用于从MSDB同步各个MSS所拥有的资源情况等MSS信息，并保存到共享内存 中；同时通过查询MSDB来更新各个MSS的资源情况。还可以接收MSS的重定向请求并根据 其中的资源名称等信息查询可提供服务的MSS链接地址，再将查询到的MSS链接地址返回 给MSS。另外，在业务进程因崩溃等原因发生重启后，通过读取共享内存中各MSS的资源信 息，提供一定程度的灾难恢复能力。在具体应用中，MSCS可以从MSDB同步重定向所需的MSS资源信息。通常，只需要 同步用于完成重定向功能所需的最小数据集合，以减少数据同步时间和共享内存的占用， 其中必须包含的是每个MSS所控制的节点信息和节点内所有资源的ID。并且，MSCS可以定时从MSDB同步MSS资源的增量信息，以保证和MSDB中的数据一致。MSDB中每条有改变的记录，都会被分配对应的时间戳。因此MSCS在从MSDB获取增量信息时，只同步时间戳大于 最后一次同步成功时的时间戳的记录，之后将需要同步的时间戳按照时间戳的先后顺序插 入到已有的数据集合中。时间戳的使用保证了增量信息同步的完整性和有序性，也就保证 了共享内存和MSDB的数据一致性。MSCS可以对同步的MSS资源数据进行创建索引的处理，以提高查询速度。索引可 以不在共享内存中保存，而是在进程的堆空间中保存，以尽量减少共享内存的占用。这里所 说的索引是指以资源的ID为关键字key，资源所在的节点为取值value创建的哈希HASH 表，这样可以通过重定向请求中的资源ID快速找到资源所在节点的MSS信息。当然，在获取了增量信息后，同样可以对索引进行更新。MSCS接收到来自MSS的重定向请求时，根据该请求在共享内存中的MSS资源信息 中查找可用的MSS链接地址，并将找到的可用的MSS链接地址反馈给MSS。在MSDB崩溃后，MSCS能够依靠共享内存中的业务资源信息继续提供重定向服务。 这是因为，即使在业务进程崩溃后，由于共享内存没有被释放；因此在业务进程重启后，可 以重新读取共享内存中的数据，并重建所述索引，以继续提供重定向服务。由以上描述可见，图1所示系统能够实现图2所示流程。参见图2，图2为本发明 一实施例的实现重定向的流程图，该流程中的步骤201到步骤205描述业务数据同步的流 程和业务数据在共享内存中构建的过程，步骤206到步骤210描述对RTSP服务请求的处理 流程。图2所示流程包括以下步骤步骤201 =MSCS启动后创建共享内存，之后通过数据库查询接口向MSDB发送数据 同步请求，需要同步的数据包括VOD分布信息、TVOD分布信息、频道分布信息。步骤202 =MSDB将MSCS所请求的数据通过数据同步应答反馈给MSCS，MSCS收到 MSDB的数据同步应答，从中解析出所有数据并保存到共享内存中。步骤203 :MSCS对共享内存中保存的数据进行索引创建，以请求类型和内容ID(如 VOD、TV0D、频道的内容ID等)为关键字来创建HASH索引，将HASH索引保存到本进程堆内 存中。步骤204 =MSCS定时向MSDB发送增量同步请求，请求中包含最后一次增量或全量 同步成功的时间戳。步骤205 :MSDB将所述时间戳之后更新的数据通过增量同步应答反馈给MSCS， MSCS应用MSDB所反馈的增量数据(主要包括VOD、TV0D、频道表的增量数据)更新共享内 存中的数据，同时还可以根据更新后的数据更新堆内存中的索引。步骤206 =UE向MSS A发起RTSP服务请求。步骤207 =MSS A收到RTSP服务请求后，确定自身暂时无法提供服务，则向MSCS发 起节点间的重定向请求。步骤208 :MSCS收到MSS A的重定向请求后，通过解析该请求中的服务字段以获取 请求类型(VOD、TV0D、频道)和内容ID，查询对应的索引，从共享内存中获取完整的可服务 的MSS B的地址和端口信息。步骤209 =MSCS将获取的MSS B的地址和端口信息等MSS信息封装成MSS链接地 址，并将该MSS链接地址携带于重定向应答中反馈给MSS A。
步骤210:MSS A收到MSCS的重定向应答后，将其中所包含的MSS链接地址携带于 RTSP服务应答中发送给UE。步骤211 :UE接收来自MSS A的RTSP服务应答，向该RTSP服务应答中的MSS链接 地址所对应的MSS B发起RTSP服务请求。结合以上所述的系统及方法可知，本发明实现重定向的操作思路可以表示如图3 所示。参见图3，图3为本发明实现重定向的流程简图，该流程包括以下步骤 步骤310 将MSDB的MSS信息同步到MSDB以外的共享内存中。步骤320 :UE需要重定向时，根据共享内存中的MSS信息确定可用的MSS，并通知 UE。步骤330 =UE针对被通知的可用MSS进行重定向。需要说明的是，在图1所示的系统中，MSCS中可以设置同步单元、重定向决策单 元。其中，同步单元可以将MSDB的MSS信息同步到MSDB以外的共享内存中；实际上，同步 单元可以对MSCS中的共享内存进行维护，并将同步的MSS信息储存于该共享内存中。当因 收到重定向请求等信息而确定UE需要重定向时，重定向决策单元可以根据所述共享内存 中的MSS信息确定可用的MSS，并向UE反馈该可用的MSS的链接地址。具体而言，同步单元在同步所述MSS信息时，能够向MSDB发送数据同步请求，触发 MSDB根据该数据同步请求反馈所请求的数据；并将MSDB所反馈的数据保存到已创建的共 享内存中。重定向决策单元在确定UE可用的MSS时，则能够接收因UE需要重定向而发起 的重定向请求，通过解析该请求中的服务字段以获取请求类型和内容ID，从共享内存中获 取完整的可服务UE的MSS的地址和端口信息。另外，同步单元能够进行创建索引的操作，重定向决策单元则能够对创建的索引 加以利用；并且，重定向决策单元还能够将可用的MSS通知给UE,触发UE针对被通知的可 用MSS进行重定向。综上所述可见，由于各个MSS的资源信息都保持在共享内存中，并且共享内存的 访问速度远高于数据库，因此重定向请求可以得到更快的处理，用户体验大大改善。同时在 数据库崩溃和业务进程由于各种原因而重启的情况下，仍能依靠共享内存中的数据继续提 供重定向服务，大大提供了系统的可靠性。显然，无论是方法还是系统，本发明实现重定向的技术与现有技术对比具有如下 优点(1)、MSCS在收到MSS的重定向请求时，不查询数据库，而是查询共享内存中保存 的节点资源信息，获取可服务的MSS地址数据，查询速度大大提高；(2)、即使数据库无法提供服务，MSCS仍然可以依靠共享内存中的数据来提供服务；(3)、在数据库崩溃和业务进程重启的情况下，共享内存中的数据不会消失，MSCS 只需对共享内存中的数据进行重建索引操作，即可继续提供服务。以上优点均可有效避免因数据库的问题而导致用户请求的失败，因而能明显提高 用户满意度。以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在 本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护 范围之内。
权利要求
一种实现重定向的方法，其特征在于，该方法包括将业务数据库MSDB的媒体业务服务器MSS信息同步到MSDB以外的共享内存中；用户终端设备UE需要重定向时，根据共享内存中的MSS信息确定UE可用的MSS。
2.根据权利要求1所述的方法，其特征在于，同步所述MSS信息的过程包括向MSDB发送数据同步请求，MSDB根据该数据同步请求反馈所请求的数据，将该数据保 存到已创建的所述共享内存中。
3.根据权利要求1所述的方法，其特征在于，所述确定UE可用的MSS的过程包括 接收因UE需要重定向而发起的重定向请求，通过解析该请求中的服务字段以获取请求类型和内容ID，从所述共享内存中获取完整的可服务UE的MSS的地址和端口信息。
4.根据权利要求1至3任一项所述的方法，其特征在于，该方法进一步包括对所述共享内存中保存的数据进行索引创建，创建过程包括以请求类型和内容ID为 关键字来创建HASH索引，将HASH索引保存到本进程堆内存中。
5.根据权利要求4所述的方法，其特征在于，该方法进一步包括将所述可用的MSS通知给所述UE，由UE针对被通知的可用MSS进行重定向。
6.一种实现重定向的系统，其特征在于，该系统包括同步单元、重定向决策单元；其中，所述同步单元，用于将MSDB的MSS信息同步到MSDB以外的共享内存中； 所述重定向决策单元，用于在UE需要重定向时，根据共享内存中的MSS信息确定UE可 用的MSS。
7.根据权利要求6所述的系统，其特征在于，所述同步单元在同步所述MSS信息时，用于向MSDB发送数据同步请求，触发MSDB根据该数据同步请求反馈所请求的数据；并将 MSDB所反馈的数据保存到已创建的所述共享内存中。
8.根据权利要求6所述的系统，其特征在于，所述重定向决策单元在确定UE可用的 MSS时，用于接收因UE需要重定向而发起的重定向请求，通过解析该请求中的服务字段以获取请 求类型和内容ID，从所述共享内存中获取完整的可服务UE的MSS的地址和端口信息。
9.根据权利要求6至8任一项所述的系统，其特征在于，所述同步单元进一步用于对所 述共享内存中保存的数据进行索引创建，进行索引创建时用于以请求类型和内容ID为关键字来创建HASH索引，将HASH索引保存到本进程堆内存中。
10.根据权利要求9所述的系统，其特征在于，所述重定向决策单元，进一步用于 将所述可用的MSS通知给所述UE，触发UE针对被通知的可用MSS进行重定向。
全文摘要
本发明公开了一种实现重定向的方法和系统，均可将业务数据库的媒体业务服务器信息同步到业务数据库以外的共享内存中；用户终端设备需要重定向时，根据共享内存中的媒体业务服务器信息确定用户终端设备可用的媒体业务服务器。本发明实现重定向的方法和系统，可有效避免因数据库的问题而导致用户请求的失败，因而能明显提高用户满意度。
文档编号H04L12/56GK101867526SQ201010210998
公开日2010年10月20日 申请日期2010年6月28日 优先权日2010年6月28日
发明者刘俊, 熊勤 申请人:中兴通讯股份有限公司