專利名稱：一種清單查詢系統(tǒng)、裝置和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通訊的業(yè)務(wù)支撐領(lǐng)域，更具體的，本發(fā)明涉及一種清單查詢系統(tǒng)、 裝置和方法。
背景技術(shù)：
清單查詢是電信運營商為用戶提供的一種服務(wù)。用戶通過通信工具(比如移動終 端、固定電話、無線網(wǎng)卡等)使用運營商提供的服務(wù)，產(chǎn)生了詳細清單(⑶R)。用戶可以通過 自助打印、網(wǎng)上營業(yè)廳、無線應(yīng)用協(xié)議(WAP)等方式查詢自己使用服務(wù)的詳細情況以及由 此產(chǎn)生的費用。清單查詢可以給用戶帶來很大的便利。傳統(tǒng)的清單是一般存儲在數(shù)據(jù)庫中，用戶通過各種渠道向數(shù)據(jù)庫提交查詢請求， 比如由中間件服務(wù)器(比如tUxedo、CICS、TongEASY等)向數(shù)據(jù)庫發(fā)送查詢請求，然后把 數(shù)據(jù)庫返回的查詢結(jié)果返回給用戶。然而，如果數(shù)據(jù)庫或存儲設(shè)備發(fā)生故障，則中間件服務(wù)器無法獲得清單信息，也就 無法為用戶提供清單查詢服務(wù)。而且，在現(xiàn)有的清單查詢系統(tǒng)中，并沒有實現(xiàn)清單信息的生 命周期管理，同樣也沒有實現(xiàn)按客戶優(yōu)先級的差異化查詢清單。

發(fā)明內(nèi)容
本發(fā)明實施方式提出一種清單查詢系統(tǒng)，以在數(shù)據(jù)庫或存儲設(shè)備發(fā)生故障時也能 查詢清單數(shù)據(jù)。本發(fā)明實施方式提出一種清單查詢裝置，以在數(shù)據(jù)庫或存儲設(shè)備發(fā)生故障時也能 查詢清單數(shù)據(jù)。本發(fā)明實施方式提出一種清單查詢方法，以在數(shù)據(jù)庫或存儲設(shè)備發(fā)生故障時也能 查詢清單數(shù)據(jù)本發(fā)明實施方式的技術(shù)方案如下一種清單查詢系統(tǒng)，該系統(tǒng)包括實時數(shù)據(jù)庫、文件清單查詢單元和查詢路由引擎 單元，其中實時數(shù)據(jù)庫，用于保存實時清單數(shù)據(jù)；文件清單查詢單元，用于保存歷史清單數(shù)據(jù)及其索引信息；查詢路由引擎單元，用于根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單 數(shù)據(jù)，還是基于所述索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。一種清單查詢裝置，包括查詢請求接收單元、路由判定單元和地址信息單元，其 中所述查詢請求接收單元，用于從查詢請求方接收查詢請求；所述路由判定單元，用于根據(jù)所述查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù) 據(jù)，還是基于保存在文件清單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史 清單數(shù)據(jù)；
地址信息返回單元，用于基于由所述路由判定單元判定的清單數(shù)據(jù)獲取方式，向 查詢請求方返回實時數(shù)據(jù)庫和/或文件清單查詢單元的地址信息一種清單查詢方法，該方法包括發(fā)送清單查詢請求；根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基于保存在文 件清單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。從上述技術(shù)方案可以看出，在本發(fā)明實施方式的系統(tǒng)中，文件清單查詢單元保存 歷史清單數(shù)據(jù)及其索引信息，實時數(shù)據(jù)庫保存實時清單數(shù)據(jù)，查詢路由引擎單元接收的查 詢請求確定是從實時數(shù)據(jù)庫或文件清單查詢單元中獲取清單數(shù)據(jù)。由此可見，由于索引信 息是保存在文件清單查詢單元中，當(dāng)實時數(shù)據(jù)庫或別的數(shù)據(jù)庫發(fā)生故障時，并不影響文件 清單查詢單元的清單數(shù)據(jù)查詢操作。而且，程序編程接口(API)接口單元，可以將各種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格 式的查詢請求，利用統(tǒng)一接口提供了標(biāo)準的API接口，從而為用戶提供了便利。另外，通過 對實時清單數(shù)據(jù)、歷史清單數(shù)據(jù)、容災(zāi)數(shù)據(jù)等進行劃分處理，本發(fā)明實施方式還實現(xiàn)了信息 的生命周期管理，而且可以按照客戶優(yōu)先級的不同進行差異化查詢。


圖1為根據(jù)本發(fā)明實施方式的清單查詢系統(tǒng)結(jié)構(gòu)示意圖；圖2為根據(jù)本發(fā)明實施方式清單查詢裝置結(jié)構(gòu)示意圖；圖3為根據(jù)本發(fā)明實施方式的清單查詢方法流程示意圖；圖4為根據(jù)本發(fā)明實施方式，從網(wǎng)上營業(yè)廳發(fā)送查詢請求時的清單查詢方法流程 示意圖。
具體實施例方式為使本發(fā)明的目的、技術(shù)方案和優(yōu)點表達得更加清楚明白，下面結(jié)合附圖及具體 實施方式對本發(fā)明再作進一步詳細的說明。圖1為根據(jù)本發(fā)明實施方式的清單查詢系統(tǒng)結(jié)構(gòu)示意圖。如圖1所示，該系統(tǒng)包括實時數(shù)據(jù)庫101、文件清單查詢單元102和查詢路由引擎 單元103，其中實時數(shù)據(jù)庫101，用于保存實時清單數(shù)據(jù)；文件清單查詢單元102，用于保存歷史清單數(shù)據(jù)及其索引信息；查詢路由引擎單元103，用于根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫101獲取 實時清單數(shù)據(jù)，還是基于索引信息從文件清單查詢單元102中獲取歷史清單數(shù)據(jù)。在一個優(yōu)選方式中，實時數(shù)據(jù)庫101中可以保存本月、本周或本天的實時清單數(shù) 據(jù)(未出賬)，而且在每月的月初、每周一、每天早上等時間段，實時數(shù)據(jù)庫101可以將上 個月或上周或昨天的歷史清單數(shù)據(jù)導(dǎo)出到文件清單查詢單元102中，由文件清單查詢單元 102予以保存。這樣，實時數(shù)據(jù)庫101的規(guī)?？梢员３州^小，性能比較穩(wěn)定而且查詢速度得 到提高。文件清單查詢單元102可以保存歷史清單數(shù)據(jù)(比如，上周、上一個月、上個季度、或者去年的清單數(shù)據(jù))。文件清單查詢單元102優(yōu)選保存是基于排序的、壓縮的文件，而且 其索引信息也是保存在文件清單查詢單元102上，在運行時索引信息全部加載到服務(wù)器內(nèi) 存中。比如，文件清單查詢單元102可以將歷史清單數(shù)據(jù)按信息的唯一 ID進行排序并壓縮， 并為每個壓縮過的數(shù)據(jù)建立索引，索引也保存在文件清單查詢單元102中。這樣，即使實時 數(shù)據(jù)庫101發(fā)生故障，也不影響查詢文件清單查詢單元102中的歷史清單數(shù)據(jù)。在一個實施方式中，文件清單查詢單元102還可以通過使用群集文件系統(tǒng)實現(xiàn)文 件的共享。而且，在正常情況下，文件清單查詢單元102可以按照特定的條件(如地區(qū)代 碼)指定查詢的服務(wù)器，當(dāng)這臺服務(wù)器發(fā)生故障時，通過預(yù)先設(shè)定的路由自動切換到其他 服務(wù)器查詢歷史清單數(shù)據(jù)，可以實現(xiàn)類似Oracle的RAC和FailOver功能。另外，文件清單查詢單元102中還可以提供基于socket的高效接口，各種高級語 言均可利用該高效接口與文件清單查詢單元102相連接，文件清單查詢單元102所保存的 數(shù)據(jù)優(yōu)選可以采用DES加密，信息請求方必須有相應(yīng)的密鑰才能獲得相關(guān)信息，從而可以 提高文件清單查詢單元102中保存的歷史清單數(shù)據(jù)的安全性。在一個實施方式中，查詢路由引擎單元103，用于從接收到的清單查詢請求中解析 出查詢時間信息，并根據(jù)查詢時間信息確定清單查詢請求為實時清單查詢請求或歷史清單 查詢請求，當(dāng)為實時清單查詢請求時從實時數(shù)據(jù)庫101獲取實時清單數(shù)據(jù)，當(dāng)為歷史清單 查詢請求時從文件清單查詢單元102中獲取歷史清單數(shù)據(jù)。查詢路由引擎單元103判定出 實時清單查詢請求或歷史清單查詢請求后，查詢路由引擎單元103可以直接從實時數(shù)據(jù)庫 101或文件清單查詢單元102中查詢相應(yīng)的清單數(shù)據(jù)，然后發(fā)送給查詢方?？蛇x地，查詢路 由引擎單元103判定出實時清單查詢請求或歷史清單查詢請求后，可以將實時數(shù)據(jù)庫101 或文件清單查詢單元102的IP地址、端口號等地址信息發(fā)送給查詢方，由查詢方根據(jù)所提 供的地址信息直接從實時數(shù)據(jù)庫101或文件清單查詢單元102中獲取相應(yīng)的清單數(shù)據(jù)。在具體實現(xiàn)中，實時數(shù)據(jù)庫101或文件清單查詢單元102都可能分別由多個服務(wù) 器構(gòu)成。路由引擎單元103可以通過存儲在路由表中的路由信息來確定具體從哪個服務(wù)器 查詢數(shù)據(jù)。路由表中還可以進一步設(shè)置路由策略，比如當(dāng)實時數(shù)據(jù)庫出現(xiàn)故障時，如果查詢 路由引擎單元103判定收到了實時清單數(shù)據(jù)請求，還可以轉(zhuǎn)到文件清單查詢單元102中查 詢歷史清單數(shù)據(jù)。而且，路由表可以存儲在實時數(shù)據(jù)庫101、文件清單查詢單元102或任意 第三方中。優(yōu)選的，該路由表可以保存在查詢路由引擎單元中，這樣，當(dāng)實時數(shù)據(jù)庫101或 文件清單查詢單元102不能提供服務(wù)時，路由引擎單元103也可以根據(jù)存儲在本地的路由 表確定具體從哪個服務(wù)器或哪個數(shù)據(jù)源來查詢數(shù)據(jù)。優(yōu)選的，該系統(tǒng)進一步包括容災(zāi)數(shù)據(jù)庫104，用于保存容災(zāi)清單數(shù)據(jù)。此時，查詢路 由引擎單元103，進一步用于在實時數(shù)據(jù)庫101和/或文件清單查詢單元102不可用時，從 容災(zāi)數(shù)據(jù)庫104中獲取容災(zāi)清單數(shù)據(jù)。該系統(tǒng)進一步包括應(yīng)用程序編程接口(API)接口單元105。API接口單元105， 用于接收至少一種類型的查詢請求，將至少一種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格式的查詢請 求，并發(fā)送到所述查詢路由引擎單元103?？梢姡珹PI接口單元105可以充當(dāng)用戶或應(yīng)用程序提交查詢請求的統(tǒng)一接口。這 樣，用戶或應(yīng)用程序無需知道清單以哪種格式、哪個服務(wù)器上，統(tǒng)一接口屏蔽了這些細節(jié)， 提供了標(biāo)準的API接口。
該系統(tǒng)還可以進一步包括備份數(shù)據(jù)源106，用于保存?zhèn)浞萸鍐螖?shù)據(jù)；此時，查詢路由引擎單元103，進一步用于檢查容災(zāi)數(shù)據(jù)庫104、實時數(shù)據(jù)庫101和 /或文件清單查詢單元102的狀態(tài)，并基于狀態(tài)檢查結(jié)果和預(yù)先設(shè)定的查詢策略從備份數(shù) 據(jù)源106中獲取備份清單數(shù)據(jù)。由于實時數(shù)據(jù)庫101和/或文件清單查詢單元102是一個大型的應(yīng)用服務(wù)器軟 件，數(shù)據(jù)規(guī)模的不斷擴大，查詢的頻度不斷升高，系統(tǒng)壓力不大增大，以及主機和存儲設(shè)備 的故障等，都有可能造成實時數(shù)據(jù)庫101和/或文件清單查詢單元102異常，并無法提供服 務(wù)，因此可以在系統(tǒng)中增加備份數(shù)據(jù)源106，從而提高查詢效率，降低了故障概率?；谏鲜龇治觯景l(fā)明實施方式還提出了 一種清單查詢裝置。圖2為根據(jù)本發(fā)明實施方式清單查詢裝置結(jié)構(gòu)示意圖。如圖2所示，該裝置包括查詢請求接收單元201、路由判定單元202和地址信息單 元203，其中查詢請求接收單元201，用于從查詢請求方接收查詢請求；路由判定單元202，用于根據(jù)所述查詢請求確定是從實時數(shù)據(jù)庫(圖2中沒有示 出)獲取實時清單數(shù)據(jù)，還是基于保存在文件清單查詢單元(圖2中沒有示出)中的索引 信息從文件清單查詢單元中獲取歷史清單數(shù)據(jù)；地址信息返回單元203，用于基于由路由判定單元202判定的清單數(shù)據(jù)獲取方式， 向查詢請求方返回實時數(shù)據(jù)庫和/或文件清單查詢單元的地址信息。該裝置還可以進一步包括優(yōu)先級確定單元204 ；優(yōu)先級確定單元204，用于確定查詢請求的優(yōu)先級，并向地址信息返回單元203發(fā) 送所述查詢請求的優(yōu)先級；地址信息返回單元203，用于基于路由判定單元202判定的清單 數(shù)據(jù)獲取方式，向查詢請求方返回實時數(shù)據(jù)庫和/或文件清單查詢單元的與查詢請求的優(yōu) 先級相對應(yīng)的地址信息。具體地，優(yōu)先級確定單元204收到查詢請求后，可以通過對查詢方 資料的分析，根據(jù)查詢方品牌、大客戶級別等信息確定查詢方的優(yōu)先級信息，并將優(yōu)先級信 息發(fā)送到地址信息返回單元203，然后地址信息返回單元203，再為不同優(yōu)先級的查詢方分 配不同的端口號和進程數(shù)等。優(yōu)選地，該清單查詢裝置進一步包括API接口單元(圖中沒有示出)。API接口單 元，用于接收至少一種類型的查詢請求，將至少一種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格式的查 詢請求，并發(fā)送到查詢請求接收單元201?；谏鲜龇治觯景l(fā)明實施方式還提出了一種清單查詢方法。圖3為根據(jù)本發(fā)明實施方式的清單查詢方法流程示意圖。如圖3所示，該方法包括步驟301 發(fā)送清單查詢請求。在這里，請求方可以從營業(yè)廳發(fā)送清單查詢請求、或從網(wǎng)上營業(yè)廳發(fā)送清單查詢 請求、或從WAP網(wǎng)絡(luò)發(fā)送清單查詢請求、或根據(jù)短信/彩信發(fā)送清單查詢請求。以上雖然羅列了一些常用的清單查詢請求發(fā)送方式，本領(lǐng)域技術(shù)人員可以意識 到，這些示范性舉例僅是闡述性的，并不用于限定本發(fā)明實施方式的范圍。步驟302 根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基 于保存在文件清單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。
其中，在清單查詢請求中可以包括查詢時間信息，查詢時間信息指明查詢的清單 數(shù)據(jù)時間段。這樣，查詢請求執(zhí)行方首先從清單查詢請求中解析出查詢時間信息，根據(jù)查詢時 間信息確定所述清單查詢請求為實時清單查詢請求或歷史清單查詢請求，當(dāng)為實時清單查 詢請求時從所述實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，當(dāng)為歷史清單查詢請求時從所述文件清單 查詢單元中獲取歷史清單數(shù)據(jù)。該方法可以進一步包括，當(dāng)查詢請求的類型為多種時，在接收到多種類型的查詢 請求后，將各種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格式的查詢請求。該方法可以進一步包括，當(dāng)判定實時數(shù)據(jù)庫和/或文件清單查詢單元不可用時， 從容災(zāi)數(shù)據(jù)庫中獲取容災(zāi)清單數(shù)據(jù)。而且定期檢查容災(zāi)數(shù)據(jù)庫、實時數(shù)據(jù)庫和/或文件清 單查詢單元的狀態(tài)，并基于狀態(tài)檢查結(jié)果和預(yù)先設(shè)定的查詢策略從備份數(shù)據(jù)源中獲取備份 清單數(shù)據(jù)。比如，可以在容災(zāi)數(shù)據(jù)庫、實時數(shù)據(jù)庫和文件清單查詢單元都不可用的時候，從 備份數(shù)據(jù)源中獲取備份清單數(shù)據(jù)。下面以從網(wǎng)上營業(yè)廳發(fā)送查詢請求為例，詳細說明清單查詢方法的流程。圖4為根據(jù)本發(fā)明實施方式，從網(wǎng)上營業(yè)廳發(fā)送查詢請求時的清單查詢方法流程 示意圖。如圖4所示，該方法包括步驟401 用戶A登錄網(wǎng)上營業(yè)廳(或自助打印、WAP等其他渠道)，發(fā)出查詢清單 的請求，提交短信到網(wǎng)上營業(yè)廳的WEB服務(wù)器；步驟402 =WEB服務(wù)器調(diào)用API接口單元，由API接口單元轉(zhuǎn)換為統(tǒng)一的查詢請求；步驟403 :API接口單元調(diào)用查詢路由引擎單元；步驟404 查詢路由引擎單元根據(jù)查詢請求中包括的查詢月份，確定數(shù)據(jù)源(比 如如果查詢實時清單數(shù)據(jù)從實時數(shù)據(jù)庫查詢，如果查詢歷史清單數(shù)據(jù)從文件清單查詢單 元中查詢)及其IP地址、端口號。在這里，查詢路由引擎單元可以定期檢索實時數(shù)據(jù)庫、文 件清單查詢單元的狀態(tài)，如果確定的數(shù)據(jù)源狀態(tài)不正常，則根據(jù)查詢策略可以轉(zhuǎn)而使用其 他數(shù)據(jù)源，具體包括1)當(dāng)查詢請求是查詢實時清單，并且實時數(shù)據(jù)庫不可用時，則使用容災(zāi)數(shù)據(jù)庫；2)當(dāng)查詢請求是查詢歷史清單數(shù)據(jù)，并且文件清單查詢單元不可用時，則使用容 災(zāi)庫。步驟405 如果查詢實時清單數(shù)據(jù)，則API接口單元調(diào)用數(shù)據(jù)庫查詢子模塊，從實 時數(shù)據(jù)庫中查詢數(shù)據(jù)庫記錄，獲得實時清單數(shù)據(jù)；步驟406 如果查詢歷史清單數(shù)據(jù)，則API接口單元調(diào)用文件查詢服務(wù)，從文件清 單查詢單元中查詢索引，獲得歷史清單數(shù)據(jù)；步驟407 實時數(shù)據(jù)庫或文件清單查詢單元返回查詢結(jié)果；步驟408 :API接口單元根據(jù)路由分析結(jié)果，如果是文件清單查詢單元返回的結(jié) 果，還需要將返回結(jié)果進行DES解密，得到解密后的信息。接著，API接口單元把各個返回 的結(jié)果進行標(biāo)準格式化，將查詢結(jié)果集返回給網(wǎng)上營業(yè)廳WEB服務(wù)器或其他渠道服務(wù)器；步驟409 網(wǎng)上營業(yè)廳WEB服務(wù)器將結(jié)果推送到用戶瀏覽器頁面上。至此，用戶查詢清單的流程結(jié)束。
以上以網(wǎng)上營業(yè)廳為例詳細說明了清單查詢方法的具體實施方式
。本領(lǐng)域技術(shù)人 員可以意識到，這僅是示范性的闡述，并不用于限定本發(fā)明實施方式的應(yīng)用環(huán)境。綜上所述，在本發(fā)明實施方式的系統(tǒng)中，文件清單查詢單元保存歷史清單數(shù)據(jù)及 其索引信息，實時數(shù)據(jù)庫保存實時清單數(shù)據(jù)，查詢路由引擎單元接收的查詢請求確定是從 實時數(shù)據(jù)庫或文件清單查詢單元中獲取清單數(shù)據(jù)。由此可見，由于索引信息是保存在文件 清單查詢單元中，當(dāng)實時數(shù)據(jù)庫或別的數(shù)據(jù)庫發(fā)生故障時，并不影響文件清單查詢單元的 清單數(shù)據(jù)查詢操作。而且，程序編程接口(API)接口單元，可以將各種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格 式的查詢請求，利用統(tǒng)一接口提供了標(biāo)準的API接口，從而為用戶提供了便利。另外，通過 對實時清單數(shù)據(jù)、歷史清單數(shù)據(jù)、容災(zāi)數(shù)據(jù)等進行劃分處理，本發(fā)明實施方式還實現(xiàn)了信息 的生命周期管理，而且可以按照客戶優(yōu)先級的不同進行差異化查詢。以上所述，僅為本發(fā)明的較佳實施方式而已，并非用于限定本發(fā)明的保護范圍。凡 在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保 護范圍之內(nèi)。
權(quán)利要求
一種清單查詢系統(tǒng)，其特征在于，該系統(tǒng)包括實時數(shù)據(jù)庫、文件清單查詢單元和查詢路由引擎單元，其中實時數(shù)據(jù)庫，用于保存實時清單數(shù)據(jù)；文件清單查詢單元，用于保存歷史清單數(shù)據(jù)及其索引信息；查詢路由引擎單元，用于根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基于所述索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的清單查詢系統(tǒng)，其特征在于，該系統(tǒng)進一步包括容災(zāi)數(shù)據(jù)庫， 用于保存容災(zāi)清單數(shù)據(jù)；查詢路由引擎單元，進一步用于在實時數(shù)據(jù)庫和/或文件清單查詢單元不可用時，從 所述容災(zāi)數(shù)據(jù)庫中獲取容災(zāi)清單數(shù)據(jù)。
3.根據(jù)權(quán)利要求1所述的清單查詢系統(tǒng)，其特征在于，該系統(tǒng)進一步包括應(yīng)用程序編 程接口 API接口單元，所述API接口單元，用于接收至少一種類型的查詢請求，將所述至少一種類型的查詢 請求轉(zhuǎn)換為統(tǒng)一格式的查詢請求，并發(fā)送到所述查詢路由引擎單元。
4.根據(jù)權(quán)利要求2所述的清單查詢系統(tǒng)，其特征在于，該系統(tǒng)進一步包括備份數(shù)據(jù)源， 用于保存?zhèn)浞萸鍐螖?shù)據(jù)；查詢路由引擎單元，進一步用于檢查容災(zāi)數(shù)據(jù)庫、實時數(shù)據(jù)庫和/或文件清單查詢單 元的狀態(tài)，并基于所述狀態(tài)檢查結(jié)果和預(yù)先設(shè)定的查詢策略從所述備份數(shù)據(jù)源中獲取備份 清單數(shù)據(jù)。
5.一種清單查詢裝置，其特征在于，包括查詢請求接收單元、路由判定單元和地址信息 單元，其中所述查詢請求接收單元，用于從查詢請求方接收查詢請求；所述路由判定單元，用于根據(jù)所述查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)， 還是基于保存在文件清單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史清 單數(shù)據(jù)；地址信息返回單元，用于基于由所述路由判定單元判定的清單數(shù)據(jù)獲取方式，向查詢 請求方返回實時數(shù)據(jù)庫和/或文件清單查詢單元的地址信息。
6.根據(jù)權(quán)利要求5所述的清單查詢裝置，其特征在于，進一步包括優(yōu)先級確定單元；所述優(yōu)先級確定單元，用于確定所述查詢請求的優(yōu)先級，并向地址信息返回單元發(fā)送所述查詢請求的優(yōu)先級；所述地址信息返回單元，用于基于所述路由判定單元判定的清單數(shù)據(jù)獲取方式，向查 詢請求方返回實時數(shù)據(jù)庫和/或文件清單查詢單元的與所述查詢請求的優(yōu)先級相對應(yīng)的 地址信息。
7.根據(jù)權(quán)利要求5或6所述的清單查詢裝置，其特征在于，所述清單查詢裝置進一步包 括API接口單元；所述API接口單元，用于接收至少一種類型的查詢請求，將所述至少一種類型的查詢 請求轉(zhuǎn)換為統(tǒng)一格式的查詢請求，并發(fā)送到所述查詢請求接收單元。
8.—種清單查詢方法，其特征在于，該方法包括發(fā)送清單查詢請求；根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基于保存在文件清 單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。
9.根據(jù)權(quán)利要求8所述的清單查詢方法，其特征在于，該方法進一步包括當(dāng)判定實時數(shù)據(jù)庫和/或文件清單查詢單元不可用時，從容災(zāi)數(shù)據(jù)庫中獲取容災(zāi)清單 數(shù)據(jù)。
10.根據(jù)權(quán)利要求8所述的清單查詢方法，其特征在于，所述發(fā)送清單查詢請求包括 從營業(yè)廳發(fā)送清單查詢請求、從網(wǎng)上營業(yè)廳發(fā)送清單查詢請求、從WAP網(wǎng)絡(luò)發(fā)送清單查詢 請求、或根據(jù)短信/彩信發(fā)送清單查詢請求。
11.根據(jù)權(quán)利要求8所述的清單查詢方法，其特征在于，該方法進一步包括在接收至少一種類型的查詢請求后，將所述至少一種類型的查詢請求轉(zhuǎn)換為統(tǒng)一格式 的查詢請求。
12.根據(jù)權(quán)利要求9所述的清單查詢方法，其特征在于，該方法進一步包括進一步檢查容災(zāi)數(shù)據(jù)庫、實時數(shù)據(jù)庫和/或文件清單查詢單元的狀態(tài)，并基于所述狀 態(tài)檢查結(jié)果和預(yù)先設(shè)定的查詢策略從備份數(shù)據(jù)源中獲取備份清單數(shù)據(jù)。
13.根據(jù)權(quán)利要求8-12中任一項所述的清單查詢方法，其特征在于，所述清單查詢請 求中包括查詢時間信息；所述根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基于保存在文 件清單查詢單元中的索引信息從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)包括從所述清單查詢請求中解析出查詢時間信息；根據(jù)所述查詢時間信息確定所述清單查詢請求為實時清單查詢請求或歷史清單查詢 請求，當(dāng)為實時清單查詢請求時從所述實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，當(dāng)為歷史清單查詢 請求時從所述文件清單查詢單元中獲取歷史清單數(shù)據(jù)。
全文摘要
本發(fā)明實施方式公開了一種清單查詢系統(tǒng)、裝置和方法。該系統(tǒng)包括實時數(shù)據(jù)庫、文件清單查詢單元和查詢路由引擎單元，其中實時數(shù)據(jù)庫，用于保存實時清單數(shù)據(jù)；文件清單查詢單元，用于保存歷史清單數(shù)據(jù)及其索引信息；查詢路由引擎單元，用于根據(jù)接收的查詢請求確定是從實時數(shù)據(jù)庫獲取實時清單數(shù)據(jù)，還是基于索引信息從文件清單查詢單元中獲取歷史清單數(shù)據(jù)。應(yīng)用本發(fā)明實施方式以后，當(dāng)實時數(shù)據(jù)庫或別的數(shù)據(jù)庫發(fā)生故障時，并不影響文件清單查詢單元的清單數(shù)據(jù)查詢操作。還實現(xiàn)了信息的生命周期管理，而且可以按照客戶優(yōu)先級的不同進行差異化查詢。
文檔編號G06F17/30GK101957830SQ20091015932
公開日2011年1月26日 申請日期2009年7月13日 優(yōu)先權(quán)日2009年7月13日
發(fā)明者孫凱, 戴建東, 王宏圖 申請人:中國移動通信集團江蘇有限公司