消息跟蹤和檢查的方法和系統(tǒng)的制作方法
【專利摘要】一種用于跟蹤報價和訂購平臺的高速緩存架構中的消息的失效跟蹤器系統(tǒng)，其中所述高速緩存架構包括多個級別，其中每個級別都包含一個或多個服務器，其中失效消息從一個級別傳達到另一個級別，以便把失效消息發(fā)送到所述高速緩存架構中的全部服務器，以及其中所述失效跟蹤器系統(tǒng)從供應商數(shù)據(jù)庫接收要傳達到所述高速緩存架構中的服務器的數(shù)據(jù)；其中所述失效跟蹤器系統(tǒng)包括：記錄模塊，用于記錄傳達到所述高速緩存架構中的服務器的全部失效消息以形成已發(fā)送失效消息的集合；分析模塊，用于確定在所述高速緩存架構中的每個服務器接收的失效消息以及將接收的失效消息與所述已發(fā)送失效消息的集合對比以識別一個或多個未傳遞失效消息；重放模塊，用于向所述高速緩存架構中的適當服務器再次發(fā)送一個或多個識別的未傳遞失效消息。
【專利說明】消息跟蹤和檢查的方法和系統(tǒng)
【技術領域】
[0001]本發(fā)明涉及跟蹤和檢查消息以及在必要時采取補救措施的方法和系統(tǒng)。
【背景技術】
[0002]在旅游系統(tǒng)中有許多消息從一處分發(fā)到另一處。典型情況下，旅游系統(tǒng)可以包含中心數(shù)據(jù)服務器和由遍布該系統(tǒng)分布的許多不同級別的高速緩存組成的高速緩存架構。高速緩存架構從許多不同的供應商獲得更新，然后把它們從應用服務器傳達到不同級別的高速緩存。該系統(tǒng)的工作基礎是不要求消息的確認。該系統(tǒng)假設已經穩(wěn)妥地收到了消息。數(shù)據(jù)庫應用服務器將消息發(fā)送到中心數(shù)據(jù)服務器上的許多中心高速緩存，中心數(shù)據(jù)服務器然后又將消息發(fā)送到眾多計算服務器上的本機高速緩存。這些消息意在使高速緩存的內容失效。它們被稱為失效消息。在典型的旅游系統(tǒng)中可能每天都有多達100，000個更新，這等同于極多的消息要應對。如果未收到消息便發(fā)生問題，此時可能發(fā)生的問題可能導致對消費者的財務影響。為了確保和控制分布式高速緩存架構中的數(shù)據(jù)一致性，可以使用異步失效消息。它的實現(xiàn)方式困難而耗時并且目前尚未以有效方式實現(xiàn)。
[0003]為了應對航空公司旅客機票審計已經提出了許多系統(tǒng)。西北航空公司已經提出了一種這樣的系統(tǒng)，它使用專家系統(tǒng)審計過程來復查報告。這種系統(tǒng)未能應對與跟蹤失效消息等問題相關聯(lián)的許多難題。同樣，其他系統(tǒng)提供了費用驗證產品以及映射和匹配產品，它們仍然未能解決跟蹤失效消息的問題。
[0004]US6, 604, 205公開了同一網(wǎng)絡中連接的至少兩臺設備之間狀態(tài)同步的方法和系統(tǒng)。第一臺設備把消息發(fā)送到第二臺設備，以第一標識符附著到該消息。第二臺設備然后對該消息應用特定過程，它又把第一標識符變換為第二標識符。第一臺設備然后向第二臺設備發(fā)送狀態(tài)請求，請求第二標識符的傳輸。第一臺設備的比較模塊然后比較第一標識符和第二標識符以判斷第一臺設備的狀態(tài)是否與第二臺設備的狀態(tài)同步。

【發(fā)明內容】

[0005]本發(fā)明的目的是克服與現(xiàn)有技術相關聯(lián)的至少某些問題。
[0006]本發(fā)明的進一步目的是提供一種方法和系統(tǒng)，能夠有效地跟蹤和監(jiān)視失效消息以及在需要時再次發(fā)送所述消息。
[0007]本發(fā)明提供了附帶的權利要求書中闡述的方法和系統(tǒng)。
[0008]根據(jù)本發(fā)明的一個方面，提供了用于跟蹤報價和訂購平臺的高速緩存架構中的消息的失效跟蹤器系統(tǒng)，其中所述高速緩存架構包括多個級別，其中每個級別都包含一個或多個服務器，其中失效消息從一個級別傳達到另一個級別，以便把失效消息發(fā)送到所述高速緩存架構中的全部服務器，以及其中所述失效跟蹤器系統(tǒng)從供應商數(shù)據(jù)庫接收要傳達到所述高速緩存架構中的服務器的數(shù)據(jù)；其中所述失效跟蹤器系統(tǒng)包括:
[0009]-記錄模塊，用于記錄傳達到所述高速緩存架構中的服務器的全部失效消息以形成已發(fā)送失效消息的集合；[0010]-分析模塊，用于確定在所述高速緩存架構中的每個服務器接收的失效消息以及將接收的失效消息與所述已發(fā)送失效消息的集合對比以識別一個或多個未傳遞失效消息；
[0011]-重放模塊，用于向所述高速緩存架構中的適當服務器再次發(fā)送一個或多個識別的未傳遞失效消息。
[0012]可選情況下，所述重放模塊基于已經滿足的預定條件再次發(fā)送失效消息。
[0013]可選情況下，所述預定條件包括多條重現(xiàn)的未傳遞失效消息。
[0014]可選情況下，在未傳遞失效匹配消息的數(shù)目超過預定閾值時觸發(fā)所述預定條件。
[0015]可選情況下，所述預定條件是識別服務器不在運行。
[0016]可選情況下，所述系統(tǒng)進一步包括通知模塊，用于創(chuàng)建未傳遞失效消息的通知并向用戶傳達所述通知。
[0017]可選情況下，所述系統(tǒng)進一步包括報告模塊，用于創(chuàng)建報告并向用戶傳達所述報
生口 ο
[0018]可選情況下，所述失效跟蹤器進一步包括監(jiān)督器模塊，用于控制未傳遞失效消息的自動檢索。
[0019]可選情況下，所述失效跟蹤器系統(tǒng)進一步包括配置管理模塊，所述配置管理模塊存儲關于所述高速緩存架構的設置和分布狀況的信息。
[0020]根據(jù)本發(fā)明的第二方面，提供了一種用于跟蹤報價和訂購平臺的高速緩存架構中的消息的方法，其中所述高速緩存架構包括多個級別，其中每個級別都包含一個或多個服務器，其中失效消息從一個級別傳達到另一個級別，以便把失效消息發(fā)送到所述高速緩存架構中的全部服務器，以及其中所述消息由所述失效跟蹤器系統(tǒng)跟蹤，所述失效跟蹤器系統(tǒng)從供應商數(shù)據(jù)庫接收要傳達到所述高速緩存架構中的服務器的數(shù)據(jù)；其中所述方法包括:
[0021]-經由計算機記錄傳達到所述高速緩存架構中的服務器的全部失效消息以形成已發(fā)送失效消息的集合；
[0022]-經由計算機中的檢測器確定在所述高速緩存架構中的每個服務器接收的失效消息以及將接收的失效消息與所述已發(fā)送失效消息的集合對比以識別一個或多個未傳遞失效消息；
[0023]-經由消息系統(tǒng)向所述高速緩存架構中的適當服務器再次發(fā)送一個或多個識別的未傳遞失效消息。
[0024]可選情況下，再次發(fā)送失效消息的步驟根據(jù)預定條件。
[0025]可選情況下，所述預定條件包括識別多個重現(xiàn)的未傳遞失效消息。
[0026]可選情況下，所述預定條件包括在未傳遞失效匹配消息的數(shù)目超過預定閾值時觸發(fā)所述消息重放。
[0027]可選情況下，所述預定條件包括識別服務器不在運行。
[0028]可選情況下，所述方法包括創(chuàng)建未傳遞失效消息的通知并向用戶傳達所述通知的步驟。
[0029]可選情況下，所述方法包括創(chuàng)建報告并向用戶傳達所述報告的步驟。
[0030]可選情況下，所述方法包括經由監(jiān)督器模塊控制未傳遞失效消息的自動檢索的步驟。
[0031]可選情況下，所述方法包括經由配置管理模塊存儲關于所述高速緩存架構的設置和分布狀況的信息。
【專利附圖】

【附圖說明】
[0032]現(xiàn)在將對例如附圖進行參考，其中:
[0033]圖1是根據(jù)本發(fā)明的實施例的失效跟蹤器系統(tǒng)的框圖；
[0034]圖2是根據(jù)本發(fā)明的實施例的用于過程第一部分的系統(tǒng)框圖；
[0035]圖3是根據(jù)本發(fā)明的實施例的用于過程第二部分的系統(tǒng)框圖；
[0036]圖4是根據(jù)本發(fā)明的實施例的用于過程第三部分的系統(tǒng)框圖；
[0037]圖5是根據(jù)本發(fā)明的實施例的用于過程第四部分的系統(tǒng)框圖；
[0038]圖6是根據(jù)本發(fā)明的實施例的用于過程第五部分的系統(tǒng)框圖；
[0039]圖7是根據(jù)本發(fā)明的實施例的系統(tǒng)的整體概況的框圖；
[0040]圖8是根據(jù)本發(fā)明的實施例的系統(tǒng)的使用事例的總圖；
[0041 ]圖9至圖18是根據(jù)本發(fā)明的實施例的許多特定使用事例圖。
【具體實施方式】
[0042]本發(fā)明涉及被設計為要在費用高速緩存系統(tǒng)環(huán)境中使用的失效跟蹤器系統(tǒng)。報價和訂購平臺(PSP)的高速緩存架構由橫跨PSP組件分布的幾個級別的高速緩存組成。正如圖2所示，有單個數(shù)據(jù)庫應用服務器200與多臺中心數(shù)據(jù)服務器202通信，多臺中心數(shù)據(jù)服務器202又與眾多計算服務器204通信。在所示的實例中，有三臺中心數(shù)據(jù)服務器和大約150臺計算服務器。應當認識到在不同的環(huán)境中可以使用不同數(shù)量的中心數(shù)據(jù)服務器和計算服務器。這個高速緩存架構被連接到從供應商連續(xù)地獲取數(shù)據(jù)更新的數(shù)據(jù)庫。高速緩存借助從數(shù)據(jù)庫應用服務器發(fā)送的失效信息得以更新?？梢杂胁恢挂粋€數(shù)據(jù)庫，比如主文件數(shù)據(jù)庫和有效圖像數(shù)據(jù)庫。不過，不同的數(shù)據(jù)庫可以在不同的情況中使用。
[0043]失效跟蹤器系統(tǒng)和方法涉及檢查由數(shù)據(jù)應用服務器發(fā)送的失效消息被終端用戶接收。按定期方式進行這些檢查，并且如果識別出任何不一致，可以自動地再次發(fā)送失效消息或在用戶的控制下再次發(fā)送。如果識別出反復出現(xiàn)的問題，可以產生警報或出錯消息以便能夠通知用戶或操作員。失效跟蹤器系統(tǒng)和方法可以用于對失效流程中全部系統(tǒng)組件和子系統(tǒng)進行調查。
[0044]參考圖1，顯示了失效跟蹤器系統(tǒng)組件的概況。圖3更詳細地介紹了各種功能。系統(tǒng)包括失效跟蹤器102所在的數(shù)據(jù)控制臺服務器100。系統(tǒng)進一步包括數(shù)據(jù)庫應用服務器104、客戶機數(shù)據(jù)服務器(CDS)子系統(tǒng)106和報價或低費用搜索(LFS)子系統(tǒng)108 (后文稱為計算服務器)。失效跟蹤器系統(tǒng)包括三個主要模塊。失效跟蹤器監(jiān)督器110對于給定時間范圍和給定終端用戶或目標組管理全自動檢測以及重放或再次發(fā)送任何丟失的失效消息。失效跟蹤器檢測器模塊112通過分析來自目標失效組件的關鍵字記錄器文件的關鍵字來識別遺漏的失效消息。失效跟蹤器重放模塊114重放或向所請求的目標再次發(fā)送丟失的失效消息。失效跟蹤器系統(tǒng)基于中間件服務等級。
[0045]邏輯失效流程包括四種類型的系統(tǒng)組件。第一種是位于數(shù)據(jù)庫應用服務器116上的數(shù)據(jù)庫應用服務器的失效服務。它向CDS CIX(中心失效)服務器隊列的消息隊列發(fā)送邏輯關鍵字陣列。CIX服務器118接收包含邏輯實體關鍵字陣列的消息，以便使其失效并將其分發(fā)到包含至IIX (單獨失效)服務器120的單關鍵字的消息中。IIX服務器管理⑶S高速緩存上的單失效消息并把這些失效消息轉發(fā)到定價衛(wèi)星或目標124上的LIX(本地失效)服務器122。LIX服務器處理計算服務器上的失效消息。每個服務器都包括與檢測器112通信的適當?shù)年P鍵字記錄器(124、126、128和130)。關鍵字記錄器的目標是本地存儲由每個服務器接收的全部消息。
[0046]失效跟蹤器系統(tǒng)要求每個失效系統(tǒng)組件記錄其接收的任何消息的關鍵字。這種記錄通過與每個服務器相關聯(lián)的關鍵字記錄器系統(tǒng)組件完成。關鍵字被記錄，這使得確定失效流程在何處失敗更容易。失效跟蹤器系統(tǒng)組件之間的通信基于標準的中間件通信。結果，關于系統(tǒng)中特定組件的全部必要信息都被存儲在失效跟蹤器專用的配置文件中。必要信息可以包括主機名、目標中間件環(huán)境或目標數(shù)據(jù)庫。失效跟蹤器系統(tǒng)能夠按照失效判斷目標是否可運行，并且在不可運行時忽略該目標。
[0047]失效跟蹤器系統(tǒng)借助幾個專門編寫的過程監(jiān)視和重放失效消息。第一個過程是記錄過程，由服務器接收的失效消息在該過程中被記錄在每個服務器上。在分析過程中基于固定時間的方式對每個服務器上接收的失效消息進行從頭到尾的檢查。如果消息丟失則使用重放過程，而且為了刷新對應數(shù)據(jù)自動地重放相關消息。如果消息丟失則使用通知過程進行識別。使用報告過程來記錄和存檔全部操作并且不時地產生統(tǒng)計報告。每個專門編寫的過程將參考圖2至圖6進行說明。
[0048]參考圖2，每個服務器都包括分別為206、208和210的失效消息處理程序；分別為212、214和216的記錄處理程序；以及分別為218、220和222的壓縮后失效消息的數(shù)據(jù)庫。從失效消息處理程序206向失效消息處理程序208發(fā)送消息。失效消息處理程序208然后把該消息傳播到相應的失效消息處理程序210。
[0049]每個失效消息處理程序都把消息傳遞到其各自的記錄處理程序，在數(shù)據(jù)應用服務器中所示的模塊224和226中記錄和壓縮。在消息已經被記錄和壓縮后，壓縮的消息被存儲在數(shù)據(jù)應用服務器中所示的數(shù)據(jù)庫218中。在中心數(shù)據(jù)服務器和計算服務器中能找到類似的布局。這就完成了每個服務器上全部失效消息的記錄過程。
[0050]對于這種類型的典型PSP高速緩存系統(tǒng)，總數(shù)據(jù)量將在每天4.5GB量級，以每秒大約15，000條消息的本地速率。高速緩存系統(tǒng)的保留期限典型情況下將為五天的量級。已發(fā)送全部消息在每個服務器的壓縮后失效消息數(shù)據(jù)庫中被存儲預定時間。
[0051]現(xiàn)在參考圖3，現(xiàn)在將介紹分析過程。數(shù)據(jù)控制臺服務器300與數(shù)據(jù)應用服務器200、中心數(shù)據(jù)服務器202和計算服務器204通信。數(shù)據(jù)控制臺服務器中的失效跟蹤器系統(tǒng)包括協(xié)調程序模塊308、配置管理器310和配置數(shù)據(jù)庫312。另外，失效跟蹤器進一步包括與兩個數(shù)據(jù)庫通信的檢測器314:要重放的消息的數(shù)據(jù)庫316和歷史數(shù)據(jù)庫318。檢測器也與失效消息收集器320通信。
[0052]服務器200、202和204的每一臺都包括在數(shù)據(jù)應用服務器200中示為212的記錄處理程序。記錄處理程序與壓縮后失效消息的數(shù)據(jù)庫218通信。記錄處理程序包括檢索模塊324、解壓器模塊326和串聯(lián)模塊328。其他傳感器202和204同等地配置。
[0053]協(xié)調程序模塊定期觸發(fā)分析循環(huán)。協(xié)調程序模塊與檢測器314中的分析器模塊330通信。分析器類似地與失效消息收集器320中的收集器模塊332通信。收集器模塊收集和記錄從PSP系統(tǒng)服務器中接收或完成的失效消息的細節(jié)。收集從每層服務器中進行:數(shù)據(jù)庫應用服務器；中心數(shù)據(jù)庫服務器；以及計算服務器。分析器模塊然后應用算法以檢測、識別和存儲尚未收到或已經丟失的消息。正如先前陳述，對每條消息的關鍵字記錄使得容易識別該消息以及它在何處丟失。已經丟失并且可能需要后來重放的消息被存儲在數(shù)據(jù)庫316中。配置管理器310對PSP系統(tǒng)服務器的設置和分布狀況有集中的了解，并且能夠協(xié)調失效消息的收集。網(wǎng)絡的配置被存儲在配置數(shù)據(jù)庫312中并且能夠在網(wǎng)絡改變時更新。歷史數(shù)據(jù)庫318用于保存全部操作的記錄。在運行時，分析器模塊330首先檢查數(shù)據(jù)庫應用服務器處接收的消息。隨后檢查在中心數(shù)據(jù)服務器的消息并且最后檢查在計算服務器的消息。這種順序能夠識別出特定失效消息的失敗點。
[0054]檢索模塊324在如圖3中所示出的數(shù)據(jù)庫應用服務器中。檢索模塊324識別然后傳遞所接收的失效消息。這些消息從數(shù)據(jù)應用服務器發(fā)送到中心數(shù)據(jù)服務器，然后從中心數(shù)據(jù)服務器發(fā)送到計算服務器。
[0055]已經分析了失效消息的接收后，該過程的下一個階段是在已經識別出丟失的消息的情況下重放或再次發(fā)送消息。這將參考圖4介紹，其中與圖3相同的單元將具有同樣的附圖標記，并且將不會進一步詳細地介紹，除非這屬于重放失效消息的過程。除了先前介紹的模塊之外，失效跟蹤器還包括重放模塊400和失效消息發(fā)送模塊402。在分析了丟失的失效消息后，確定對于特定服務器已經丟失的消息數(shù)量。如果丟失的消息數(shù)量低于某閾值便通知發(fā)送者或用戶，并且再次發(fā)送丟失的消息。不過，如果丟失的消息數(shù)量高于某閾值，則向協(xié)調程序或用戶發(fā)送警報狀態(tài)，因為有問題的服務器很可能不再運行而再次發(fā)送消息將不起任何作用。
[0056]全部操作以及所記錄并重放的消息都存儲在歷史數(shù)據(jù)庫中。已經識別出消息已經在某服務器丟失后，失效消息發(fā)送模塊將向沒有收到該消息的服務器發(fā)送丟失的消息。如果這臺服務器是數(shù)據(jù)應用服務器或中心數(shù)據(jù)服務器之一，那么該消息將分別向這些中心數(shù)據(jù)服務器和計算服務器傳遞。如果消息在特定服務器丟失，在該點之后的任何服務器也都將不會收到該消息，因此這就是對計算服務器(它們是失效流程的端點)以外的任何服務器重放消息時要把它傳遞下去的原因。在PSP系統(tǒng)服務器內發(fā)送的消息遵循來自接收該重放消息的服務器的標準失效流程。
[0057]參考圖5，失效跟蹤器系統(tǒng)包括通知模塊500，它能夠用于基于已經被重放消息的狀態(tài)發(fā)送通知。這些消息能夠包括全部丟失的消息已經被重放的事實。作為替代，能夠發(fā)送一條消息表明，消息已經被重放了幾次。如果丟失的消息的數(shù)量高于某閾值，便可以產生通知，它給出某特定服務器當前不在運行的指示。借助任何適合的通信插件比如郵件、RSS (網(wǎng)絡送入格式)、SMS等能夠發(fā)送這些通知。
[0058]以類似方式，圖6介紹了本發(fā)明的報告過程。失效跟蹤器系統(tǒng)包括存檔數(shù)據(jù)庫600、存檔模塊602、統(tǒng)計模塊604和報告數(shù)據(jù)庫606。
[0059]協(xié)調程序模塊能夠定期觸發(fā)報告的產生。此外，報告的性質可以預定義或開發(fā)并且應特定用戶或供應商的請求而產生。報告的性質可以由配置管理模塊識別。存檔數(shù)據(jù)庫包括比歷史數(shù)據(jù)庫更長期的數(shù)據(jù)保留，并且存檔模塊能夠訪問存檔數(shù)據(jù)庫，并且使用適當?shù)慕y(tǒng)計產生所要求的報告。[0060]圖2至圖6的每一幅都已經被用于介紹由失效跟蹤器系統(tǒng)所執(zhí)行的部分過程。圖7顯示了失效跟蹤器系統(tǒng)的整體概況圖。各個單元根據(jù)圖2至圖6中的類似單元編號，并且等效解釋和描述將適用于每個單元。以上介紹的失效跟蹤器系統(tǒng)是全自動的并高度可配置。另外，失效跟蹤器系統(tǒng)是分布式的、可縮放的并能夠與任何全球PSP系統(tǒng)集成。
[0061]本發(fā)明用于管理旅游業(yè)中使用的巨量的失效消息。能夠監(jiān)視大量主機并能夠跟蹤持久的數(shù)據(jù)流?，F(xiàn)在將對許多使用案例進行引用以進一步演示本發(fā)明的功能。圖8顯示了一般的使用案例圖。失效跟蹤器監(jiān)督器800是高層次模塊，管理對于給定時間范圍和給定服務器組丟失的失效消息的全自動檢測和重放。失效跟蹤器檢測器模塊802通過分析來自關鍵字記錄器文件的關鍵字來確定丟失的失效消息以瞄準失效組件。失效跟蹤器重放模塊804借助失效過程806把丟失的失效消息重放給所請求的目標。用戶808與多個模塊通信而若干過程的調度由調度器系統(tǒng)810管理。
[0062]在以下具體使用案例中，用戶或失效跟蹤器監(jiān)督器900與對其發(fā)送、接收或以其他方式處理失效消息的各個目標通信。在以下篇幅中以這種方式解釋術語用戶和目標。
[0063]在圖9顯示的使用案例中，全部目標在運行而且沒有丟失有效消息。失效跟蹤器檢測器902接收在各個系統(tǒng)組件之間被發(fā)送和被接收的失效消息，并且檢查是否已經丟失了任何消息。如果已經丟失了消息便提供丟失關鍵字的列表。分析的時間范圍被預定義并且用戶使用失效跟蹤器檢測器進行特定調查。作為替代，可以安排自動檢查以自動地執(zhí)行。
[0064]在第一個步驟904中，從用戶向失效跟蹤器檢測器發(fā)送檢查請求。這種請求能夠基于許多不同的準則。在步驟906中失效跟蹤器檢測器將以源失效組件908檢查失效路由。在步驟910中源失效組件指出該組件在運行。在步驟912中失效跟蹤器檢測器請求源失效組件對具體時間范圍建立源失效列表；這在步驟914中返回。隨后失效跟蹤器檢測器對全部目標失效組件進行調查。對于每個目標失效組件執(zhí)行以下步驟。在步驟918中失效跟蹤器檢測器從跟蹤器失效組件916判斷該失效路由是否在運行。在步驟920中從目標失效組件發(fā)出應答以確認該組件在運行。在步驟922中失效跟蹤器檢測器從目標失效組件請求在具體時間范圍上的目標失效列表。在這種情況下，在步驟924中目標失效組件916確認還沒有丟失失效消息。以這種方式檢查全部目標失效組件之后，在步驟926中失效跟蹤器檢測器判斷是否存在著任何已經丟失的消息。在這種情況下，由于尚未丟失消息所以在步驟928中失效跟蹤器檢測器向用戶傳達沒有丟失的關鍵字。根據(jù)在給定時間范圍內由所請求的失效系統(tǒng)組件所記錄的邏輯關鍵字，建立目標失效消息列表。該列表自身包括在給定時間由所請求的失效系統(tǒng)所記錄的邏輯關鍵字。步驟926包括比較步驟，其中對比由若干服務器和目標失效系統(tǒng)組件所記錄的關鍵字列表。
[0065]現(xiàn)在參考圖10，這個使用案例涉及在運行但是丟失了失效消息的目標。如圖9中的介紹執(zhí)行步驟904、906、910、912、914、918、920和922。不過，在這種情況下已經從一個或多個目標失效組件中丟失了消息。結果，在步驟1000產生了已經檢測到丟失的失效消息的指示。在步驟1002對丟失消息的檢查對每個服務器識別丟失的關鍵字，然后在步驟1004將其傳達給用戶。
[0066]現(xiàn)在參考圖11，該使用案例涉及不在運行的目標。如同先前實例，如以上的介紹執(zhí)行步驟904、906、910、912、914和918。由于目標失效組件不在運行，所以在步驟1100中失效跟蹤器檢測器判定該目標不在用。在步驟1102中向用戶通知特定目標失效組件不在運行而且不在接收消息。
[0067]圖12涉及源失效組件不在運行的使用案例。如以上的介紹執(zhí)行步驟904和906。由于在步驟1200源失效組件不在運行，所以向失效跟蹤器檢測器通知該組件不在運行。然后在步驟1202將其傳達給用戶。
[0068]在圖13涉及的使用案例中丟失了許多失效消息，但是數(shù)量尚未達到以上討論的預定閾值。此外，此使用案例涉及不存在從特定目標重現(xiàn)丟失失效消息的情況。在這種情況下用戶或失效跟蹤器監(jiān)督器900與失效跟蹤器重放模塊1300和失效過程1302通信。在步驟1306用戶向失效跟蹤器重放模塊1300發(fā)送要重放的失效消息列表。由該用戶確定閾值(它涉及對特定目標能夠被重放的失效消息的最大數(shù)量)以及測量此閾值經過的延遲。已經向每個目標重放的消息列表被更新，這意味著在當前時間被處理的丟失的消息僅僅是在步驟1306中所提供的列表中的消息。在監(jiān)督過程期間用戶或監(jiān)督器能夠控制失效跟蹤器重放模塊。要重放消息的列表必須僅僅包含非重現(xiàn)的丟失的消息以及沒有到達特定目標但是尚未達到閾值的消息。任何非重現(xiàn)的丟失的消息都基于對被發(fā)送失效消息的計時以由用戶配置的延遲被重放。典型的延遲為一秒的量級。為了保護被重放的信息量，如果失效消息數(shù)量已經達到每個目標的閾值或者這些消息已經在給定時間范圍期間被重放，該系統(tǒng)便不播放這些消息。在已經達到了閾值的情況下，警報出現(xiàn)并由任何適宜裝置比如電子郵件發(fā)送給用戶。
[0069]返回到圖13，步驟1308涉及過濾邏輯關鍵字的步驟。該過濾器從給定的消息列表和對給定的目標確定要失效的邏輯關鍵字。之所以沒有過濾出任何關鍵字是因為目標的閾值還未達到閾值并且不存在重現(xiàn)的丟失的失效消息。結果，在列表中的全部關鍵字都被標注為準備好重放。在步驟1310中，對于已經丟失的失效消息，邏輯關鍵字的列表被發(fā)送給失效過程。同時在步驟1312中重放的關鍵字的列表被存儲并傳達給用戶。
[0070]在圖14中，使用案例涉及已經丟失的失效消息的數(shù)量達到或超過了至少一個目標的閾值。如以上的介紹執(zhí)行步驟1306。在步驟1400應用過濾器。在這種情況下失效消息的邏輯關鍵字被過濾器全部過濾出，因為丟失的失效消息的數(shù)量已經達到或超過了至少一個目標的閾值。結果，該系統(tǒng)將不播放任何失效消息。在步驟1402轉而向該用戶發(fā)送消息以指示已經丟失的消息多得無法重放它們。
[0071]在圖15涉及的使用案例中，對特定目標存在著重現(xiàn)的丟失的失效消息。如以上的介紹執(zhí)行步驟1306。在步驟1500對失效消息列表應用過濾器。在這種情況下列表中存在著某些重現(xiàn)誤差。這些在步驟1500被過濾出并在步驟1502產生丟失的重現(xiàn)消息的警報。列表上的其他消息在步驟1504被發(fā)送到失效過程并向有問題的目標重放。在步驟1506向用戶通知已經被重放的消息，以便使其能夠被存儲。
[0072]在圖16公開的使用案例中，在許多目標上存在著丟失的失效消息。如以上的介紹發(fā)送消息并在步驟1600應用過濾器。該過濾器在步驟1602判定對于框符I (第一個目標)存在著太多的丟失消息并產生了警報消息。此外，在步驟1604過濾器識別出框符2 (第二個目標)具有許多重現(xiàn)的丟失的消息。失效跟蹤器重放模塊然后產生要在步驟1606通過失效過程1302重放的消息的列表。步驟1606包括不對框符I重放任何消息；對于框符2的消息僅僅是與非重現(xiàn)的丟失的關鍵字有關的消息；以及對于所有的其他框符(目標)全部丟失關鍵字都被重放。在步驟1608通知用戶已經重放的消息因而可以存儲它們。[0073]圖17涉及的使用案例包括失效跟蹤器監(jiān)督器1700。為了有規(guī)律地運行該過程，該過程由調度系統(tǒng)1702協(xié)調。本系統(tǒng)還使用了失效跟蹤器檢測器902和失效跟蹤器重放模塊1300。產生了要檢查的時間范圍和系統(tǒng)組件列表并且停用了失效跟蹤器重放模塊。如果有任何丟失的消息，則產生丟失的失效消息的列表作為該過程的結果。這個使用案例描述的過程監(jiān)督失效消息流并且是全自動的?？梢援a生包含丟失的失效消息的報告。在第一個步驟1704中，系統(tǒng)的調度器產生對具體時間范圍的檢查失效消息的請求。在步驟1706失效跟蹤器監(jiān)督器請求失效跟蹤器檢測器在給定時間跨度上全局地檢查失效流。失效跟蹤器檢測器在步驟1708中識別出任何關鍵字或丟失的消息并且把這些返回在列表中。
[0074]在圖18顯示的使用案例中，失效跟蹤器監(jiān)督器產生自動重放。如以上的介紹執(zhí)行步驟1704、1706和1708。這個使用案例描述的過程監(jiān)督失效消息流；由調度系統(tǒng)調度；并且是全自動的。在重現(xiàn)錯誤的情況下由失效跟蹤器重放模塊產生報告并能夠產生警報向用戶發(fā)送。監(jiān)督過程使用了在失效跟蹤器檢測器和失效跟蹤器重放模塊使用案例中已經介紹的功能。在步驟1804中重放失效消息的列表從失效跟蹤器監(jiān)督器發(fā)送到失效跟蹤器重放模塊。只有非重現(xiàn)的失效消息才將被重放。消息已經重放的確認在步驟1802中被發(fā)送給失效跟蹤器監(jiān)督器，并且在步驟1804中發(fā)送給用戶。
[0075]本領域的技術人員將理解，某些或全部功能實體以及這些過程自身可以實施為軟件或者一個或多個軟件啟用的模塊和/或器件或者其任何組合。該軟件可以運行在任何適宜的計算機或其他機器上。本發(fā)明的運行提供了許多變換，比如監(jiān)視失效消息以及在需要時再次發(fā)送。
[0076]本系統(tǒng)和方法運行在特定機器上，比如被配置執(zhí)行本發(fā)明的多個步驟和功能的計算機。本發(fā)明還涉及許多變換，包括監(jiān)視關鍵字記錄數(shù)據(jù)的能力以及使用其再次發(fā)送或重放消息的能力。
[0077]參考旅行環(huán)境中失效消息的使用已經介紹了本發(fā)明。不過，應當認識到，本發(fā)明可以應用于其他環(huán)境。應當認識到，本發(fā)明可以以許多不同方式變化而仍然保持在權利要求書中定義的本發(fā)明的意圖范圍之內。
【權利要求】
1.一種用于跟蹤報價和訂購平臺的高速緩存架構中的消息的失效跟蹤器系統(tǒng)，其中所述高速緩存架構包括多個級別，其中每個級別都包含一個或多個服務器，其中失效消息從一個級別傳達到另一個級別，以便把失效消息發(fā)送到所述高速緩存架構中的全部服務器，以及其中所述失效跟蹤器系統(tǒng)從供應商數(shù)據(jù)庫接收要傳達到所述高速緩存架構中的服務器的數(shù)據(jù)；其中所述失效跟蹤器系統(tǒng)包括: -記錄模塊，用于記錄傳達到所述高速緩存架構中的服務器的全部失效消息以形成已發(fā)送失效消息的集合； -分析模塊，用于確定在所述高速緩存架構中的每個服務器接收的失效消息以及將接收的失效消息與所述已發(fā)送失效消息的集合對比以識別一個或多個未傳遞失效消息； -重放模塊，用于向所述高速緩存架構中的適當服務器再次發(fā)送一個或多個識別的未傳遞失效消息。
2.根據(jù)權利要求1的系統(tǒng)，其中，所述重放模炔基于已經滿足的預定條件再次發(fā)送失效消息。
3.根據(jù)權利要求2的系統(tǒng)，其中，所述預定條件包括多個重現(xiàn)的未傳遞失效消息。
4.根據(jù)權利要求2或權利要求3的系統(tǒng)，其中，在未傳遞失效匹配消息的數(shù)目超過預定閾值時觸發(fā)所述預定條件。
5.根據(jù)權利要求2至4中任何一項的系統(tǒng)，其中，所述預定條件是識別服務器不在運行。
6.根據(jù)任何一項前面的權利要求的系統(tǒng)，進一步包括通知模塊，用于創(chuàng)建未傳遞失效消息的通知并向用戶傳達所述通知。
7.根據(jù)任何一項前面的權利要求的系統(tǒng)，進一步包括報告模塊，用于創(chuàng)建報告并向用戶傳達所述報告。
8.根據(jù)任何一項前面的權利要求的系統(tǒng)，其中，所述失效跟蹤器進一步包括監(jiān)督器模塊，用于控制未傳遞失效消息的自動檢索。
9.根據(jù)任何一項前面的權利要求的系統(tǒng)，其中，所述失效跟蹤器系統(tǒng)進一步包括配置管理模塊，所述配置管理模塊存儲關于所述高速緩存架構的設置和分布狀況的信息。
10.一種用于跟蹤報價和訂購平臺的高速緩存架構中的消息的方法，其中所述高速緩存架構包括多個級別，其中每個級別都包含一個或多個服務器，其中失效消息從一個級別傳達到另一個級別，以便把失效消息發(fā)送到所述高速緩存架構中的全部服務器，以及其中所述消息由所述失效跟蹤器系統(tǒng)跟蹤，所述失效跟蹤器系統(tǒng)從供應商數(shù)據(jù)庫接收要傳達到所述高速緩存架構中的服務器的數(shù)據(jù)；其中所述方法包括: -經由計算機記錄傳達到所述高速緩存架構中的服務器的全部失效消息以形成已發(fā)送失效消息的集合； -經由計算機中的檢測器確定在所述高速緩存架構中的每個服務器接收的失效消息以及將接收的失效消息與所述已發(fā)送失效消息的集合對比以識別一個或多個未傳遞失效消息； -經由消息系統(tǒng)向所述高速緩存架構中的適當服務器再次發(fā)送一個或多個識別的未傳遞失效消息。
11.根據(jù)權利要求10的方法，其中，重放失效消息是基于預定條件。
12.根據(jù)權利要求11的方法，其中，所述預定條件包括識別多個重現(xiàn)的未傳遞失效消息。
13.根據(jù)權利要求11或12的方法，其中，所述預定條件包括在未傳遞失效匹配消息的數(shù)目超過預定閾值時觸發(fā)所述消息重放。
14.根據(jù)權利要求11至13中任何一項的方法，其中，所述預定條件包括識別所述服務器不在運行。
15.根據(jù)權利要求10至14中任何一項的方法，進一步包括創(chuàng)建未傳遞失效消息的通知并向用戶傳達所述通知的步驟。
16.根據(jù)權利要求10至15中任何一項的方法，進一步包括創(chuàng)建報告并向用戶傳達所述報告的步驟。
17.根據(jù)權利要求10至16中任何一項的方法，進一步包括經由監(jiān)督器模塊控制未傳遞失效消息的自動檢索的步驟。
18.根據(jù)權利要求10至17中任何一項的方法，進一步包括經由配置管理模塊存儲關于所述高速緩存架構的設置和分布狀況的信息。
19.一種包含指令的計算機程序，當所述計算機程序在計算機系統(tǒng)上執(zhí)行時，所述指令用于執(zhí)行根據(jù)權利要求10至18中任何一項的方法的步驟。
【文檔編號】G06F17/30GK104011719SQ201280063170
【公開日】2014年8月27日 申請日期:2012年10月12日 優(yōu)先權日:2011年12月22日
【發(fā)明者】R·戈萊, B·杜考爾, M·特拉伊納 申請人:艾瑪?shù)纤购喴坠煞莨?br>