專利名稱：用于保持旨在與大型數(shù)據(jù)庫對接的多層軟件系統(tǒng)中的緩存內(nèi)容的一致性的系統(tǒng)和方法
技術領域：
本發(fā)明一般涉及多層客戶機/服務器軟件架構，更具體地說，涉 及一種保持前端層機器和中間層機器中實現(xiàn)的緩存內(nèi)容之間的一致 性以提高總體性能的方法和系統(tǒng)。
背景技術：
20世紀80年代后期出現(xiàn)的客戶機/服務器模型是一種通用的模 塊化軟件架構，與作為當時標準的集中式分時計算的大型機相比，該 架構想要改進可用性、靈活性、互操作性以及可擴展性。客戶機是服 務的請求方，而服務器則是這種服務的提供方。根據(jù)軟件配置，同一 臺機器可以同時是客戶機和服務器。客戶機/服務器架構已經(jīng)逐步取代了先前的大型機軟件架構，在 先前的大型機軟件架構中，所有智能全都位于中心主機計算機內(nèi)，并 且用戶通過只能捕獲鍵擊和向主機發(fā)送信息的無智能終端來與主機 進行交互。大型機軟件架構的眾所周知的限制是它們不易于支持圖 形用戶界面(GUI)或者從地理上分散的地點訪問多個數(shù)據(jù)庫。但是， 在分布式客戶機/服務器架構中，大型機仍被用作功能強大的服務器?？蛻魴C/服務器架構引入了充當文件服務器的數(shù)據(jù)庫服務器。在 該架構中，使用關系型數(shù)據(jù)庫管理系統(tǒng)或RDBMS來直接應答用戶查 詢。通過提供查詢響應而不是始終傳送完整文件，從而減少了網(wǎng)絡通 信量。此外，該架構還改進了通過GUI前端對共享數(shù)據(jù)庫進行的多用 戶更新。在客戶機/服務器架構中，通常使用結(jié)構化查詢語言(SQL) 語句在客戶機與服務器之間交換數(shù)據(jù)。對于圖1所示的雙層客戶機/服務器架構(100)來說，用戶系統(tǒng)接口位于用戶的臺式機(102)環(huán)境中，而數(shù)據(jù)庫管理服務則位于能 為許多客戶機提供服務的服務器(104)中。在用戶系統(tǒng)接口環(huán)境與 數(shù)據(jù)庫管理服務器環(huán)境之間，處理管理被劃分。對于往往位于局域網(wǎng) 或LAN (108)上的包括與單個/多個服務器(未顯示)對接的單個/ 多個客戶機的拓樸結(jié)構來說，這些拓樸的所有組合都是明顯可行的。在傳統(tǒng)的雙層架構中，第一層即客戶機(102)具有用戶接口、 主要業(yè)務以及數(shù)據(jù)處理邏輯。它接受并且檢查用戶輸入的句法，處理 應用邏輯，產(chǎn)生數(shù)據(jù)庫請求，將這些請求發(fā)送到服務器，以及將響應 傳回給用戶任務。第二層即數(shù)據(jù)庫服務器(104)接受并處理來自客 戶機的數(shù)據(jù)庫請求，檢查授權，確保未違反完整性約束，執(zhí)行查詢/ 更新處理，以及向客戶機發(fā)送響應。此外，第二層還維護系統(tǒng)目錄， 提供并發(fā)數(shù)據(jù)庫訪問，并且執(zhí)行恢復控制。已經(jīng)證實，當工作組中同時在LAN上交互的人不超過100個時，雙層客戶機/服務器架構是一種良好的分布式計算解決方案。但是，由 于服務器即使在無工作要做時也會借助"?；?keep-alive )"消息而與 每個客戶機保持連接，因此，當用戶數(shù)量增加時，性能開始降低。雙 層架構的第二個限制是使用賣方獨有的數(shù)據(jù)庫過程來實現(xiàn)處理管理 服務限制了針對應用的RDBMS選擇和靈活性。此外，在將程序功能 從一臺服務器移動(重新分配)到另一臺服務器時，雙層架構的實現(xiàn) 表現(xiàn)出有限的靈活性。隨后，在90年代出現(xiàn)了三層架構(120)和多層變體，用以克服 上述限制。在三層架構中，在用戶系統(tǒng)接口客戶機環(huán)境(122)與數(shù) 據(jù)庫管理服務器環(huán)境(124)之間添加了一個中間層(126)。雖然存 在用于實現(xiàn)這種架構以及中間層的多種方式，但是后者往往負責排 隊、應用執(zhí)行以及數(shù)據(jù)庫分級(database staging)。通常，由于中間 層應該訪問數(shù)據(jù)并且向客戶機返回應答，因此，客戶機將其請求遞送 到中間層然后脫離。此外，中間層還會為進行中的工作添加調(diào)度和優(yōu) 先區(qū)分。在三層架構的上述變體中，客戶機即第一層可以僅實現(xiàn)用戶接口，也就是驗證輸入；在這種情況下，中間層具有所有業(yè)務邏輯并且 執(zhí)行數(shù)據(jù)處理，而服務器即第三層則執(zhí)行數(shù)據(jù)驗證并且控制數(shù)據(jù)庫訪 問。三層客戶機/服務器架構已經(jīng)顯示出改進了具有大量用戶(通常 多達一千個，即雙層架構的10倍)的組的性能，并且尤其與雙層方 法相比，由于不必在層間共享應用代碼，因此這種架構還提高了靈活 性。三層客戶機/服務器架構導致了如下的環(huán)境，與具有直接的客戶機 到服務器連接的雙層架構相比，該環(huán)境的可擴展性明顯更大。它提供 了在單個事務中更新多個不同的RDBMS的能力，并且可以與包括平 面文件、非關系型數(shù)據(jù)庫管理系統(tǒng)的各種數(shù)據(jù)源相連，此外，它還可 以與現(xiàn)在常用作功能強大的數(shù)據(jù)庫服務器的大型機相連。由此，三層 和多層架構最適合大型分布式客戶機/服務器環(huán)境。舉個例子，機票預 訂公司必須部署以為其顧客提供服務的環(huán)境，即全世界的旅行社，其 中需要諸如異構數(shù)據(jù)庫(也就是航空運輸費用和可用性數(shù)據(jù)庫)的共 享資源以及處理規(guī)則。如果多層數(shù)據(jù)中心成為提供此類服務的主要需求，那么要想進一 步提高性能及可擴展性的話，降低計算和通信開銷是至關重要的。在 多層數(shù)據(jù)中心的不同層中緩存動態(tài)內(nèi)容是一種用于減少計算和通信 開銷的公知方法，由此，由于在命中時不必從上位層中再次提取數(shù)據(jù)， 因此可以為甚至更多的顧客同時提供服務。但是，對在中間層和前端 層中進行緩存來說，其自身是存在問題的。因此，緩存相容性和緩存 一致性成為必須處理的問題。尤其對于無法接受過時航線可用性值的 機票預訂來說，強的相容性和一致性是必不可少的。發(fā)明內(nèi)容因此，本發(fā)明的寬泛目的是提供一種用于保持多層軟件架構中的 動態(tài)緩存內(nèi)容的一致性的方法和系統(tǒng)。本發(fā)明的一個更具體的目的是本發(fā)明必須適合多層架構，例如為 機票預訂系統(tǒng)而部署的架構，并且該架構的特征在于來自客戶機側(cè)的非常高等級的事務，以及由航空公司和其它此類服務供應方提供的 費用和可用性數(shù)據(jù)庫的頻繁更新。對本領域技術人員來說，通過參考附圖來詳讀后面的描述，可以 清楚了解本發(fā)明的其它目的、特征和優(yōu)點。任何附加的優(yōu)點都應被包 括在本文中。描述了一種用于保持多層軟件架構中的緩存內(nèi)容的一致性的方法和系統(tǒng)。該架構包括衛(wèi)星服務器組成的前端層，每個衛(wèi)星服務器 都操作一個本地緩存；和中心服務器組成的中間層，每個中心服務器都操作一個中心緩存。中心服務器通過數(shù)據(jù)庫服務器與數(shù)據(jù)庫對接以 檢索用于構造對象的數(shù)據(jù)元素。 一旦構造了對象，對象就被賦予生存時間(TTL)并且被存儲在中心緩存中，然后被轉(zhuǎn)發(fā)到衛(wèi)星服務器， 在衛(wèi)星服務器中，在被遞送到已經(jīng)請求這些對象的軟件應用之前，這 些對象被存儲在本地緩存中。在所有可用的中心服務器上對來自衛(wèi)星 服務器的請求進行負載平衡。對于每個請求，選擇一個中心服務器進 行處理。新構造的對象從所選擇的中心服務器被復制到所有其它中心 服務器中。每當對象在本地緩存中不找到或過期時，則從所選擇的中 心緩存請求該對象。每當被請求對象在所選擇的中心緩存中不找到 時，在所選擇的中心服務器中觸發(fā)被請求對象的構造處理。如果被請 求對象已經(jīng)存在于中心緩存中并且沒有過期，則跳過構造處理。 一個 中心服務器被指定為主中心服務器，并且所有其它中心服務器是備份 中心服務器。每當發(fā)現(xiàn)被請求對象過期時，由無效處理機在主中心服 務器中觸發(fā)構造處理。在將所發(fā)現(xiàn)的過期對象的TTL轉(zhuǎn)發(fā)給發(fā)起請 求的衛(wèi)星服務器之前，該過期對象的TTL ^L設置成一個低值。在數(shù) 據(jù)庫中用于構造所述對象的至少一個所述數(shù)據(jù)元素一經(jīng)修改，就使存儲在中心緩存和本地緩存中的對象無效，然后確定哪些對象受到影 響，向所有中心服務器的無效處理機廣播無效命令。這些無效處理機使中心緩存中的相應對象無效，然后將無效命令傳播到所有本地緩 存，本地緩存繼而無效并刪除本地緩存中的相應對象。中心緩存中的 被無效對象被刪除或被重建。在后一種情況下，重建的對象被復制到所有備份中心緩存中。


圖l論述了現(xiàn)有技術，即二層與多層軟件架構的對比。圖2顯示了最適合應用本發(fā)明的總體的多層軟件架構。 圖3描述了由應用程序處理終端用戶請求而導致的對象提取的 各種情況以及中心服務器中的對象構造處理。圖4論述了本地和中心緩存中的對象的時效。圖5描述了在數(shù)據(jù)庫中修改了數(shù)據(jù)元素時緩存中的對象的無效處理。圖6論述了被無效對象的重建處理。圖7描述了在輔助存儲器中存儲必須從中心緩存中移除的未過 期對象的處理。
具體實施方式
本發(fā)明的以下詳細描述是參考附圖進行的。雖然描述包含了示例 性實施例，但是其它實施例也是可行的，并且在沒有脫離本發(fā)明的精 神和范圍的情況下，可對這些實施例是進行改變。圖2描述了最適合應用本發(fā)明的總體的多層軟件架構。 上層(200 )是最終數(shù)據(jù)源，其中通常至少一個數(shù)據(jù)庫服務器(202 ) 與多個數(shù)據(jù)庫(204 )對接，例如由來自世界各地的旅行承運商或此 類服務的其它提供商提供的可用性和費用數(shù)據(jù)庫。這些數(shù)據(jù)庫被其用戶(也就是負責更新和維護其內(nèi)容的用戶)(206)頻繁更新，這些 更新往往是通過包括因特網(wǎng)的專用網(wǎng)絡和公用網(wǎng)絡(208 )的組合進 行的?？偟膩碚f，每天都會記錄數(shù)以百萬計的事務，這涉及大量的數(shù) 據(jù)。在這里，中間層(210)被示出為包含兩個服務器，在下文中將 這些服務器稱為中心數(shù)據(jù)服務器或CDS。通常，出于冗余的考慮，存 在一個主服務器(212 )和一個備份服務器(214 )。但是，在一個(無冗余)與多個服務器之間的任何配置都是可行的。此外，例如為了便于系統(tǒng)維護，或者由于指定的主CDS發(fā)生故障，中心服務器有時候 必須被配置成獨立服務器。另外，在必要時，指定的備份服務器必須 暫時作為主服務器運轉(zhuǎn)。在本發(fā)明的后面的描述中會對此進行進一步 論述。對該架構來說，在中間層中具有多個服務器是常用實踐。可能有 與主服務器起相同作用的一個以上的冗余服務器，或者運行不同應用 程序的專用服務器。當需要更大的處理能力時， 一種實現(xiàn)可擴展性的 方式包括添加中間服務器，從而可以通過在更多的中間層服務器上對 前端層(220 )的請求進行負載平衡來處理更多的客戶機事務。因此， 每個CDS都具有其自己的緩存(216, 218)，這些緩存被稱為中心 緩存，它們必須始終保持相干的內(nèi)容。在本發(fā)明所考慮的應用類型中，在下文中將存在于緩存中的數(shù)據(jù) 實體寬泛地稱為軟件對象或者簡稱為對象。 一般來說，通過查詢而從 數(shù)據(jù)庫獲取的許多數(shù)據(jù)元素需要被放置在一起，以創(chuàng)建這些數(shù)據(jù)元 素。因此，舉例來說，根據(jù)本發(fā)明的對象是曾由CDS從數(shù)據(jù)元素中 構造的特定旅費，所述數(shù)據(jù)元素是通過數(shù)據(jù)庫服務器(202 )而從數(shù) 據(jù)庫(204 )獲取的。如果如背景技術部分所述，數(shù)據(jù)庫是關系型數(shù) 據(jù)庫，那么該處理可以通過以下方式實現(xiàn)向數(shù)據(jù)庫發(fā)出至少一個(通 常是許多個)SQL請求，從而能夠在CDS中收集到構造對象(例如， 在該具體示例中為旅費)所需的所有數(shù)據(jù)元素。由此，根據(jù)本發(fā)明的 對象被假定為需要處理能力并且使用與數(shù)據(jù)服務器的通信帶寬而被 置于可用形式的詳細對象。只要在數(shù)據(jù)庫中尚未修改用于構造對象的 源信息，這些對象就可以保持在緩存中。對于重建來說，由于重建耗 費了處理能力并且使用了與數(shù)據(jù)庫服務器及其數(shù)據(jù)庫的部分可用通 信帶寬，因此重建是昂貴的。就一致性而言，例如存在于主CDS(216) 的中心緩存中的特定對象必須與其在備份CDS中心緩存(218)中的 克隆體完全相同，并且其內(nèi)容必須與構造了這些內(nèi)容的數(shù)據(jù)庫(204 ) 的數(shù)據(jù)元素相容。在本發(fā)明的后面的描述中將會對此進行進一步的論述。前端層(220)是由多個衛(wèi)星服務器構成，衛(wèi)星服務器運行用于 其終端用戶的軟件應用。在用于說明本發(fā)明的該示例中，這些軟件應 用通常是定價或費用搜索引擎。這些軟件應用可以直接在衛(wèi)星客戶機 服務器(222 )上運行，或者在包含服務器群(225 )的獨立的前端層 衛(wèi)星服務器(224 )上運行，而前端層衛(wèi)星服務器(224 )繼而由遠程 用戶(226 )使用標準瀏覽器以及因特網(wǎng)上最廣泛的應用(萬維網(wǎng)或 web)通過例如因特網(wǎng)的專用或公用網(wǎng)絡(228 )來進行訪問。在這兩 種情況下，所述應用實質(zhì)上都利用本地緩存(230 )來減少前端層與 連接到所有衛(wèi)星服務器的中間層的CDS之間的通信開銷。由此，在 必要時，上述對象也會被引入不同的本地緩存。因此，如果被請求對 象實際處于其本地緩存中，那么本地應用就不必訪問CDS或數(shù)據(jù)服 務器。這樣做的主要優(yōu)點是保護數(shù)據(jù)庫服務器(202 )，即，防止這 些服務器接收到來自終端用戶(226 )的、不這樣做的話就會到達這 些服務器的無數(shù)請求。由于軟件應用是以實現(xiàn)良好的緩存命中率(hit ratio)為目標而 進行設計的，因此可以發(fā)現(xiàn)它們的性能得到了顯著提高。此外，這顯 著減少了層間的通信開銷，并且最終允許在同一基礎架構上接納更多 的終端用戶。如上面已論述的，所有這些都假設保持緩存一致性，這 一點會在后面的附圖中進行進一步論述。圖3描述了由應用程序處理終端用戶請求而導致的對象提取的 各種情況。當例如定價程序(300 )的位于前端層服務器中的應用程序需要 對象(305)來計算旅行價格時，首先詢問本地緩存(310)。如果命 中，則簡單地從本地緩存中取回對象(315)。由于整個處理只涉及 運行該應用的服務器，因此，這是取回對象的最有效的方式。但是，當在本地緩存中不存在被請求對象時，即未找到(320)。 這時必須引入對象，這里首先假設對象存在于主CDS (340 )的中心 緩存中，通過在下文中進一步描述的負載平衡功能向主CDS (340 )發(fā)出請求(390)。如果確實是這種情況(345)，那么數(shù)據(jù)處理機功 能(350)的目標是從中心緩存中取回該對象，并且將其轉(zhuǎn)發(fā)(330) 到請求服務器的本地緩存，在那里所述對象被存儲。在這樣做之后， 被請求對象最終可被遞送到應用程序。因此，本地緩存又多包含了一 個可能用于進一步的請求的對象(325)。當被請求對象既不存在于本地緩存(350 )也不存在于主CDS的 中心緩存(355)時，必須在CDS中構造該對象并且將其存儲在中心 緩存中。這是通過已提及的數(shù)據(jù)處理機(350)實現(xiàn)的，該處理機必 須從數(shù)據(jù)庫(365)收集構造被請求對象(355)所需的所有數(shù)據(jù)元素 (360)。構造該對象可能是一個復雜的處理，該處理可能需要向數(shù) 據(jù)庫發(fā)出很多請求(例如SQL查詢)。 一旦將其置于一起，則執(zhí)行 徹底的檢查以確保它確實可供發(fā)起請求的應用使用。這包括對象描述 語言的句法和語法檢查以及利用應用采樣代碼的測試。如果新對象如 正常時那樣通過了該驗證階段，則將其存儲在中心緩存中。在存儲之 前，將生存時間(TTL)或者屆滿日期附于對象，從而，當對象如圖 4中進一步論述的那樣過期時可以移除該對象。 一旦執(zhí)行了該處理， 那么新對象就被轉(zhuǎn)發(fā)到已經(jīng)請求該對象的服務器的本地緩存，該對象 首先被存儲在所述本地緩存中，然后被遞送(375)到需要該對象的 軟件應用。但是，如果新構造的對象的驗證失敗，那么該對象將被拒 絕，由此不會將其存儲在中心緩存或轉(zhuǎn)發(fā)給本地緩存(357)。當在主CDS中創(chuàng)建了新對象時，還在備份服務器(342 )中復制 (380)該對象，從而也可以從其它中心服務器緩存取回這個新對象。 如上所述，為了提供冗余和可擴展性，多個中間層服務器可以同時活 動，以使來自前端層服務器的請求在這組可用中心數(shù)據(jù)服務器上是負 載平衡的。對在圖3中描繪的負載平衡來說，提及了存在負載平衡功 能(385 )，該功能根據(jù)與眾所周知的循環(huán)復用(round-robin)功能 同樣簡單的特定邏輯或算法來分派前端層請求(390 )，除此之外， 不會進一步討論負載平衡功能，這超出了本發(fā)明的范圍。在這種情況 下，輸入的前端層請求被按順序接連發(fā)送到每個活動的中心服務器，直至到達最后一個為止。然后，下一個請求被再次發(fā)送到編號為第一 個的中心服務器，以此類推。這種簡單的算法通常是非常有效的。但是，存在某些更為復雜的算法，比如如下的算法測量每個服務器的 實際負載并且設法向最不忙的服務器發(fā)送輸入請求。因此，提及向主CDS緩存請求未找到對象的先前描述必須加以 修正。根據(jù)負載平衡功能(385 )作出的決定，由于在活動服務器中 復制(380 ) 了新構造的對象，因此也可以向備份中心緩存請求未找 到對象。在這種情況下，如果在所選擇的備份中心緩存中不存在該對 象，則必須像選擇了主CDS那樣如上所述地構造該對象。當出現(xiàn)這 種情況時，備份CDS暫時作為主CDS運轉(zhuǎn)，這意味著一旦構造了對 象，那么該對象將被從該備份CDS復制到所有活動CDS,以使得在 所有的中間層中心緩存中都可得到新對象。在圖6中也論述了本發(fā)明 的此方面，其中備份CDS可以暫時充當主CDS。圖4論述了緩存中的對象的時效。如上所述，所有構造的對象都 具有附于其的規(guī)定生存時間(TTL)或?qū)脻M日期，從而可以從緩存中 移除過期的元素，并且這些元素不會永遠保持在存儲器中。當軟件應用(400)在本地緩存中提取到過期對象(405)時，該 對象將被移除，并且因此不會將其返回給發(fā)起請求的應用。這會觸發(fā) 對中間層CDS(由負載平衡功能選擇的中間層CDS，未示出，如圖3 所述)的詢問。如果該對象存在于中心緩存中(445)并且沒有過期， 那么如先前所述，數(shù)據(jù)處理機(450)將其轉(zhuǎn)發(fā)到調(diào)用應用的本地緩 存，在本地緩存中該對象被存儲(425 )，并且將從所述本地緩存將 該對象遞送(435 )到發(fā)起請求的應用。這樣就結(jié)束了替換本地緩存 中的過期對象的處理。如果在中心緩存中很容易就可以得到被請求對 象的新拷貝，那么這^f艮可能是由以下事實導致的使用另一個本地緩 存的另一個應用已經(jīng)需要相同的對象，由此先前在CDS中已經(jīng)重建 了該對象。但是，如果情況并非如此，也就是說，如果被請求對象在中心緩 存中也過期了 (455)，那么必須重建該對象。如圖3所述，該處理是由數(shù)據(jù)處理機從數(shù)據(jù)庫(465)執(zhí)行的，該數(shù)據(jù)處理機還通過無效 處理機(460)功能來請求使過期對象無效(470)。由此，在中心緩 存中，過期對象最終被新構造的對象替換(475)，并且如圖3所示， 該新構造的對象在所有中間層CDS中被復制。在這里注意到以下一 點很重要如果向其已經(jīng)請求過期對象(455)的CDS不是主CDS， 而是備份CDS，那么作為圖3中提到的負載平衡功能進行的選擇的結(jié) 果，重建實際上并不是由備份數(shù)據(jù)處理機執(zhí)行的。更確切的說，對象 無效請求被轉(zhuǎn)發(fā)(480 )到主CDS無效處理機，從而是主CDS執(zhí)行 了重建處理并且在所有備份CDS中復制了重建的對象，由此最終更 新了包括接收到原始請求的中間層CDS的所有中間層CDS。由于重建可能是一個冗長的過程，因此，原來請求的對象隨已經(jīng) 過期(455)但仍被遞送到發(fā)起請求的本地緩存(485 )，從而使發(fā)起 請求的應用(400)不被阻塞。但是在遞送之前，對象的TTL將被設 置成非常低的值。由此，如上所述，在重建正在進行時，對象仍舊可 以用于當前請求。因此，在短的TTL屆滿之后接收到的其它請求將 使用新的重建的對象。該操作方式與本發(fā)明考慮的應用的類型相兼 容，其中，機票費用是定期更新的，但是更新時間是靈活的，這是因 為在大型網(wǎng)絡上部署一組新的機票費用無論如何都要花費很多時間。圖5描述了在數(shù)據(jù)庫(500)中修改了數(shù)據(jù)元素時緩存中對象的 無效處理。每當數(shù)據(jù)庫被其用戶(505 )(也就是負責更新和管理其 內(nèi)容的用戶)更新時就發(fā)生該處理。數(shù)據(jù)庫服務器能夠檢測哪些用于 構造對象的數(shù)據(jù)元素發(fā)生了變化。然后，確定受影響的對象的集合， 以便使這些對象無效，并且可能在中心緩存中重建這些對象。為此， 數(shù)據(jù)庫向所有CDS (也就是主CDS和備份CDS )廣播(510 )對象 無效命令，在這些CDS中，所有受影響的對象被無效(515， 525 )。在主CDS ( 520 )上，無效處理才幾(530 )首先必須判定應該刪 除還是重建無效對象。實際上，仍舊存在于中心緩存中的對象未必需 要重建。舉例來說，如果長時間沒有使用或者很少使用該對象，或者 所述對象被頻繁無效，那么無效處理機可以簡單地判定刪除該對象，從而不會無用地占用緩存存儲器，并且節(jié)省了重建所需的處理能力和 通信帶寬。該判定是根據(jù)預定義的設置而作出的。無效處理機的行為是由CDS管理員定義和設置的。然后，如果作出了刪除對象的判定，則釋放相應的緩存存儲器空 間。但是，如果無效處理機判定必須重建該對象，那么以與如圖3所 述的方式相似的方式從數(shù)據(jù)庫完成該處理。 一旦得以重建(535 )， 那么該對象在所有CDS中被復制(540)，從而可以使其同步，并且 可以從所有中心緩存(545)中得到新拷貝。無論執(zhí)行的是對象刪除還是對象重建，主CDS無效處理機都將 對象無效傳播到所有衛(wèi)星(550 )，以防止前端層服務器的軟件應用 (555)使用過時對象(560)。當軟件應用再次需要被無效對象并且 因此在本地緩存中無法得到該對象時，將會如圖3所述地從CDS中 提取對象并且可能重建該對象。此外，當完成了對象刪除或重建時，從主CDS向備份CDS通知 (570 )所述無效。如下一幅圖所述，該處理是通過管理無效處理機 使用的進展表而完成的。圖6進一步論述了被無效對象的重建。當如圖5所示必須執(zhí)行被無效對象的重建時，在CDS中將會存 在進展表(600 ),該表在接收到對象無效請求時被更新。對進行中 的操作、也就是被無效對象的重建(605 )來說，該操作被記錄在主 CDS的表(610)中并且也被轉(zhuǎn)發(fā)到備份進展表(625)。此外，被無 效的當前對象的TTL或?qū)脻M日期被變?yōu)橐粋€低值，從而如先前所述， 該對象在新對象正在被重建時仍然可用。如果該操作正常完成，那么對象會被正常重建并通過所有驗證和 檢查(640)。在這種情況下，如先前所述，該對象被轉(zhuǎn)發(fā)(615)到 備份CDS，從而在所有中心緩存中都可得到該對象。同時，進行中的 操作的記錄被從主進展表中擦除，并且也從接收到重建對象(615) 的備份CDS ( 620)的進展表中擦除。但是，這些操作未必會在沒有長期影響CDS的良好操作的情況下正常結(jié)束。要考慮的第一種情況是如下的情況例如因為沒有從數(shù)據(jù)庫正確 傳送所有必要的數(shù)據(jù)元素而沒有完整重建主CDS中的對象(630)。 必須重新嘗試重建操作，該操作的開端將被記錄在進展表(500)中。 由此，未決操作將會被監(jiān)視和定性檢查進展表的清道夫進程(635 ) 檢測到。對于進展表中記錄的未決操作，無效處理機嘗試進行的重試 次數(shù)明顯是有限制的。在正常情況下，其中的一次重試成功，并且操 作如上所述正常地繼續(xù)進行。要考慮的第二種情況是沒有將剛重建對象(610)正常地傳送到 任意數(shù)量的備份CDS。這是以與在主CDS中的方式相似的方式檢測 到的，因為備份CDS也都具有進展表(620)。因此，備份清道夫進 程檢測由于從數(shù)據(jù)庫廣播的對象無效而被記錄的未決操作。期望主 CDS重建被無效對象的備份CDS通常不會承擔任何對象重建。但是， 當清道夫進程報告了問題時，這可以由備份無效處理機(650 )例外 地觸發(fā)。在遇到這種情況時，備份無效處理機最終為其自身的緩存重 建(655 )被無效對象，暫時作為主CDS運轉(zhuǎn)。這需要從數(shù)據(jù)庫重新 傳送必要的數(shù)據(jù)元素(傳送到備份CDS)。此后，進展表的未決項可 被移除，并且受影響的備份CDS的操作可以正常地繼續(xù)進行。圖7簡要描述了本發(fā)明的可選特征。由于緩存是由其所處于的中心服務器的可用活動存儲器構造的， 因此該緩存的大小必然是有限的。因此，緩存可能變滿沒有剩余足 夠的存儲器用以構造新的被請求對象。于是，針對緩存的標準實踐是 移除最近最少使用(LRU)的對象，以為新對象騰出空間。其它替換 算法也可以應用。無論使用哪種算法，近來未使用的選擇要移除的對 象可能仍然是有效對象，也就是說，該對象并未過期。如已經(jīng)指出的， 根據(jù)本發(fā)明的對象是需要用服務器中央處理器(CPU)的極大處理能 力來構造并且還需要多次訪問后臺數(shù)據(jù)庫(700)的復雜對象。因此， 對象重建是昂貴的，如果對象在從緩存中移除時沒有過期，那么應該 避免丟棄該對象。在主CDS( 720 )或任一備份CDS( 730 )中的中心緩存已滿(760 )， 并且例如要移除的LRU對象已被選擇(770)的時候，如果該對象沒 有過期(792 )，那么可以將該對象存儲(775)到易于從服務器訪問 的輔助存儲器(740， 750)中，而不是將其丟棄(780)。但是，如 果對象過期(794 ),則必須丟棄該對象。輔助存儲器通常是來自附 于服務器的硬盤的專用存儲空間。因此，可以避免未過期對象的重建。 為了這樣做，CDS追蹤存儲在輔助存儲器中的對象。當應用再次需要 其中的一個對象時，從相應的輔助存儲器中取回該對象，而不是重建 該對象。如果搜索不成功，或者如果該對象由于被存儲在輔助存儲器 中而過期，那么相同的機制也適用，也就是說，LRU對象被從緩存中 移除以便為被請求對象騰出空間，在重建該被請求對象之前首先在輔 助存儲器中進行搜索。
權利要求
1.一種用于保持多層軟件架構中的緩存內(nèi)容的一致性的方法，所述架構包括前端層(220)，該前端層包含至少一個衛(wèi)星服務器，所述至少一個衛(wèi)星服務器中的每一個都操作本地緩存(230)，所述架構包括中間層(210)，該中間層包含至少一個中心服務器(212)，每個所述至少一個中心服務器都操作中心緩存(216)，并且每個所述至少一個中心服務器都通過至少一個數(shù)據(jù)庫服務器(202)而與至少一個數(shù)據(jù)庫(204)對接，所述至少一個數(shù)據(jù)庫包含數(shù)據(jù)元素(360)，所述數(shù)據(jù)元素是用從每個所述至少一個中心服務器發(fā)送到所述至少一個數(shù)據(jù)庫服務器的查詢來檢索的，所述方法包括以下步驟在所述至少一個中心服務器中從來自所述至少一個數(shù)據(jù)庫的至少一個所述數(shù)據(jù)元素中構造(350)對象，所述構造步驟還包括以下步驟驗證所述對象；向所述對象賦予生存時間(TTL)；以及將所述對象存儲在所述中心緩存(340)中；將所述對象從所述中心緩存轉(zhuǎn)發(fā)(330，370)到請求所述對象的任意所述衛(wèi)星服務器，所述轉(zhuǎn)發(fā)步驟還包括以下步驟將所述對象存儲在所述本地緩存中；將所述對象遞送(335，375)到在所述衛(wèi)星服務器上運行并且請求所述對象的那些軟件應用。
2. 根據(jù)權利要求1所述的方法，其中，來自所述衛(wèi)星服務器的 請求被在所有可用的所述中心服務器上進行負載平衡(385)，并且 其中，對于每個請求，選擇所述中心服務器之一。
3. 根據(jù)權利要求1或2所述的方法，其中，所述構造步驟還包 括以下步驟在所有其它所述中心服務器中復制(380 )來自所述選 擇的中心服務器的新構造對象(355)。
4. 根據(jù)權利要求1或2所述的方法，其中，每當對象在所述本 地緩存中未找到(320, 350 )或者過期(405 )時，從所述選擇的中 心緩存(340)請求該對象。
5. 根據(jù)權利要求1或2所述的方法，其中，每當被請求對象在 所述選擇的中心緩存中未找到(355)時，在所述選擇的中心服務器 中觸發(fā)所述構造步驟(350)。
6. 根據(jù)權利要求1或2所述的方法，其中，用以下步驟替換賦 予TTL的步驟和存儲所述對象的步驟如果先前的所述驗證步驟未 能驗證所述對象，則拒絕所述對象(357)。
7. 根據(jù)權利要求1或2所述的方法，其中，每當被請求對象已 經(jīng)存在(345)于所述中心緩存中并且沒有過期(445)時，在所述選 擇的中心服務器中跳過所述構造步驟(350， 450)。
8. 根據(jù)權利要求1至7中任一項所述的方法，其中， 一個所述 中心服務器被指定為主中心服務器(340 )，并且所有其它中心服務 器是備份中心服務器。
9. 根據(jù)權利要求1至8中任一項所述的方法，其中，每當在所 述選擇的中心服務器中發(fā)現(xiàn)所述被請求對象過期(455 )時，由無效 處理機(460)在所述主中心服務器(480)中觸發(fā)所述構造步驟。
10. 根據(jù)權利要求9所述的方法，其中，在將所述過期對象(455 ) 的TTL轉(zhuǎn)發(fā)(485 )給發(fā)起請求的衛(wèi)星服務器之前，所述過期對象(455 ) 的TTL被設置成一個低值。
11. 根據(jù)前述權利要求中任一項所述的方法，其中，在所述數(shù)據(jù) 庫中用于構造所述對象(500)的至少一個所述數(shù)據(jù)元素一經(jīng)修改， 就使存儲在所述中心緩存和所述本地緩存中的對象無效，所述方法包 括以下步驟確定哪些對象受到影響；向所述中心服務器的所有無效處理;f幾廣播無效命令(510); 使所述中心緩存中的相應對象(515)無效； 將所述無效命令(550 )傳播到所有所述本地緩存； 使所述本地緩存中的相應對象(560 )無效，所述無效步驟還包 括以下步驟刪除所述對象。
12. 根據(jù)權利要求11所述的方法，其中，使所述中心緩存中的對象無效的步驟還包括以下步驟刪除所述對象。
13. 根據(jù)權利要求12所述的方法，其中，用在所述主中心服務 器(520 )中重建所述對象(535 )的步驟來替換刪除所述對象的步驟， 所述方法還包括以下步驟將所述重建的對象復制(540 )到所有所 述備份中心服務器中。
14. 根據(jù)前述權利要求中任一項所述的方法，其中，每個所述中 心服務器都包括對象重建進展表(600 )和用于從所述進展表中監(jiān)視 所述對象重建的清道夫進程(635)，所述方法包括以下步驟在所述進展表(610)中記錄對象重建的開端和末端； 檢查所述進展表(635)以檢測所述對象重建的完成，所述方法 還包括以下步驟擦除已成功完成的對象重建的表條目； 檢測失敗的進行中的對象重建； 重新嘗試失敗的對象重建。
15. 根據(jù)權利要求14所述的方法，其中，所述對象重建是在所 述主中心服務器中執(zhí)行的，并且其中，所述記錄步驟還包括以下步驟 將對象重建開端(625 )轉(zhuǎn)發(fā)給備份中心服務器的所有所述進展表。
16. 根據(jù)權利要求15所述的方法，其中，當接收到(615)從主 中心服務器轉(zhuǎn)發(fā)的對象時，對象重建末端被記錄在備份中心服務器的 所述進展表中。
17. 根據(jù)權利要求14所述的方法，其中，所述檢測步驟和所述重新嘗試步驟是在所述備份中心服務器之一中執(zhí)行的。
18. 根據(jù)權利要求1所述的方法，其中，所述構造步驟包括以下 預備步驟檢查所述中心緩存是否已滿；如果未滿，則立即前進到所述構造 步驟；如果已滿(760 )，則在所述中心緩存中選擇LRU對象(770); 以及檢查所述LRU對象是否已過期；如果沒有過期(792 )，則將所 述LRU對象存儲在輔助存儲器中(775);如果已過期(794)，則 丟棄(780 )所述LRU對象；并且在這兩種情況下都前進到所述構造
19.根據(jù)權利要求13所述的方法，其中，在前進到所述重建步 驟之前，在所述輔助存儲器(720)中進一步搜索所述未找到對象。
20. —種用于保持服務器的多層架構中的緩存內(nèi)容的一致性的系 統(tǒng)，所述系統(tǒng)包括適于執(zhí)行根據(jù)權利要求1至19中任一項所述的方 法的各步驟的裝置。
21. 權利要求20所述的系統(tǒng)，該系統(tǒng)包括用于使用來自至少 一個數(shù)據(jù)庫的數(shù)據(jù)元素來構造對象(350 )的裝置；用于在所述數(shù)據(jù) 對象過期(450 )時使其無效的裝置，以及用于管理所述過期對象(500， 535)的重建的裝置。
22. —種存儲在計算機可讀存儲介質(zhì)上的計算機程序產(chǎn)品，該產(chǎn) 品包括計算機可讀代碼裝置，該計算機可讀代碼裝置使至少一個計算 機運行根據(jù)權利要求1至19中任一項所述的用于保持多層軟件系統(tǒng) 中的緩存內(nèi)容一致性的方法。
全文摘要
本發(fā)明涉及用于保持旨在與大型數(shù)據(jù)庫對接的多層軟件系統(tǒng)中的緩存內(nèi)容的一致性的系統(tǒng)和方法。描述了一種用于保持服務器的多層架構中的緩存內(nèi)容的一致性的方法和系統(tǒng)。該架構包括衛(wèi)星服務器組成的前端層，每個衛(wèi)星服務器都操作一個本地緩存；和中心服務器組成的中間層，每個中心服務器都操作一個中心緩存執(zhí)。中心服務器通過數(shù)據(jù)庫服務器與數(shù)據(jù)庫對接以檢索用于構造對象的數(shù)據(jù)元素并且將其存儲在中心緩存中。一旦構造了對象，對象就被賦予生存時間(TTL)并且被存儲在中心緩存中，然后被轉(zhuǎn)發(fā)到衛(wèi)星服務器，在衛(wèi)星服務器中，在被遞送到請求這些對象的軟件應用之前，這些對象被存儲在本地緩存中。當對象過期時，使這些對象無效并從中心服務器重建這些對象，從中心服務器將這些對象轉(zhuǎn)發(fā)到所有中心緩存以及需要這些對象的本地緩存。
文檔編號H04L29/08GK101278540SQ200680036625
公開日2008年10月1日 申請日期2006年9月27日 優(yōu)先權日2005年10月3日
發(fā)明者B·雅南, L·伊斯納爾迪, R·戈萊, R·達尼埃羅, W·魯本施泰因 申請人:阿瑪?shù)盟箖珊瞎?