iBATIS緩存介紹

1.1緩存對象

理論上，Web分層設計的各個層都可以有緩存，Web中的任何對象都可以緩存。

Http請求結果的緩存

瀏覽器緩存、代理緩存、服務器端方向代理緩存、使用Filter實現對請求結果頁面的緩存

Java對象的緩存

緩存數據庫查詢結果對象

1.2緩存介質[保存在哪裏]

從硬件介質上來將無非就是兩種,內存和硬盤(對應應用層的程序來講不用考慮寄存器等問題).但是往往我們不會從硬件上來劃分,一般的劃分方法是從技術上劃分,可以分成幾種,內存,硬盤文件.數據庫.

1.2.1內存

將緩存放在內存中是最快的選擇,任何程序直接操作內存都比操作硬盤要快的多,但是如果你的數據要考慮到break down的問題,因爲放在內存中的數據我們稱之爲沒有持久話的數據,如果硬盤上沒有備份,機器down機之後,很難或者無法恢復.

1.2.2硬盤

一般來說,很多緩存框架會結合使用內存和硬盤,比如給內存分配的空間有滿了之後,會讓用戶選擇把需要退出內存空間的數據持久化到硬盤.當然也選擇直接把數據放一份到硬盤(內存中一份,硬盤中一份,down機也不怕).也有其他的緩存是直接把數據放到硬盤上.

1.2.3數據庫

說到數據庫,可能有的人會想,之前不是講到要減少數據庫查詢的次數,減少數據庫計算的壓力嗎,現在怎麼又用數據庫作爲緩存的介質了呢.這是因爲數據庫又很多種類型,比如berkleydb,這種db不支持sql語句,沒有sql引擎,只是key和value的存儲結構,所以速度非常的快,在當代一般的pc上,每秒中十幾w次查詢都是沒有問題的.

1.3命中率

命中率是指請求緩存次數和緩存返回正確結果次數的比例.比例越高,就證明緩存的使用率越高.

命中率問題是緩存中的一個非常重要的問題,我們都希望自己緩存的命中率能達到100%,但是往往事與願違,而且緩存命中率是衡量緩存有效性的重要指標.

1.4最大保存元素數量

緩存中可以存放得最大元素得數量,一旦緩存中元素數量超過這個值,那麼將會起用緩存清空策略,根據不同的場景合理的設置最大元素值往往可以一定程度上提高緩存的命中率.從而更有效的時候緩存.

1.5緩存更新策略

1.5.1 FIFO[first in first out]

最先進入緩存得數據在緩存空間不夠情況下(超出最大元素限制時)會被首先清理出去

1.5.2 LFU[Less Frequently Used]

一直以來最少被使用的元素會被被清理掉。這就要求緩存的元素有一個hit 屬性，在緩存空間不夠得情況下,hit 值最小的將會被清出緩存。

1.5.3 LRU[Least Recently Used]

最近最少使用的，緩存的元素有一個時間戳，當緩存容量滿了，而又需要騰出地方來緩存新的元素的時候，那麼現有緩存元素中時間戳離當前時間最遠的元素將被清出緩存。

1.6本地緩存VS遠程緩存

Local Cache：本地緩存

RemoteCache：遠程緩存

Local Cache最大的優點是應用和Cache的時候是在同一個進程內部,請求緩存非常快速,完全不需要網絡開銷等.所以單應用,不需要集羣或者集羣情況下cache node不需要相互通知的情況下使用local cache比較合適.

但是Local cache是有一定的缺點的,一般這種緩存框架都是local cache.也就是跟着應用程序走的,多個應用程序無法直接共享緩存,應用集羣的情況下這個問題更加明顯,當然也有的緩存組件提供了集羣節點相互通知緩存更新的功能,但是由於這個是廣播,或者是環路更新,在緩存更新頻繁的情況下會導致網絡io開銷非常大,嚴重的時候會影響應用的正常運行.而且如果緩存中數據量較大得情況下使用local cache意味着每個應用都有一份這麼大得緩存,着絕對是對內存的浪費.

所以這個情況下,往往我們會選擇remote cache,.這樣集羣或者分佈式的情況下各個應用都可以共享memcached中的數據,這些應用都通過socket和基於tcp/ip協議上層的memcached協議直接連接到memcached,有一個app更新了memcached中的值,所有的應用都能拿到最新的值.雖然這個時候多了很多了網絡上的開銷,但是往往這種方案要比localcache廣播或環路更新cache節點要普遍的多,而且性能也比後者高.由於數據只需要保存一份,所以也提高了內存的使用率.

二．iBATIS高速緩存介紹

2.1iBATIS高速緩存的關注點

iBATIS高速緩存只關注如何在持久層對查詢結果進行緩存。

2.2iBATIS對高速緩存管理的幫助

iBATIS帶來的好處就是通過配置文件來管理高速緩存，幫助避免因手工管理高速緩存結果及其依賴性而造成的大量繁瑣的工作。

2.3iBATIS高速緩存和傳統O/RM高速緩存的區別

iBATIS的思想是建立SQL語句到對象的映射，而不是建立數據庫表到對象的映射。傳統O/RM工具主要關注數據庫表到對象的映射。

傳統的O/RM高速緩存會爲其管理的每個對象維護一個OID[objectidentification，對象標識]，就像數據庫需要管理其表中的每條記錄的唯一性一樣。這意味着，如果兩個不同的結果都返回同一個對象，那麼該對象將只被高速緩存一次。

iBATIS不這樣，關注的是SQL語句的執行結果，我們不會根據對象的唯一性來高速緩存它們iBATIS高速緩存的所有結果，而不考慮所標識的對象是否存在於高速緩存中。

三．配置iBATIS緩存

3.1cacheModel標籤

cacheModel標籤用來配置iBATIS的高速緩存，cacheModel標籤的屬性包括四個

3.1.1 cacheModel標籤的屬性

l id[必需]

該值用來指定一個唯一的ID，便於爲需要使用此高速緩存模型所配置的高速緩存的查詢已映射語句使用。

l type[必需]

此屬性用於指定高速緩存所配置的高速緩存的類型。其有效值包括MEMORY LRU FIFO OSCACHE，該屬性也可取值爲某個自定義CacheController實現的全限定名。

l readOnly[可選]

取值爲true時表示高速緩存將僅僅用作只讀緩存，從只讀高速緩存中讀出的對象的特性值不允許修改。

l serialize[可選]

該屬性用於指定在讀取高度緩存內容時是否要進行“深複製”

readOnly、serialize屬性經常聯合起來使用。

3.1.2 聯合使用readOnly和serialize屬性

readOnly	seralize	結果	原因
true	false	好	可以最快地檢索出已高速緩存對象。返回已高速緩存對象的一個共享實例，若使用不當可能會導致問題
false	true	好	能快速檢索出已高速緩存對象。返回已高速緩存對象的一個深副本
false	false	警告	對於此組合，高速緩存僅僅同調用線程的會話的生命週期相關，且不能被其他線程所使用
true	true	壞	這種組合同readOnly=false&serialize=true的組合作用一致，否則它在語意上無任何意義

【表1】聯合使用readOnly和serialize屬性

【備註】默認組合是readOnly=true&serialize=false

3.2iBATIS高速緩存模型的類型

3.2.1 MEMORY

MEMORY高速緩存是一種基於引用的高速緩存（參考java.lang.ref）。高速緩存中的每個對象都被賦予一個引用類型，此引用類型爲垃圾收集器提供了線索，指導它如何處理相應的對象。

MEMORY高速緩存模型對於那些更關注內存的管理策略而不是對象的訪問策略的應用程序而言是完美的。有了STRONG、SOFT、WEAK這三種引用類型，就可以確定哪些結果應該比其他結果保留更長的時間。

值	含義
WEAK	WEAK應用類型將很快地廢棄已高速緩存的對象。這種引用類型不會阻止對象被垃圾收集器收集。它僅僅提供一種方式來訪問高速緩存的對象，該對象在垃圾回收器的第一遍收集就會被移除。這是MEMORY的默認的引用類型，如果保存在高速緩存中的所有對象都會以非常一致的方式被訪問，那麼使用這種類型就非常合適。由於高速緩存對象被廢棄的速度比較快，可以確保你的高速緩存不會超過內存限制。然而，使用這種引用類型時，數據庫訪問的頻率會很高。
SOFT	SOFT引用類型也適合於那些將滿足內存約束看的很重要，必要時就會放棄高速緩存對象的情況。這種引用類型在滿足內存約束的情況下，將盡可能地保存已高速緩存對象。此時，垃圾收集器始終不會收集對象，除非確定需要更多的內存。SOFT引用也確保不會超過內存限制，並且和WEAK類型相比，其數據庫訪問頻率會低一些。
STRONG	STRONG引用類型不管內存約束，其中的已高速緩存對象永遠不會被廢棄，除非到達了指定的清除時間間隔。STRONG類型的高速緩存應該用於存放那些靜態的小對象，並且對這些小對象的訪問應該有一定規律。這個引用類型可以通過減少數據庫訪問頻率提高性能，但當高速緩存中的數據越來越多時存在內存耗盡的風險。

【表2】MEMORY高速緩存reference-type屬性取值及對應含義

3.2.5自定義高速緩存模型

只需要實現com.ibatis.sqlmap.engine.cache.CacheController接口即可，配置時設定type爲全限類名或其別名即可。

3.3高速緩存的清除

使用flushOnExecute、flushInterval標籤可以定義清空緩存觸發條件

標籤名稱	用途
<flushOnExecute>	定義查詢已映射語句，其執行將引起相關高速緩存的清除
<flushInterval>	定義一個時間間隔，高速緩存將以此間隔定期清除

【表3】<flushOnExecute>、<flushInterval>標籤

屬性	描述
hours(可選)	每次清除高速緩存前應該經過的小時數
minutes（可選）	每次清除高速緩存前應該經過的分鐘數
seconds（可選)	每次清除高速緩存前應該經過的秒數
milliseconds（可選）	每次清除高速緩存前應該經過的毫秒數

【表4】<flushInterval>標籤屬性

3.4設置高速緩存模式實現的特性

由於高速緩存模型只是一些可以插入到iBATIS框架的組件，它甚至允許用戶自己定製，因此必須有一種方式能爲這些組件提供任意的值。<property>標籤就是用來完成此任務的。

屬性	描述
name（必需）	所設定的特性的名稱
value（必需）	所設定的特性的值

【表5】<property>標籤的屬性

3.5常見問題

3.5.1如何選擇iBATIS高速緩存模型類型

如何選擇一個適合實際應用情況的高速緩存模型類型是一個很負責的問題，需要考慮諸多因素。

需要考慮的因素：

1.當前應用程序是否是數據庫的唯一操作入口

2.讀寫屬性

3.緩存時間間隔

4.失效控制

5.最大保存對象數目

舉例：

1.只讀的長效數據

購物車中的物品類別－－LRU

緩存只讀的長效數據可以明顯地提升訪問效率，如果使用LRU高速緩存模型，記得不要將其size屬性值設置過大，否則就變成了STRONG類型的MEMORY高速緩存。

2.可讀寫數據

根據對象的更新頻率選擇是否需要對其進行緩存

3.舊的靜態數據

每小時內顧客購買的最多5件產品－－FIFO

需要多找一些例子，讓大家進行討論和選擇；另外需要在實際應用中找到驗證所選擇的緩存模型類型是否是最佳方案的方式。

場景	適合緩存模型類型	原因
翻頁	LRU	......

【表6】iBATIS高速緩存模型類型選擇討論示例表格

3.5.2如何手工強制清除iBATIS高速緩存中保存的對象

SqlMapClient接口提供了相關的方法：

publicvoid flushDataCache()

publicvoid flushDataCache(StringcacheId)

分別用來清空所有緩存內容及指定ID的緩存內容，先獲取到SqlMapClient接口具體實現的實例，然後就可以進行相關操作。

3.5.3 OSCACHE基本使用及配置項說明

【待完善】

四．參考資料

《iBATIS實戰》第9章，使用高速緩存提升性能

論緩存之第一<道>

http://www.javaeye.com/topic/345693

論緩存之第二<近與快>

http://www.javaeye.com/topic/348671

IBatis中的強制刷新緩存

http://blogger.org.cn/blog/more.asp?id=32349&name=lhwork