專利名稱：一種冗余容錯方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明屬于數(shù)字通訊領(lǐng)域，尤其涉及一種冗余容錯方法及系統(tǒng)。
背景技術(shù)：
在現(xiàn)有的點播系統(tǒng)中，機頂盒向控制中心(Control Center, CC)發(fā)送請求， 控制中心接收到請求后，向視頻服務(wù)器(Video Servers, VS)發(fā)送相應(yīng)的請求 并帶上機頂盒(SetTopBox， STB)信息，在現(xiàn)有技術(shù)中，第一次接收到機頂 盒的請求后，控制中心需要為會話分配資源，包括視頻服務(wù)器、調(diào)制調(diào)解器等； 視頻服務(wù)器收到請求后給控制中心回應(yīng)，控制中心判斷回應(yīng)正常則給機頂盒回 應(yīng)；機頂盒判斷回應(yīng)正常則繼續(xù)下一步動作；其中，若視頻服務(wù)器或控制中心 的任一回應(yīng)格式不正確或超時，會話過程就會結(jié)束，機頂盒請求服務(wù)不成功。 當會話正常時，控制中心會給機頂盒分配資源，資源主要是指調(diào)制調(diào)解器。視 頻服務(wù)器將用戶所請求的節(jié)目以傳輸流(Transport Streams, TS )的形式推流到 調(diào)制調(diào)解器，調(diào)制調(diào)解器將傳輸流傳到光纖電纜同軸網(wǎng)(Hybrid Fiber Coax, HFC)，然后通過HFC到達機頂盒用戶，這樣，用戶就得到了所請求的服務(wù)。
通常在前端系統(tǒng)部分出現(xiàn)崩潰后，仍然能夠為新的用戶請求才是供服務(wù)，需 要在控制中心和視頻服務(wù)器等處做冗余部署，這種部署采用冷備份，當控制中 心或視頻服務(wù)器崩潰時，當前正在進行的會話信息就會丟失，用戶請求的服務(wù) 就會中斷?，F(xiàn)有點播系統(tǒng)中的冗余部署，并不對當前會話進行容錯，這種方式 只能保證新用戶的請求能得到正確的響應(yīng)以獲得服務(wù)，而不保證老用戶的服務(wù) 不被中斷，給用戶帶來許多不便，容錯機制并不完善。

發(fā)明內(nèi)容
本發(fā)明實施例的目的在于提供一種冗余容錯方法，旨在解決現(xiàn)有技術(shù)中點 播系統(tǒng)中的會話崩潰時的容錯機制不完善的問題。
本發(fā)明實施例是這樣實現(xiàn)的， 一種冗余容錯方法，所迷方法包括下述步驟
當容錯端出現(xiàn)異常時，向所述容錯端發(fā)送會話重置請求信息；
接收容^t普端回應(yīng)信息，開始或者續(xù)接服務(wù)會話。
本發(fā)明實施例的另一目的在于提供一種冗余容錯系統(tǒng)，所述系統(tǒng)包括
容錯端異常判斷單元，用于判斷容錯端是否出現(xiàn)異常；
信息發(fā)送單元，用于當容錯端出現(xiàn)異常時，向所述容錯端發(fā)送會話重置請 求信息；以及
容錯端信息回應(yīng)接收單元，用于接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù) M。
在本發(fā)明實施例中，對當前點播系統(tǒng)中斷的會話采用容錯處理，在用戶可 感知的時間內(nèi)繼續(xù)提供服務(wù)，提高了服務(wù)的連續(xù)性、可用性。


圖l是本發(fā)明實施例提供的冗余容錯方法流程圖2是本發(fā)明實施例提供的控制中心采用非集群式集中部署的容錯處理流 程圖3是本發(fā)明實施例提供的控制中心采用集群部署的容錯處理流程圖4是本發(fā)明實施例提供的視頻服務(wù)器的容錯處理流程圖5是本發(fā)明實施例提供的冗余容錯系統(tǒng)的結(jié)構(gòu)圖6是本發(fā)明實施例提供的冗余容錯系統(tǒng)的結(jié)構(gòu)圖。
具體實施例方式
為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實 施例，對本發(fā)明進行進一步詳細說明。應(yīng)當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
在本發(fā)明實施例中，對當前點播系統(tǒng)中中斷的會話采用容錯處理，在用戶 可感知的時間內(nèi)繼續(xù)提供服務(wù)，提高了服務(wù)的連續(xù)性、可用性。
圖1示出了本發(fā)明實施例提供的冗余容錯方法流程圖，其詳細步驟如下
在步驟S101中，判斷容錯端是否出現(xiàn)異常，是則執(zhí)行步驟S103，否則執(zhí) 行步驟S102;
在本發(fā)明實施例中，上述容錯端包括控制中心以及視頻服務(wù)器。該容錯端 出現(xiàn)異常包括對客戶端的服務(wù)請求回應(yīng)不正常以及在對客戶端服務(wù)過程中容錯 端崩潰。
在步驟S102中，客戶端繼續(xù)下一步請求或者得到服務(wù)結(jié)束交互； 在步驟S103中，當容錯端回應(yīng)不正常時，向所述容錯端發(fā)送會話重置 (RESETUP)請求信息；
在本發(fā)明實施例中，容錯端回應(yīng)不正常包括容錯端的回應(yīng)才各式不正確以及 超時。當容錯端為控制中心時，步驟S103中的會話重置請求信息包括會話標識 信息；當容錯端為視頻服務(wù)器時，該會話重置請求信息還包括資源信息以及服 務(wù)斷點信息。
在步驟S104中，接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù)會話，或者返回 步驟S102,進行判斷。
作為本發(fā)明的一個實施例，當當前的會話服務(wù)出現(xiàn)不正常，當前容錯端出 現(xiàn)崩潰時，客戶端也要向容錯端發(fā)送會話重置請求信息，請求中斷的會話繼續(xù)， 其步驟如上述，不再贅述。
在本發(fā)明實施例中，作為容錯處理的前序步驟冗余部署包括以下幾個方面
l控制中心冗余部署
1.1控制中心提供資源的統(tǒng)一管理，主要負責流服務(wù)時的帶寬預(yù)留和回收， 流服務(wù)負載的全局和局部均衡，就是將用戶訪問導向到恰當?shù)牧鞣?wù)器以及不 同流服務(wù)器的協(xié)議適配，通常指RTSP訪問代理。
1.2控制中心集中部署?？刂浦行挠袃煞N部署方法，既可以采用集群部署(是 集中部署的一種方式)，也可以采用非集群式集中部署。集群部署將多個控制 中心以集群的方式組織起來，對外它是一個整體，相當于只有一個控制中心，只要集群中還有一個控制中心可用，該集群就是有效的；非集群式集中部署是 將多個控制中心在空間上部署在一起，各自擁有不同的訪問地址。
兩種部署的相同點是有多個控制中心，它們處于對等地位；兩種部署的不 同點是集群部署對外表現(xiàn)為只有一個IP地址，而非集群式集中部署表現(xiàn)為多 個IP地址，此時機頂盒采用多代理機制來模擬集群訪問。
1.3對控制中心的資源和會話管理進行持久化設(shè)計，使得任何一個控制中心 的崩潰都不會導致會話信息的丟失和資源管理的混亂，任何一個控制中心均能 隨時獲知任何一個會話的信息包括會話所占用的資源情況。
2. 視頻服務(wù)器冗余部署
2.1中心視頻服務(wù)器可以作為邊緣視頻服務(wù)器的冗余，邊緣的調(diào)制調(diào)解器可 以在城域網(wǎng)上進行交換。
2.2直接在較大的邊緣視頻服務(wù)器內(nèi)部做冗余。
視頻服務(wù)器必須定期向控制中心發(fā)?；畎?，以證明自己服務(wù)正常。當控制 中心一段時間沒有收到?；畎?，就認為視頻服務(wù)器崩潰，啟動容錯處理。
3. 客戶端
在本發(fā)明實施例中，當容錯端為視頻服務(wù)器時，對應(yīng)的客戶端應(yīng)該為控制 中心，當容錯端為控制中心時，對應(yīng)的客戶端為機頂盒。
3.1當控制中心采用非集群式集中部署時，客戶端需要采用多代理機制。多 代理機制的作用是屏蔽多個非集群式集中部署的控制中心的地址，而對客戶端 表現(xiàn)為一個地址。當客戶端向這個地址發(fā)送請求時，多代理機制自動在屏蔽的 多個控制中心中選取一個可用控制中心來響應(yīng)請求。當響應(yīng)不正確或超時時， 多代理機制還有容錯處理。
3.2當控制中心采用集群部署的時候，客戶端不需要采用多代理機制，只需普通部署即可，容錯處理將由集群來完成。
3.3客戶端必須隨時清楚服務(wù)斷點以及用戶會話服務(wù)的標識(Identification, ID)，以便在中斷發(fā)生時提供斷點信息給前端。
作為本發(fā)明的一個實施例，圖2示出了本發(fā)明實施例提供的控制中心采用 非集群式集中部署的容錯處理流程，此時容錯端為控制中心，其詳細步驟如下
在步驟S201中，客戶端機頂盒通過多代理機制向控制中心發(fā)送服務(wù)請求；
在本發(fā)明實施例中，根據(jù)上述冗余部署，當控制中心采用非集群式集中部 署時，客戶端機頂盒需要采用多代理機制。客戶端機頂盒通過多代理機制從集 中部署的多個控制中心中隨機選取一個可用的控制中心向控制中心發(fā)送服務(wù)請 求。
在步驟S202中，判斷控制中心的回應(yīng)是否正常，是則執(zhí)行步驟S203，否則執(zhí)行步驟S204;
在步驟S203中，客戶端繼續(xù)下一步請求或者得到服務(wù)結(jié)束交互； 在步驟S204中，在集中部署剩余的可用的控制中心中選取一個控制中心； 在本發(fā)明實施例中，多代理機制將響應(yīng)不正確或超時的控制中心標識為不可用，在剩余可用的控制中心中選取一個。其中，在經(jīng)歷一段時間之后，多代理機制將標識為不可用的控制中心置為可用狀態(tài)，不管是否可用，以免長時間閑置。
在步驟S205中，機頂盒通過多代理機制向根據(jù)上述步驟S204中選取的可 用的控制中心發(fā)送會話重置請求信息；
在本發(fā)明實施例中，上述會話重置請求信息包括會話標識信息，當控制中 心給機頂盒分配資源時，會將會話的資源信息寫入數(shù)據(jù)庫，當重連會話時，控 制中心根據(jù)會話標識可以查詢到分配給該會話的資源，不需要用戶在重置請求 中攜帶資源信息，也不需要重新分配資源。
在步驟S206中，機頂盒得到控制中心的回應(yīng)，開始或者續(xù)接服務(wù)會話，或 者返回步驟S202，進行判斷。
在本發(fā)明實施例中，當控制中心崩潰時，視頻服務(wù)器向機頂盒的推流并沒 有中斷，只要機頂盒在一定時間內(nèi)發(fā)送會話重置請求，視頻服務(wù)器提供的服務(wù)就不會間斷；當機頂盒沒有在規(guī)定時間內(nèi)發(fā)送會話重置的請求，視頻服務(wù)器的服務(wù)才會中斷，會話信息也會丟失，這樣的會話重置保證了用戶接收的服務(wù)的 連續(xù)性。
作為本發(fā)明的另一個實施例，圖3示出了本發(fā)明實施例提供的控制中心采 用集群部署的容錯處理流程，此時容錯端為控制中心，其詳細步驟如下
在步驟S301中，客戶端機頂盒向控制中心發(fā)送服務(wù)請求；
在步驟S302中，判斷控制中心的回應(yīng)是否正常，是則執(zhí)行步驟S303，否 則執(zhí)行步驟S304;
在步驟S303中，客戶端機頂盒繼續(xù)下一步請求或者得到服務(wù)結(jié)束交互；
在步驟S304中，機頂盒向控制中心發(fā)送會話重置請求信息；
在本發(fā)明實施例中，該會話重置請求信息包括會話標識，當控制中心部署中有一個控制中心崩潰后，其他控制中心處于可用狀態(tài)。當客戶端機頂盒發(fā)送會話重置請求信息到控制中心部署時，控制中心部署的其它控制中心接收該會話重置請求信息，繼續(xù)為客戶端服務(wù)。
在步驟S305中，機頂盒得到控制中心的回應(yīng)，開始或者續(xù)接服務(wù)會話，或者返回步驟S302，進行判斷。
作為本發(fā)明的一個實施例，當當前的會話服務(wù)出現(xiàn)異常，控制中心對當前
的服務(wù)回應(yīng)不正常，某個控制中心出現(xiàn)崩潰時，機頂盒要向控制中心發(fā)送^S舌
重置請求信息，請求繼續(xù)中斷的會話，其詳細步驟如上述兩個實施例所述，不
再贅述。
作為本發(fā)明的另一個實施例，圖4示出了本發(fā)明實施例提供的視頻服務(wù)器 的容錯處理流程，此時容錯端為視頻服務(wù)器，其詳細步驟如下 在步驟S401中，控制中心向視頻服務(wù)器發(fā)送服務(wù)請求； 在步驟S402中，判斷視頻服務(wù)器的回應(yīng)是否正常，是則執(zhí)行步驟S403,否則執(zhí)行步驟S404;
在步驟S403中，控制中心繼續(xù)下一步請求或者得到服務(wù)結(jié)束交互；
在步驟S404中，控制中心選取一個可用的視頻服務(wù)器；
在步驟S405中，控制中心向可用的視頻服務(wù)器發(fā)送會話重置請求信息；
在本發(fā)明實施例中，當視頻服務(wù)器崩潰時，-阮頻服務(wù)器向機頂盒的推流會中斷，步驟S405中的會話重置請求信息除包括會話標識信息，還需要包括資源信息以及服務(wù)斷點信息，以便視頻服務(wù)器清晰為客戶端提供服務(wù)的資源及斷點。
在步驟S406中，控制中心得到視頻服務(wù)器的回應(yīng)，開始或者續(xù)接服務(wù)會話，或者返回步驟S402，進行判斷。
作為本發(fā)明的一個實施例，當當前的會話服務(wù)出現(xiàn)不正常，視頻服務(wù)器對當前的服務(wù)回應(yīng)不正常，某個視頻服務(wù)器出現(xiàn)崩潰時，控制中心向視頻服務(wù)器發(fā)送會話重置請求信息，請求繼續(xù)中斷的會話，其詳細步驟如上述實施例所屬，不再贅述。
在本發(fā)明實施例中，對非正常中止視頻服務(wù)器崩潰時的會話進行重置，可 利用服務(wù)斷點對用戶提供續(xù)傳服務(wù)。
圖5示出了本發(fā)明實施例提供的冗余容錯系統(tǒng)的結(jié)構(gòu)，為了便于說明，僅 示出與本發(fā)明實施例相關(guān)的部分。
容錯端異常判斷單元11判斷容錯端是否出現(xiàn)異常，該容錯端出現(xiàn)異常包括 對客戶端的服務(wù)請求回應(yīng)不正常以及在對客戶端服務(wù)過程中出現(xiàn)崩潰，當容錯 端出現(xiàn)異常時，信息發(fā)送單元12向上述容錯端發(fā)送會話重置請求信息；當容錯 端為控制中心且該控制中心采用非集群式集中部署時，客戶端機頂盒的信息發(fā) 送單元通過多代理機制向選取的可用的控制中心發(fā)送會話重置請求信息，此時 會話重置請求信息包括會話標識信息。當容4普端正常時，客戶端繼續(xù)下一步請 求或者得到服務(wù)結(jié)束交互。
容錯端信息回應(yīng)接收單元13接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù)會話。
在本發(fā)明實施例中，圖6示出了本發(fā)明實施例提供的冗余容錯系統(tǒng)的結(jié)構(gòu)，當容錯端出現(xiàn)異常時，且當容^l晉端為控制中心且所述的控制中心的部署為非集 群式集中部署或者當容錯端為視頻服務(wù)器時，該冗余容錯系統(tǒng)還包括容錯端重新選擇單元21重新選擇一個可用的控制中心或者視頻服務(wù)器，其它結(jié)構(gòu)描述如 上述，此不再贅述。
在本發(fā)明實施例中，通過對非正常中止的會話進行重連，用戶得到享受到 不間斷的服務(wù)，提高了服務(wù)的連續(xù)性、可用性。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā) 明的精神和原則之內(nèi)所作的任何修改、等同替換和改進等，均應(yīng)包含在本發(fā)明 的保護范圍之內(nèi)。
權(quán)利要求
1、一種冗余容錯方法，其特征在于，所述方法包括下述步驟當容錯端出現(xiàn)異常時，向所述容錯端發(fā)送會話重置請求信息；接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù)會話。
2、 如權(quán)利要求1所述的冗余容錯方法，其特征在于，所述容錯端包括控制 中心或視頻服務(wù)器。
3、 如權(quán)利要求2所述的冗余容錯方法，其特征在于，當所述容錯端為控制 中心時，所述的控制中心的部署包括非集群式集中部署以及集群部署。
4、 如權(quán)利要求2或3所述的冗余容錯方法，其特征在于，當容錯端為控制 中心且所述的控制中心的部署為非集群式集中部署或者當容錯端為視頻服務(wù)器 時，所述方法還包括下述步驟重新選擇一個可用的容錯端。
5、 如權(quán)利要求1或2所述的冗余容錯方法，其特征在于，所述的會話重置 請求信息包括會話標識信息；當所述容錯端為視頻服務(wù)器時，所述的會話重置請求信息還包括資源信息 以及服務(wù)斷點信息。
6、 一種冗余容錯系統(tǒng)，其特征在于，所述系統(tǒng)包括 容錯端異常判斷單元，用于判斷容錯端是否出現(xiàn)異常； 信息發(fā)送單元，用于當容錯端出現(xiàn)異常時，向所述容錯端發(fā)送會話重置請求信息；以及容錯端信息回應(yīng)接收單元，用于接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù) 會話。
7、 如權(quán)利要求6所述的冗余容錯系統(tǒng)，其特征在于，所述容錯端包括控制 中心或視頻服務(wù)器。
8、 如權(quán)利要求7所述的冗余容錯系統(tǒng)，其特征在于，當所述容錯端為控制 中心時，所述的控制中心的部署包括非集群式集中部署以及集群部署。
9、 如權(quán)利要求6所述的冗余容錯系統(tǒng)，其特征在于，所述系統(tǒng)還包括 容錯端重新選擇單元，用于當容錯端出現(xiàn)異常時，重新選擇一個可用的容錯端。
10、 如權(quán)利要求6或7所述的冗余容錯系統(tǒng)，其特征在于，所述的會話重 置請求信息包括會話標識信息；當所述容錯端為視頻服務(wù)器時，所述的會話重置請求信息還包括資源信息 以及服務(wù)斷點信息。
全文摘要
本發(fā)明適用于數(shù)字通訊領(lǐng)域，提供了一種冗余容錯的方法及系統(tǒng)，所述方法包括下述步驟當容錯端出現(xiàn)異常時，向所述容錯端發(fā)送會話重置請求信息；接收容錯端回應(yīng)信息，開始或者續(xù)接服務(wù)會話。在本發(fā)明實施例中，對當前點播系統(tǒng)中中斷的會話采用容錯處理，在用戶可感知的時間內(nèi)繼續(xù)提供服務(wù)，提高了服務(wù)的連續(xù)性、可用性。
文檔編號H04N7/64GK101202924SQ20071007507
公開日2008年6月18日 申請日期2007年6月18日 優(yōu)先權(quán)日2007年6月18日
發(fā)明者洪家明 申請人:深圳市同洲電子股份有限公司