近期客戶經常因爲系統響應慢、甚至服務器宕機來發信給我們，當然這做爲高優先級的任務，需要立即解決。通過分析應用日誌和was日誌，發現是出現了併發請求某些複雜數據資源的時候，造成的線程掛起、系統不響應。既然確定了是系統問題，那就得趕緊給出一個可行性解決方案，穩住客戶。通過分析異常日誌，發現併發的情況是應用在更新緩存信息，或者說是因爲緩存失效後應用在重新請求資源。
應用所用的是JCS緩存機制，我看過cache.ccf緩存配置文件，發現了一些問題，也是在解決問題的過程中，對這個緩存工具進一步瞭解，發現網絡上關於JCS的解答並不多，所以寫了一些東西來釋疑。
Java Caching System
JCS是Jakarta的項目Turbine的子項目。它是一個複合式的緩衝工具。可以將對象緩衝到內存、硬盤，同時能對緩衝對象進行生命週期的過期設定，還可以通過JCS構建具有緩衝的分佈式構架，以實現高性能的應用。對於一些需要頻繁訪問而每訪問一次都非常消耗資源的對象，可以臨時存放在緩衝區中，這樣可以提高服務的性能，JCS正是這樣一個能夠處理高訪問低修改數據對象的緩衝工具，對於讀操作遠遠多於寫操作的應用性能提高非常顯著。
JCS除了簡單的將對象緩衝在內存中以外，還具有幾個特性，以適應企業級緩衝系統的需要。這些特性包括時間過期、索引式硬盤緩衝、並行式的分佈緩衝等。
內存緩衝
JCS現在支持兩種內存緩衝算法LRU和MRU。通常都是使用LRU（近期最少使用算法）算法：org.apache.stratum.jcs.engine.memory.lru.LRUMemoryCache 。
使用內存緩衝區需要定義緩衝區大小，當超過緩衝區限制時，會將緩衝內容拋棄掉。如果有配硬盤緩衝，則將擠出來的緩衝內容寫入硬盤緩衝區。
時間過期
JCS對於緩衝的對象，可以設定緩衝過期時間，一個對象在緩衝區中停留的時間超過這個時間，就會被認爲是“不新鮮”而被放棄。索引式硬盤緩衝
一方面，爲了避免緩衝區過大，撐爆虛擬機的內存，另一方面又希望能夠緩衝更多的對象，JCS可以將超出緩衝區大小的對象緩存到硬盤上。配置上也比較方便，只需要指定緩衝臨時文件的存放目錄位置。硬盤緩衝將緩衝對象的內容寫到文件上，但是將訪問索引保存在內存中，因此也能夠達到儘可能高的訪問效率。並行式的分佈緩衝(Lateral)
通常，將對象緩衝在內存中，一方面提高了應用的性能，而另一方面卻使得應用不可以分佈式發佈。因爲假設一個應用配置在兩臺服務器上並行運行，而兩臺服務器單獨緩衝，則很容易導致兩個緩衝區內容出現版本上的不一致而出錯。一個機器上修改了數據，這個動作會影響到本地內存緩衝區和數據庫服務器，但是卻不會通知到另一臺服務器，導致另一臺上緩衝的數據實際上已經無效了。
並行式的分佈緩衝就是解決這個問題。可以通過配置，將幾臺服務器配成一個緩衝組，組內每臺服務器上有數據更新，會橫向將更新的內容通過TCP/IP協議傳輸到其他服務器的緩衝層，這樣就可以保證不會出現上述情況。這個的缺點是如果組內的並行的服務器數量增大後，組內的數據傳輸量將會迅速上升。這種方案適合並行服務器的數量比較少的情況。
Client/Server式的緩衝(Remote)
客戶/服務端式的緩衝集羣。這種方式支持一個主服務器和最高達到256個客戶端。客戶端的緩衝層會嘗試連接主服務器，如果連接成功，就會在主服務器上註冊。每個客戶端有數據更新，就會通知到主服務器，主服務器會將更新通知到除消息來源的客戶端以外的所有的客戶端。
每個客戶端可以配置超過一個服務器，第一個服務器是主服務器，如果與第一個服務器連接失敗，客戶端會嘗試與備用的服務器連接，如果連接成功，就會通過備用服務器與其他客戶端對話，同時會定期繼續嘗試與主服務器取得連接。如果備用服務器也連接失敗，就會按照配置順序嘗試與下一個備用服務器連接。
這種方式下，更新通知是一種輕量級的，一個機器上的數據更新，不會把整個數據傳輸出去，而只是通知一個ID，當遠程的其他機器收到更新通知後，就會把對應ID的緩衝對象從本地的內存緩衝區中移除，以保證不會在緩衝區內出現錯誤數據。
這種構造需要分別配置客戶端和服務器，配置比較麻煩。
JCS的這些特點都是在cache.ccf配置文件中通過配置來控制的，並且我們也可以通過定製化編碼實現對JCS的一些特定緩存對象事件進行監控等等。
接下來，我會放上一些實例來講解在項目中如何配置和應用JCS,以及一些注意事項。