[發明專利]在分布式數據庫架構中維護會話-主機關系的容錯方法有效
| 申請號: | 201110020100.7 | 申請日: | 2011-01-06 |
| 公開(公告)號: | CN102591886A | 公開(公告)日: | 2012-07-18 |
| 發明(設計)人: | R·沙瑪;胡明 | 申請(專利權)人: | 阿爾卡特朗訊 |
| 主分類號: | G06F17/30 | 分類號: | G06F17/30 |
| 代理公司: | 北京市金杜律師事務所 11256 | 代理人: | 鄭立柱 |
| 地址: | 法國*** | 國省代碼: | 法國;FR |
| 權利要求書: | 查看更多 | 說明書: | 查看更多 |
| 摘要: | |||
| 搜索關鍵詞: | 分布式 數據庫 架構 維護 會話 主機 關系 容錯 方法 | ||
技術領域
本發明涉及數據庫技術,特別涉及分布式的數據庫技術。
背景技術
在使用計費收集功能(Charging?Collection?Function,簡稱CCF)的IP多媒體系統網絡中,計費數據記錄(CDR)的互相關聯是這樣一種功能:它接合了來自各個網元(NE)的要素CDR,這些網元實現了計費觸發功能。在一個分布式數據庫架構(DDB)中,關聯的主機典型地是一個CCF節點,它會被選中從而將負載均衡地分散到CCF節點中。DDB方式具有這樣的優點:與傳統的、受讀寫TPS一般處于1000讀/寫每秒的數量級的商用服務器的讀寫TPS限制的集中式數據庫方式相比,系統地吞吐隨著CCF的加入線性地變化。
盡管DDB方式在CCF節點中提供了公平的負載分布,并且增加了系統吞吐,但是下面這些相關的問題使得DDB方式還不夠優化:
-關聯主機可能無法提供服務(out?of?service,簡稱OOS),并繼而阻止了關聯的完成;
-當一個或多個CCF節點被加入時,正在進行的會話已經要求重新歸屬以分散處理負載,由于這一階段的特征是大量的數據從一個數據庫到另一個數據庫的轉移,該轉移牽涉到多個源以及目的,這些源和目的最終消耗了很大百分比的CPU周期進行轉移,因此在這一階段中系統的吞吐會降低。而如果不進行重新歸屬,CCF節點會不正確地計算關聯主機,并且不同的CCF節點會將屬于相同會話的記錄導向至不同的關聯主機,這意味著關聯功能:
(a)對于相同的會話被執行超過一次,以及
(b)所有的服務器都使用不完整的會話信息進行工作,這帶有很大幾率使所有相關聯的紀錄都是不完整的并且在計費協調系統處不被接受。
因此,這種用于處于服務器停運和服務器加入的下雨天場景需要手工來正確地重新計算關聯主機以及調整負載分布。
在現有技術中,已經提出了一種解決方案克服以上問題,下面將結合圖1至3給予說明
·現有技術:當關聯主機無法提供服務
一個關聯主機根據f(Key)被選中,其中,該key典型的是被分配給被記賬的會話的IMS計費標識(ICID),并且該key被多個作為計費觸發功能(CTF)的網元所報告,其中該ICID被保證為在網絡中對于一段時間內,例如一個月內唯一。被使用在ICID上的函數是一個哈希函數,并且該結果確定關聯主機。該方法確保:屬于同一關聯對象的記賬記錄被發送給單個關聯主機,并且平均來說每個CCF節點接納了大致相同數量的處理負載。在實踐中,一個關聯對象可以具有多于一個正在進行的、由CTF所報告的記賬會話。
作為一個例子,考慮具有3個CCF節點:CCF節點1至CCF節點3(下面簡稱為CCF1至CCF3)的網絡。假定目前CCF2無法提供服務。對于一些正在進行會話,CCF1和CCF3能夠通過對該些會話相應的ICID施加f(Key)來了解到關聯主機是CCF2。由于CCF1和CCF3無法與CCF2通信,例如計費相關信息等新的會話記錄會被插入到這各個服務器的本地緩存中。當CCF2恢復后,CCF1和CCF3檢測到其可用性,繼而將這些被緩存的會話記錄發送給由CCF2擁有并且作為主機的數據庫中。
這一方式的問題在于:沒有辦法預先得知CCF2的停運將會持續多久。因此,本地緩存的解決方案只能在一定程度上起作用。在一段時間后,本地緩存將變得無法存儲記賬信息,繼而該解決方案失敗。當緩存充滿時,在這一時刻可以使用回滾機制產生不關聯的CDR,從而來清空緩存并且避免丟失記錄。這一方式相關的問題在于:很多用戶拒絕支付不關聯的CDR,這意味著這些呼叫或會話將無法被記賬,使用者也不會對它們被開具帳單。這產生了收入泄漏問題
·現有技術:當將一個或多個CCF節點加入到可用的服務器簇中
對于現有的網絡,當增加服務器時,復雜的一系列處理將被運行:這些處理首先設立該被加入的一個或多個服務器,暫停目前已有的服務器上的處理,更新各服務器的內部表格以添加被加入的一個或多個服務器的標記,在所更新的服務器數中重新歸屬正在進行的會話,之后繼續處理并恢復正常狀態。該處理的每個階段都具有精心設計的差錯處理進程,并且它還需要人工介入以解決下雨天場景。
作為這一方式的兩個主要缺點,以下這些點值得注意:
-與精心設計的差錯處理進程相關的復雜的一系列步驟需要操作員參照差錯日志并且基于失效點使用恢復機制;
-正常的處理被暫停,會話被重新歸屬以及耦合,這樣帶來的事實是:該過程的運行可能出現問題,處理暫停的時間對于網絡運營商來說可能無法接受;
該專利技術資料僅供研究查看技術是否侵權等信息,商用須獲得專利權人授權。該專利全部權利屬于阿爾卡特朗訊,未經阿爾卡特朗訊許可,擅自商用是侵權行為。如果您想購買此專利、獲得商業授權和技術合作,請聯系【客服】
本文鏈接:http://www.szxzyx.cn/pat/books/201110020100.7/2.html,轉載請聲明來源鉆瓜專利網。





