緩存是在提升系統響應時常用的一種技術，在我之前的blog中也提及過好幾次這部分的技術，今天還是想從緩存涉及的一些方面再次的去談談，在系統緩存上通常采用的是有頁面緩存、處理緩存和數據緩存這三種具體的類別，應該說這三種緩存在實現上還是稍有不同，盡管底層的緩存實現是一樣的。
頁面緩存
頁面緩存是指對頁面中的內容片斷進行緩存的方案。比如頁面中有一個部分是顯示欄目中的內容的，那么就可以緩存這個部分，在進行第二次請求的時候就直接從緩存中取出這部分的內容(其實就是這部分的html了)，這種情況下，緩存的作用其實非常明顯，在典型的action+service+dao這樣的結構中，在采用頁面緩存后就意味著不需要經過action、service、dao這些層次的處理了，而是直接就返回了，對于系統響應速度的提升來說是非常明顯的。
頁面緩存通常采用oscache來進行實現，oscache提供了一個jsp tag，可通過這個tag來包含需要緩存的內容部分，當然，緩存的這個內容部分需要有對服務器的請求或邏輯計算等的，可想而知，去緩存一段靜態html是沒有意義的。
其次需要定義緩存的這段內容的key，例如我們要去緩存頁面中某個欄目的某頁的內容，對于這段內容而言唯一的key就是欄目ID以及當前頁數，這樣就組成了這段緩存的key了，其實這個部分看起來好像是很簡單，但有些時候會很麻煩，要仔細的想清楚這段內容的唯一的標識的key到底是什么，^_^，通常的做法其實可以從action中需要獲取的參數或service接口的參數來決定....
頁面緩存中還需要做的一個步驟就是通知緩存需要更新，頁面緩存和其他緩存稍有不同，需要告訴它，這個時候不能再使用緩存中的內容了，需要從后臺再重新獲取來生成新的緩存內容，這個其實很簡單，因為很難在后臺發生變化的時候自己來更新緩存的內容，只能是去通知它，然后讓它再次發起請求來生成新的內容放入緩存中。
頁面的緩存的使用對于系統的響應速度確實會有很大的提升，在實現頁面緩存時最麻煩的主要是緩存的key的定義以及緩存更新的通知，緩存key的定義這個自然框架是沒法解決的，不過緩存更新的通知其實在框架中可以考慮一種通知模型的，^_^，就像事件通知那樣........在實際的項目中，可以自己去實現一個這樣的通知模型或者就是簡單的采用單例方式來標識某個key是否需要更新。
頁面緩存在實際的項目中使用非常的多。
處理緩存
處理緩存是指對于action、service、dao或者系統層次中的某方法進行緩存，說直接點，就是對某個類的某個方法的結果做緩存，這樣在下次進行完全相同的請求的時候就可以直接取緩存了，這種響應速度的提升也是非常明顯的。
處理緩存在現在的情況下其實采用任務的緩存工具包都可以實現，如oscache、ehcache、jbosscache等，但目前還沒有處理緩存框架的出現，這個和處理緩存是否應該存在的意義也是有關系的，處理緩存框架要做到的其實就像攔截一樣的方式，和oscache tag類似。
同樣，處理緩存的麻煩也在于怎么樣去定義這個key，很多情況下可以根據方法的輸入作為key，方法的輸出作為key的值，但也會有其他一些復雜的情況，這個時候定義key就會變得復雜些了。
處理緩存同樣有通知更新緩存的情況，和頁面緩存基本是一樣的。
應該說，處理緩存和頁面緩存非常的相似，從實現上來說基本是完全一致的，在使用上來講處理緩存使用的好像不多。
數據緩存
數據緩存估計大家都很熟悉，就是對系統的數據進行緩存的方式，典型的就是Hibernate的一級、二級數據緩存。
數據緩存在實現上如果是用hibernate的話更多的是直接使用hibernate的一級、二級以及查詢緩存，如果自己要實現的話可以去參考hibernate的實現機制。
數據緩存的key在一級、二級緩存中采用的都是數據的標識鍵的值的方式，查詢緩存采用的是查詢參數、查詢語句的方式。
數據緩存的更新則是hibernate在進行存儲時直接更新緩存的內容，而對于查詢緩存則是采用全部直接清除的方式，這樣在下次進行查詢時自然會重新去查詢，^_^，大家可能會想，為什么頁面緩存和處理緩存不采用這樣的方式來實現緩存的更新，稍微想想就知道了，在后臺發生改變的時候其實是不知道需要移除哪些key的，所以hibernate為了避免這個麻煩，采用的就是當數據一旦發生改變的時候就清除全部的查詢緩存，而不是只去清除相關的緩存，其實這里可以采用一種訂閱式的模型，呵呵，當然，也增加了框架的復雜度。
數據緩存使用的應該是最多的，效果也是很明顯的。
以上三種緩存是目前緩存實現時通常碰到的三種狀況，里面按使用的多少來排序應該是：數據緩存、頁面緩存和處理緩存；實現的難度上從難到易的順序應該是：處理緩存、頁面緩存、數據緩存；對于系統響應速度提升的效果來說從最好到好的順序應該是：頁面緩存、處理緩存、數據緩存。