這次，我將要涉及到一個非常重要的概念：快取。在當今的web應用中，如果沒有設計一個比較好的快取系統，在web中就不可能有一個良好的效能。所以我將要

提到的快取不僅僅能夠更好地理解Liferay架構，而且還會比較好地幫助我們去寫其他的Java Web應用，尤其是在他們比較大的時候。

    Liferay以提供了優良效能(可以參考這篇效能白皮書)著稱，而它的快取系統是實現優良效能的關鍵因素。它的快取系統貫穿了Liferay的三層(前端，service層，持久化層)

下圖顯示了每層主要的快取元件:

讓我們一層一層地來看看cache的應用，先從最底層開始：

    在持久化層，Liferay依賴Hibernate去完成它訪問資料庫的大部分工作。Hibernate有兩層快取結構，分別是Level1(L1) 和Level2(L2).Level1被用作cache

從當前資料庫會話獲取的物件，在這種情況下，資料庫的的一個會話會與Liferay的 Service層的一個呼叫捆綁起來。所以，當前端(或者一個 Web Service)

呼叫service,一個數據庫的會話將被開啟，而且會被重用一直到這個Service方法呼叫return。所有對DB的操作將會共享L1 cache, 所以獲取同樣的物件將只會

查詢一個DB.

   Hibernate的第二層cache, Level 2 可以用來擴張DB 會話和 儲存資料庫物件(Entity Cache)和查詢的結果(Query Cache).舉個例來說，如果屬於一個組織

(organization)的某一個使用者呼叫了從DB獲取物件的方法，那麼這時這些被查詢出來的物件就會被存在快取中。不過值得注意的是，真正存在快取裡的是存在

實體快取(Entity Cache)物件們的引用列表。這樣是為了確保在快取中，同一個物件在快取系統中只有一個。

    除了用Hibernate,Liferay也可以自定義SQL語句用來直接查詢一些比較複雜的結果(通過重用DB的連線)。針對這些，Liferay也有自己的實體和查詢快取

(Entity Cache and Query Cache，不過目前我好像如果通過自己寫SQL查詢的話，沒有用到快取？).實質上，在Liferay 6.2的版本中，由於Shuyang（Liferay創始人之一）

的努力，這兩種快取已經被高效地實現了。Hibernate的L2 cache將會預設地被關閉，Liferay自己的查詢快取系統將會取代它。

    最後比較重要的一點是，以上的cache都是通過一種底層的快取池來管理在記憶體中的物件的，Liferay預設用ehcache來實現這一點，但是這也可是改變的，

我們可以通過修改portal.properties檔案來改變它。這些配置已經被寫在hibernate-clustered.xml中，在這個xml檔案中定義了，定義和配置了幾個快取區域。

    這些配置檔案對於一個高效能的網站來說是很重要的。但是不要根據你自己的猜測來隨意改變它們。你應該總是在做一些效能測試的時候修改它，這樣可以幫助你

找到效能瓶頸和驗證你所修改的。