WO2012000398A1 - 一种实现重定向的方法和系统 - Google Patents

一种实现重定向的方法和系统 Download PDF

Info

Publication number
WO2012000398A1
WO2012000398A1 PCT/CN2011/076056 CN2011076056W WO2012000398A1 WO 2012000398 A1 WO2012000398 A1 WO 2012000398A1 CN 2011076056 W CN2011076056 W CN 2011076056W WO 2012000398 A1 WO2012000398 A1 WO 2012000398A1
Authority
WO
WIPO (PCT)
Prior art keywords
mss
shared memory
request
msdb
redirection
Prior art date
Application number
PCT/CN2011/076056
Other languages
English (en)
French (fr)
Inventor
刘俊
熊勤
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012000398A1 publication Critical patent/WO2012000398A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23116—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving data replication, e.g. over plural servers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and system for implementing redirection. Background technique
  • IPTV Internet TV
  • this redirection mechanism in the IPTV system mainly relies on the database to maintain the resource status of each node.
  • the database queries become more frequent, causing database performance to degrade, and user requests cannot be responded to in a timely manner.
  • the database crashes, such inter-node redirection will not be possible, and the original connected nodes will become islands, causing a large number of user requests to fail, resulting in a severe drop in user experience.
  • the main object of the present invention is to provide a method and system for implementing redirection, which avoids failure of user requests due to problems of the database and improves user satisfaction.
  • a method for implementing redirection comprising:
  • MSS Media Business Server
  • MSDB Business Database
  • the MSS available to the UE is determined according to the MSS information in the shared memory.
  • the process of synchronizing the MSS information includes:
  • a data synchronization request is sent to the MSDB, and the MSDB feeds back the requested data according to the data synchronization request, and saves the data to the created shared memory.
  • the process of determining an MSS available to a UE includes:
  • the method further includes:
  • the index is created in the shared memory, and the process includes: creating a HASH index by using the request type and the content ID as keywords, and saving the HASH index to the process heap memory.
  • the method further includes:
  • the available MSS is notified to the UE, and the UE redirects for the notified available MSS.
  • a system for implementing redirection comprising a synchronization unit and a redirection decision unit;
  • the synchronization unit is configured to synchronize MSS information of the MSDB into a shared memory other than the MSDB;
  • the redirection decision unit is configured to determine, according to the MSS information in the shared memory, the MSS available to the UE when the UE needs to be redirected.
  • the synchronization unit is configured to: when synchronizing the MSS information:
  • the redirection decision unit is configured to: when determining an MSS available to the UE:
  • the synchronization unit is further configured to index and create data stored in the shared memory
  • the index is created by creating a HASH index with the request type and the content ID as keywords, and saving the HASH index into the process heap memory.
  • the redirection decision unit is further configured to:
  • Notifying the UE of the available MSS triggering the UE to redirect for the notified available MSS.
  • the method and system for realizing the redirection of the invention can effectively avoid the failure of the user request due to the problem of the database, and thus can significantly improve the user satisfaction.
  • FIG. 1 is a system diagram of implementing redirection according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of a process for implementing redirection according to the present invention. detailed description
  • FIG. 1 is a system diagram of implementing redirection according to an embodiment of the present invention, where the system includes a media service server (MSS, Media Service Server), a media service control server (MSCS, Media Service Control Server), and a user terminal device.
  • MSS media service server
  • MSCS media service control server
  • UE User Equipment
  • MSDB Media Service DataBase
  • the MSS serves as a service request control unit of a node in the IPTV system, and is configured to receive the UE.
  • the Real Time Streaming Protocol (RTSP) is sent, and is also used to send a redirect request to the MSCS if the service server cannot provide the service; and can also return the MSS that can provide the service to the UE. Access the link.
  • RTSP Real Time Streaming Protocol
  • the UE is configured to send an RTSP service request to the MSS, and re-initiate the RTSP service request to the available MSS according to the RTSP service response returned by the MSS.
  • the MSCS is used to synchronize the MSS information such as the resources owned by each MSS from the MSDB and save it to the shared memory.
  • the MSDB is used to update the resources of each MSS.
  • the MSS redirect request can also be received and the MSS link address of the service can be queried according to the resource name and the like, and the queried MSS link address is returned to the MSS.
  • the business process restarts due to a crash or the like, it provides a certain degree of disaster recovery capability by reading the resource information of each MSS in the shared memory.
  • the MSCS can synchronously redirect the required MSS resource information from the MSDB.
  • the MSCS can periodically synchronize the incremental information of the MSS resources from the MSDB to ensure consistency with the data in the MSDB.
  • Each record in the MSDB with a change is assigned a corresponding timestamp.
  • the MSCS when the MSCS obtains the incremental information from the MSDB, it only synchronizes the records with the timestamps greater than the timestamp of the last synchronization success, and then inserts the timestamps that need to be synchronized into the existing datasets in the order of the timestamps.
  • the use of timestamps ensures the integrity and order of incremental information synchronization, which ensures the data consistency of shared memory and MSDB.
  • the MSCS can perform index creation processing on the synchronized MSS resource data to improve the query speed.
  • the index can not be saved in shared memory, but saved in the heap space of the process to minimize the occupation of shared memory.
  • the index mentioned here refers to the hash (HASH) table created by the resource ID as the key (key), and the node where the resource is located, so that the weight can be The resource ID in the directed request quickly finds the MSS information of the node where the resource is located.
  • the index can also be updated.
  • the MSCS When the MSCS receives a redirect request from the MSS, it is in the shared memory according to the request.
  • MSCS can continue to provide redirection services by relying on the information of the business resources in the shared memory. This is because, even after the business process crashes, the shared memory is not released; therefore, after the business process is restarted, the data in the shared memory can be re-read and the index is rebuilt to continue to provide the redirect service.
  • FIG. 2 is a flowchart of implementing redirection according to an embodiment of the present invention. Steps 201 to 205 in the process describe a process of synchronizing service data and a process of constructing service data in a shared memory, step 206 to step 210 describes the processing flow for the RTSP service request.
  • the process shown in Figure 2 includes the following steps:
  • Step 201 After the MSCS is started, the shared memory is created, and then the data synchronization request is sent to the MSDB through the database query interface.
  • the data to be synchronized includes video on demand (VOD) distribution information, point-to-point broadcast (TVOD) distribution information, and channel distribution information.
  • VOD video on demand
  • TVOD point-to-point broadcast
  • Step 202 The MSDB feeds back the data requested by the MSCS to the MSCS through the data synchronization response, and the MSCS receives the data synchronization response of the MSDB, parses all the data from the data, and saves the data to the shared memory.
  • Step 203 The MSCS indexes the data saved in the shared memory, creates a HASH index by using the request type and the content ID (such as VOD, TVOD, channel content ID, etc.) as a keyword, and saves the HASH index to the process heap memory. in.
  • the content ID such as VOD, TVOD, channel content ID, etc.
  • Step 204 The MSCS periodically sends an incremental synchronization request to the MSDB, where the request includes a timestamp of the last incremental or full synchronization success.
  • Step 205 The MSDB feeds back the updated data after the timestamp to the MSCS through the incremental synchronization response, and the MSCS applies the incremental data (including the VOD, TVOD, and channel table incremental data) fed back by the MSDB to update the shared memory. Data, as well as updating the index in heap memory based on the updated data.
  • Step 206 The UE initiates an RTSP service request to the MSS A.
  • Step 207 After receiving the RTSP service request, the MSS A determines that it is temporarily unable to provide the service, and then initiates a redirection request between the nodes to the MSCS.
  • Step 208 After receiving the redirection request of the MSS A, the MSCS obtains the request type (VOD, TVOD, channel) and the content ID by parsing the service field in the request, queries the corresponding index, and obtains the complete information from the shared memory. Address and port information for the MSS B of the service.
  • the request type VOD, TVOD, channel
  • the content ID by parsing the service field in the request, queries the corresponding index, and obtains the complete information from the shared memory. Address and port information for the MSS B of the service.
  • Step 209 The MSCS encapsulates the acquired MSS information such as the address and port information of the MSS B into an MSS link address, and carries the MSS link address in the redirect response to feed back to the MSS A.
  • Step 210 After receiving the MSCS redirect response, the MSS A carries the MSS link address included in the RTSP service response and sends the response to the UE.
  • Step 211 The UE receives the RTSP service response from the MSS A, and initiates an RTSP service request to the MSS B corresponding to the MSS link address in the RTSP service response.
  • FIG. 3 is a schematic flowchart of implementing redirection according to the present invention, where the process includes the following steps:
  • Step 310 Synchronize the MSS MSS information into the shared memory other than the MSDB.
  • Step 320 When the UE needs to be redirected, determine an available MSS according to the MSS information in the shared memory, and notify the UE.
  • Step 330 The UE performs redirection for the notified available MSS.
  • a synchronization unit can be set in the MSCS. Redirect the decision unit.
  • the synchronization unit can synchronize the MSS information of the MSDB to the shared memory outside the MSDB; in fact, the synchronization unit can maintain the shared memory in the MSCS, and store the synchronized MSS information in the shared memory.
  • the redirecting decision unit may determine the available MSS according to the MSS information in the shared memory, and feed back the available link address of the available MSS to the UE.
  • the synchronization unit when synchronizing the MSS information, can send a data synchronization request to the MSDB, trigger the MSDB to feed back the requested data according to the data synchronization request, and save the data fed back by the MSDB to the created shared memory.
  • the redirection decision unit when determining the MSS available to the UE, can receive a redirection request initiated by the UE requiring redirection, and obtain a request type and a content ID by parsing the service field in the request, and obtain a complete from the shared memory.
  • the synchronization unit can perform an operation of creating an index, and the redirect decision unit can utilize the created index; and the redirect decision unit can also notify the UE of the available MSS, and trigger the UE to perform heavy on the notified available MSS. Orientation.
  • the redirection request can be processed faster, and the user experience is greatly improved.
  • the data in the shared memory can still be used to continue to provide the redirection service, which greatly provides the reliability of the system.
  • the MSCS When receiving the MSS redirect request, the MSCS does not query the database, but queries the node resource information stored in the shared memory to obtain the serviceable MSS address data, and the query speed is greatly improved;
  • MSCS can still rely on shared memory even if the database cannot provide services. Data to provide services;

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种实现重定向的方法和系统，均可将业务数据库的媒体业务服务器信息同步到业务数据库以外的共享内存中；用户终端设备需要重定向时，根据共享内存中的媒体业务服务器信息确定用户终端设备可用的媒体业务服务器。本发明实现重定向的方法和系统，可有效避免因数据库的问题而导致用户请求的失败，因而能明显提高用户满意度。

Description

一种实现重定向的方法和系统 技术领域
本发明涉及通信领域， 具体涉及一种实现重定向的方法和系统。 背景技术
随着 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, Real Time Streaming Protocol )月良务请求； 同时还用于在本业务服务器无法提供服务的情况下向 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、 TVOD, 频道的内容 ID等）为关键字来创建 HASH 索引， 将 HASH索引保存到本进程堆内存中。
步骤 204: MSCS定时向 MSDB发送增量同步请求， 请求中包含最后 一次增量或全量同步成功的时间戳。 步骤 205: MSDB将所述时间戳之后更新的数据通过增量同步应答反馈 给 MSCS, MSCS应用 MSDB所反馈的增量数据 (主要包括 VOD、 TVOD、 频道表的增量数据） 更新共享内存中的数据， 同时还可以根据更新后的数 据更新堆内存中的索引。
步骤 206: UE向 MSS A发起 RTSP服务请求。
步骤 207: MSS A收到 RTSP服务请求后，确定自身暂时无法提供服务， 则向 MSCS发起节点间的重定向请求。
步骤 208: MSCS收到 MSS A的重定向请求后， 通过解析该请求中的 服务字段以获取请求类型 （VOD、 TVOD、 频道）和内容 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 只需对共享内存中的数据进行重建索引操作， 即可继续提 供服务。
以上优点均可有效避免因数据库的问题而导致用户请求的失败， 因而 能明显提高用户满意度。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围， 凡在本发明的精神和原则之内所作的任何修改、 等同替换和改进 等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种实现重定向的方法， 其特征在于， 所述方法包括：
将业务数据库 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 进行重定向。
PCT/CN2011/076056 2010-06-28 2011-06-21 一种实现重定向的方法和系统 WO2012000398A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010210998A CN101867526A (zh) 2010-06-28 2010-06-28 一种实现重定向的方法和系统
CN201010210998.X 2010-06-28

Publications (1)

Publication Number Publication Date
WO2012000398A1 true WO2012000398A1 (zh) 2012-01-05

Family

ID=42959095

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/076056 WO2012000398A1 (zh) 2010-06-28 2011-06-21 一种实现重定向的方法和系统

Country Status (2)

Country Link
CN (1) CN101867526A (zh)
WO (1) WO2012000398A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101867526A (zh) * 2010-06-28 2010-10-20 中兴通讯股份有限公司 一种实现重定向的方法和系统
CN102355600B (zh) * 2011-07-20 2017-02-15 中兴通讯股份有限公司 一种媒体重定向系统和方法
CN103856541B (zh) * 2012-12-06 2017-10-10 华为技术有限公司 重定向页面显示方法、网关及用户设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101119475A (zh) * 2007-08-21 2008-02-06 中兴通讯股份有限公司 实现iptv系统中视频点播请求重定向的系统和方法
CN101355522A (zh) * 2008-09-18 2009-01-28 中兴通讯股份有限公司 一种媒体服务器的控制方法和系统
CN101645928A (zh) * 2009-08-26 2010-02-10 成都市华为赛门铁克科技有限公司 内容资源缓存方法、装置及系统
CN101867526A (zh) * 2010-06-28 2010-10-20 中兴通讯股份有限公司 一种实现重定向的方法和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1426003A (zh) * 2001-12-20 2003-06-25 深圳市中兴通讯股份有限公司 在关系数据库中获取数据最小变动集的处理方法
CN101127915B (zh) * 2007-09-20 2011-04-20 中兴通讯股份有限公司 一种基于增量式的电子节目导航数据同步方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101119475A (zh) * 2007-08-21 2008-02-06 中兴通讯股份有限公司 实现iptv系统中视频点播请求重定向的系统和方法
CN101355522A (zh) * 2008-09-18 2009-01-28 中兴通讯股份有限公司 一种媒体服务器的控制方法和系统
CN101645928A (zh) * 2009-08-26 2010-02-10 成都市华为赛门铁克科技有限公司 内容资源缓存方法、装置及系统
CN101867526A (zh) * 2010-06-28 2010-10-20 中兴通讯股份有限公司 一种实现重定向的方法和系统

Also Published As

Publication number Publication date
CN101867526A (zh) 2010-10-20

Similar Documents

Publication Publication Date Title
JP6382454B2 (ja) 分散ストレージ及びレプリケーションシステム、並びに方法
US9684453B2 (en) Cluster federation and trust in a cloud environment
US9659078B2 (en) System and method for supporting failover during synchronization between clusters in a distributed data grid
EP2434758B1 (en) Distributed node video monitoring system and management method thereof
US10069942B2 (en) Method and apparatus for changing configurations
WO2013075578A1 (zh) 网络资源文件的离线下载系统和方法
US10691820B1 (en) Real-time distribution of messages via a network with multi-region replication in a hosted service environment
WO2015090243A1 (zh) Ip管理方法、客户端以及服务器
US11076181B2 (en) Systems and methods for resolving manifest file discontinuities
CN107623703B (zh) 全局事务标识gtid的同步方法、装置及系统
US9596313B2 (en) Method, terminal, cache server and system for updating webpage data
EP3059932B1 (en) Lock server malfunction processing method and system thereof in distribution system
US20070255823A1 (en) Method for low-overhead message tracking in a distributed messaging system
US8103631B2 (en) Merging files on storage and retrieve
CN111050188B (zh) 一种数据流调度方法、系统、设备及介质
WO2009143738A1 (zh) 一种分布式网络的管理方法、内容查询方法、系统及装置
EP3868071B1 (en) Distributed state recovery in a system having dynamic reconfiguration of participating nodes
WO2012000398A1 (zh) 一种实现重定向的方法和系统
EP4075815A1 (en) Epg data management method, server, and readable storage medium
US11108730B2 (en) Group heartbeat information in a domain name system server text record
WO2014177058A1 (zh) 文件数据的传输方法及装置
CN110109871A (zh) 一种跨站点的高能物理数据访问方法及系统
JP2013171483A (ja) 差分レプリケーションシステム、マスターデータベース装置、及びスレーブデータベース装置
JP5449471B2 (ja) 共有データに対する更新処理の同期処理方法、データ共有システムおよびデータ共有プログラム
US9195500B1 (en) Methods for seamless storage importing and devices thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11800143

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11800143

Country of ref document: EP

Kind code of ref document: A1