|
http://dev.csdn.net/Develop/article/27/27107.shtm
框架的主要原理
緩存屬性
我們將所有的緩存參數配置在名為cache.ccf的屬性文件中。這些參數包括緩存信息如：內存中存儲的對象的最大數量，緩存時間（過了時間之后緩存的數據九自動從內存中釋放），中斷時間（elapsed time since last access time）， 內存緩存名稱（例如：緩存算法如LRU或MRU）等。在當前版本的JCS中，緩存屬性文件是純文本格式的。SpiritCache framework，一種來自SpiritSoft的Jcache API商業實現，支持XML格式的緩存配置。
確認該屬性文件存放在類路徑中。注意：如果你需要使用其它不同的文件來存放緩存屬性的話，JCS 也提供了方法來指定一個配置文件的名稱。請參考JCS的 Javadocs 學習如何從其它非缺省的屬性文件中讀取緩存配置信息。
下面列出來的是web應用使用緩存功能需要了解的一些Java類。這些類存放在本文的示例代碼的common.caching包中。這些類的Javadocs也包括在源代碼壓縮包中。 （圖2 中的類圖顯示了這些Java類的關系）
ICacheManager
這是客戶應用實現所有緩存有關操作（如：存儲、訪問以及釋放緩存中的數據）的主接口（契約）。客戶程序可以是JSP、Struts Action類，或者就是一個POJO對象。創建該接口用于對客戶端隱藏所有緩存的實現細節，這樣當我們將來需要切換另一種的第三方緩存API的時候無需對客戶端代碼做任何調整。
BaseCacheManager
這是web門戶緩存框架的主類。是對ICacheManager 接口的最基本實現。創建BaseCacheManager 用于在一個類中集中所有緩存相關的方法。它被設計為單例模式保證在servlet容器的JVM中有且僅有一個ICacheManager 的實例被創建。在多web服務器/servlet容器實例共同處理web請求的集群環境中，每個JVM將會創建獨立的ICacheManager 實例。如果將來你要轉換到不同的緩存API ，這是唯一需要為新的緩存API修改的類。如果你切換到JCache-兼容的緩存實現，對緩存管理器的修改將會是很小的。
ICacheLoader
該接口用于在web客戶端實現真正的數據訪問邏輯。所有需要使用緩存機制的客戶端應用必須實現該接口。它包括僅有的一個方法叫做loadCacheObject() ，有兩個輸入參數：一個String參數制定緩存區域名稱，一個對象參數制定緩存鍵值。這樣，緩存管理器將知道在緩存的對象超過指定的“生存時間”的時候，使用哪個客戶端程序（運行loadCacheObject 方法）來重載緩存中的對象 。
ICacheKey
ICacheKey 接口創建的目的是為了隱藏特定的創建緩存鍵值的細節。有時候緩存的鍵值不是一個簡單的字符串。它可能像多個對象組合起來一樣復雜，從數據源獲取這些值需要多個查找方法而不是單一的方法。在這種情況下， ICacheKey 接口可以被用來定義創建緩存鍵值的所有復雜的邏輯。這樣，緩存鍵值創建邏輯將會被定義為獨立的類。我編寫了一個簡單的類TestCacheKey 實現了該接口并實現了getCacheKey() 方法來演示使用該接口的方法。
CacheRegions:
一個 緩存區域 被定義為一個組織起來的命名空間用于容納一組緩存對象集合。你需要在配置文件中定義緩存區域來實現在一塊單獨的內存空間中存儲數據，管理緩存數據的有效期限。如果需要的話，對有相似特征的對象（例如：生存時間和業務用途）應該被緩存在相同的緩存區域中，讓它們可以在相同的時間失效。我定義了分離的緩存區域來存儲靜態數據和小變動數據。為了避免同步操作帶來的效率影響，我對每個緩存區域使用了單獨的Cache (JCS) 實例。
CacheElementInfo
該類用于封裝所有的緩存統計信息（例如：命中數、不中數、命中比例等），用來監測在web應用中所有緩存對象的效率。
編譯, 構建, 和單元測試
我用Ant創建了一個構建腳本來編譯我的對象緩存框架的所有代碼。Ant的構建腳本build.xml, 放在WEB-INF\classes 目錄下。我還編寫了Junit測試客戶端來測試使用web門戶緩存框架的不同緩存場景。測試腳本CachingTestCase, 放在WEB-INF\classes\common\caching\test 目錄下。解壓縮示例代碼到一個新的web應用目錄，如果要驗證Junit測試腳本，從命令行運行以下命令：
切換當前目錄到%TOMCAT_HOME%/webapps/web-app-name/WEB-INF/classes （在Unix測試環境中，目錄應該是$TOMCAT_HOME/webapps/web-app-name/WEB-INF/classes）。
運行以下命令：
- ant common.compile
編譯緩存框架中所有的Java類。
- ant common.runjunit
用于運行Junit測試腳本。測試腳本使用Log4J API來顯示所有的輸出信息。
考慮何時使用對象緩存的指導方針
當你決定要在你的web應用中緩存一些特定類別的數據的時候，請參照這些指導方針。緩存的應用應該經過謹慎地考慮，只有當其它方法，如：數據訪問等，已經無法再進一步改進的時候才需要使用緩存。緩存將會帶來復雜性，讓維護工作變得更加復雜。因此，必須統籌考慮性能和緩存帶來的復雜性的平衡關系。
當考慮使用緩存的時候，需要考慮對象的預定執行時間和刷新率或者叫做對象的生存時間。緩存不能容納所有我們想要存儲的數據，因此緩存使用的內存及時得到釋放，即可以通過定義合理的生存時間實現，也可以在數據不再需要的時候顯式地釋放被緩存的對象。可以指定緩存算法如最近被訪問算法（LRU）或者最少被使用算法（LFU）以便緩存基于訪問頻率來釋放對象。Jack Shirazi的著作 Java 性能調整 提供了一個關于緩存主題的非常有趣的討論，討論了什么類型的數據應該被緩存，以及何時使用緩存的建議。
注意緩存框架并沒有處理在web應用中需要被緩存的對象的創建（例如：從數據源檢索數據的數據訪問邏輯并沒有在緩存類中編寫）。這要依賴于客戶程序來定義真正的數據訪問邏輯。像Java數據對象等技術通常用于在企業級web應用中封裝數據訪問邏輯。參考O'Reilly的 Java 數據對象 來學習更多的關于如何將數據訪問層與業務邏輯層分離的知識。
結論
本文提供了對使用Jakarta的Java緩存系統（JCS）來為web門戶應用開發對象緩存框架的概要介紹。該框架非常穩定并可以被重用于其它任何web應用，甚至可以用于客戶/服務器模式的Java應用程序。本文詳細介紹了web門戶緩存框架的工作原理，并提供了Junit測試腳本來對不同場景的緩存框架進行測試。
JCS was built as a system close to JCACHE Java Temporary Caching API (JSR-107), a description of the caching system used in Oracle 9i and other popular caching frameworks. 該規范可能會在將來的JDK發行版本中作為一種Java擴展框架。我的其中一個目的就是讓web門戶緩存框架與JCS保持松散耦合。這樣的話，如果我將來需要轉換到另一種框架（例如Jcache），我可以在對web門戶應用客戶程序代碼不做大的調整的情況下完成切換。
我現在通過記錄緩存監測信息的日志（使用Log4J API）如：命中數、不中數、命中率來衡量緩存的效率。可能將來有其它參數需要被監測來衡量緩存的效率。同樣的，用來測量使用或不使用緩存對數據訪問的反饋時間，應該使用一些負載測試工具如：Grinder或者Jmeter來測試其伸縮性和性能效果。
在機群環境下保持緩存同步將是一個挑戰，因為每個servlet容器將會在自己的JVM中擁有一個緩存管理器實例。解決該問題的方法就是創建消息驅動Bean（MDB）在需要刷新數據的時候通知所有的緩存管理器。
通常的對象查找方法，如：簡單的Hashtable、JNDI甚至是EJB，提供了在內存中存放對象并通過鍵值查找對象的方法。但是任何一種方法都沒有提供當對象不需要的時候從內存中移出的機制，或者當訪問對象遲于對象存放期限的時候自動創建對象的機制。HttpSession 對象 (in the servlet package) 也允許對象被緩存，但是它沒有共享、失效、單一對象存放期滿、自動裝載或者spooling 這些緩存框架需要具備的基礎機制。
雖然將緩存功能集成到web應用中需要額外的設計和開發工作，但我認為緩存帶來的利益大于額外付出的工作。我已經看到在我實現了緩存框架之后 ，我的web應用的性能有很大的提高，特別是在訪問靜態數據和查找結果方面。該web應用模塊目前處于測試階段。在不久的將來，我會提供一些性能方面的測試數據（包括使用與不使用緩存的情況）來比較緩存如何幫助設計更快、更具伸縮性的web應用。
示例代碼
參考資源
Srini Penchikala 是一名軟件咨詢顧問，當前為Computer Consultants of America, Inc. 工作。 |