深入探讨在叢集環境中使用 EhCache 緩存系統

EhCache 緩存系統簡介

EhCache 是一個純 Java 的程序内緩存架構，具有快速、精幹等特點，是 Hibernate 中預設的 CacheProvider。

下圖是 EhCache 在應用程式中的位置：

圖 1. EhCache 應用架構圖

EhCache 的主要特性有：

快速；
簡單；
多種緩存政策；
緩存資料有兩級：記憶體和磁盤，是以無需擔心容量問題；
緩存資料會在虛拟機重新開機的過程中寫入磁盤；
可以通過 RMI、可插入 API 等方式進行分布式緩存；
具有緩存和緩存管理器的偵聽接口；
支援多緩存管理器執行個體，以及一個執行個體的多個緩存區域；
提供 Hibernate 的緩存實作；
等等 …

由于 EhCache 是程序中的緩存系統，一旦将應用部署在叢集環境中，每一個節點維護各自的緩存資料，當某個節點對緩存資料進行更新，這些更新的資料無法在其它節點中共享，這不僅會降低節點運作的效率，而且會導緻資料不同步的情況發生。例如某個網站采用 A、B 兩個節點作為叢集部署，當 A 節點的緩存更新後，而 B 節點緩存尚未更新就可能出現使用者在浏覽頁面的時候，一會是更新後的資料，一會是尚未更新的資料，盡管我們也可以通過 Session Sticky 技術來将使用者鎖定在某個節點上，但對于一些互動性比較強或者是非 Web 方式的系統來說，Session Sticky 顯然不太适合。是以就需要用到 EhCache 的叢集解決方案。

EhCache 從 1.7 版本開始，支援五種叢集方案，分别是：

Terracotta
RMI
JMS
JGroups
EhCache Server

本文主要介紹其中的三種最為常用叢集方式，分别是 RMI、JGroups 以及 EhCache Server 。

http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/#ibm-pcon

RMI 叢集模式

RMI 是 Java 的一種遠端方法調用技術，是一種點對點的基于 Java 對象的通訊方式。EhCache 從 1.2 版本開始就支援 RMI 方式的緩存叢集。在叢集環境中 EhCache 所有緩存對象的鍵和值都必須是可序列化的，也就是必須實作 java.io.Serializable 接口，這點在其它叢集方式下也是需要遵守的。

下圖是 RMI 叢集模式的結構圖：

圖 2. RMI 叢集模式結構圖

采用 RMI 叢集模式時，叢集中的每個節點都是對等關系，并不存在主節點或者從節點的概念，是以節點間必須有一個機制能夠互相認識對方，必須知道其它節點的資訊，包括主機位址、端口号等。EhCache 提供兩種節點的發現方式：手工配置和自動發現。手工配置方式要求在每個節點中配置其它所有節點的連接配接資訊，一旦叢集中的節點發生變化時，需要對緩存進行重新配置。

由于 RMI 是 Java 中内置支援的技術，是以使用 RMI 叢集模式時，無需引入其它的 Jar 包，EhCache 本身就帶有支援 RMI 叢集的功能。使用 RMI 叢集模式需要在 ehcache.xml 配置檔案中定義 cacheManagerPeerProviderFactory 節點。假設叢集中有兩個節點，分别對應的 RMI 綁定資訊是：

節點 1	192.168.0.11	4567	/oschina_cache
節點 2	192.168.0.12
節點 3	192.168.0.13

那麼對應的手工配置資訊如下：

<cacheManagerPeerProviderFactory 
    class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" 
    properties="hostName=localhost,
    port=4567,
    socketTimeoutMillis=2000,
    peerDiscovery=manual,
    rmiUrls=//192.168.0.12:4567/oschina_cache|//192.168.0.13:4567/oschina_cache"
/>

其它節點配置類似，隻需把 rmiUrls 中的兩個 IP 位址換成另外兩個節點對應的 IP 位址即可。

接下來在需要進行緩存資料複制的區域（Region）上配置如下即可：

<cache name="sampleCache2"
    maxElementsInMemory="10"
    eternal="false"
    timeToIdleSeconds="100"
    timeToLiveSeconds="100"
    overflowToDisk="false">
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
        properties="replicateAsynchronously=true, 
    replicatePuts=true, 
    replicateUpdates=true,
        replicateUpdatesViaCopy=false, 
    replicateRemovals=true "/>
</cache>

具體每個參數代表的意義請參考 EhCache 的手冊，此處不再詳細說明。

EhCache 的 RMI 叢集模式還有另外一種節點發現方式，就是通過多點傳播（ multicast ）來維護叢集中的所有有效節點。這也是最為簡單而且靈活的方式，與手工模式不同的是，每個節點上的配置資訊都相同，大大友善了節點的部署，避免人為的錯漏出現。

在上述三個節點的例子中，配置如下：

<cacheManagerPeerProviderFactory
    class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
    properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1,
    multicastGroupPort=4446, timeToLive=32"
/>

其中需要指定節點發現模式 peerDiscovery 值為 automatic 自動；同時多點傳播位址可以指定 D 類 IP 位址空間，範圍從 224.0.1.0 到 238.255.255.255 中的任何一個位址。

http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/#ibm-pcon

JGroups 叢集模式

EhCache 從 1.5. 版本開始增加了 JGroups 的分布式叢集模式。與 RMI 方式相比較， JGroups 提供了一個非常靈活的協定棧、可靠的單點傳播和多點傳播消息傳輸，主要的缺點是配置複雜以及一些協定棧對第三方包的依賴。

JGroups 也提供了基于 TCP 的單點傳播 ( Unicast ) 和基于 UDP 的多點傳播 ( Multicast ) ，對應 RMI 的手工配置和自動發現。使用單點傳播方式需要指定其它節點的主機位址和端口，下面是兩個節點，并使用了單點傳播方式的配置：

<cacheManagerPeerProviderFactory
    class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
    properties="connect=TCP(start_port=7800):
        TCPPING(initial_hosts=host1[7800],host2[7800];port_range=10;timeout=3000;
        num_initial_members=3;up_thread=true;down_thread=true):
        VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
        pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;
    retransmit_timeout=3000):
        pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;
        print_local_addr=false;down_thread=true;up_thread=true)"
propertySeparator="::" />

使用多點傳播方式配置如下：

<cacheManagerPeerProviderFactory
    class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
    properties="connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;):PING:
    MERGE2:FD_SOCK:VERIFY_SUSPECT:pbcast.NAKACK:UNICAST:pbcast.STABLE:FRAG:pbcast.GMS"
    propertySeparator="::"
/>

從上面的配置來看，JGroups 的配置要比 RMI 複雜得多，但也提供更多的微調參數，有助于提升緩存資料複制的性能。詳細的 JGroups 配置參數的具體意義可參考 JGroups 的配置手冊。

JGroups 方式對應緩存節點的配置資訊如下：

<cache name="sampleCache2"
    maxElementsInMemory="10"
    eternal="false"
    timeToIdleSeconds="100"
    timeToLiveSeconds="100"
    overflowToDisk="false">
    <cacheEventListenerFactory
        class="net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory"
        properties="replicateAsynchronously=true, replicatePuts=true,
        replicateUpdates=true, replicateUpdatesViaCopy=false, replicateRemovals=true" />
</cache>

使用多點傳播方式的注意事項

使用 JGroups 需要引入 JGroups 的 Jar 包以及 EhCache 對 JGroups 的封裝包 ehcache-jgroupsreplication-xxx.jar 。

在一些啟用了 IPv6 的電腦中，經常啟動的時候報如下錯誤資訊：

java.lang.RuntimeException: the type of the stack (IPv6) and the user supplied addresses (IPv4) don't match: /231.12.21.132.

解決的辦法是增加 JVM 參數：-Djava.net.preferIPv4Stack=true。如果是 Tomcat 伺服器，可在 catalina.bat 或者 catalina.sh 中增加如下環境變量即可：

SET CATALINA_OPTS=-Djava.net.preferIPv4Stack=true

經過實際測試發現，叢集方式下的緩存資料都可以在 1 秒鐘之内完成到其節點的複制。

http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/#ibm-pcon

與前面介紹的兩種叢集方案不同的是， EhCache Server 是一個獨立的緩存伺服器，其内部使用 EhCache 做為緩存系統，可利用前面提到的兩種方式進行内部叢集。對外提供程式設計語言無關的基于 HTTP 的 RESTful 或者是 SOAP 的資料緩存操作接口。

下面是 EhCache Server 提供的對緩存資料進行操作的方法：

OPTIONS /{cache}}

擷取某個緩存的可用操作的資訊。

HEAD /{cache}/{element}

擷取緩存中某個元素的 HTTP 頭資訊，例如：

curl --head  http://localhost:8080/ehcache/rest/sampleCache2/2

EhCache Server 傳回的資訊如下：

HTTP/1.1 200 OK 
X-Powered-By: Servlet/2.5 
Server: GlassFish/v3 
Last-Modified: Sun, 27 Jul 2008 08:08:49 GMT 
ETag: "1217146129490"
Content-Type: text/plain; charset=iso-8859-1 
Content-Length: 157 
Date: Sun, 27 Jul 2008 08:17:09 GMT

GET /{cache}/{element}

讀取緩存中某個資料的值。

PUT /{cache}/{element}

寫緩存。

由于這些操作都是基于 HTTP 協定的，是以你可以在任何一種程式設計語言中使用它，例如 Perl、PHP 和 Ruby 等等。

下圖是 EhCache Server 在應用中的架構：

圖 3. EhCache Server 應用架構圖

EhCache Server 同時也提供強大的安全機制、監控功能。在資料存儲方面，最大的 Ehcache 單執行個體在記憶體中可以緩存 20GB。最大的磁盤可以緩存 100GB。通過将節點整合在一起，這樣緩存資料就可以跨越節點，以此獲得更大的容量。将緩存 20GB 的 50 個節點整合在一起就是 1TB 了。

http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/#ibm-pcon

總結

以上我們介紹了三種 EhCache 的叢集方案，除了第三種跨程式設計語言的方案外，EhCache 的叢集對應用程式的代碼編寫都是透明的，程式人員無需考慮緩存資料是如何複制到其它節點上。既保持了代碼的輕量級，同時又支援龐大的資料叢集。EhCache 可謂是深入人心。

2009 年年中，Terracotta 宣布收購 EhCache 産品。Terracotta 公司的産品 Terracotta 是一個 JVM 級的開源群集架構，提供 HTTP Session 複制、分布式緩存、POJO 群集、跨越叢集的 JVM 來實作分布式應用程式協調。最近 EhCache 主要的改進都集中在跟 Terracotta 架構的內建上，這是一個真正意義上的企業級緩存解決方案。

本文轉載自

http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/

深入探讨在叢集環境中使用 EhCache 緩存系統

EhCache 緩存系統簡介

圖 1. EhCache 應用架構圖

RMI 叢集模式

圖 2. RMI 叢集模式結構圖

JGroups 叢集模式

使用多點傳播方式的注意事項

圖 3. EhCache Server 應用架構圖

總結

繼續閱讀

關于Gradle配置的小結

Java小案例——随機數猜測随機數猜測

nginx location中斜線的位置的重要性

27 Best Free Eclipse Plug-ins for Java Developer to be ProductiveCode Quality PluginsText Editor PluginsDependency ManagementVersion Control Integration PluginsFramework Development Continuous Integration Related PluginsOther Utility Plugins

Java String.format方法的簡單使用

neo4j之cypher使用文檔

GitHub連夜封殺！這份阿裡 10W 字内部 Java 字面試手冊到底有多強？

spark/scala關于【資源檔案】加載方法概述外部檔案加載方案測試資源檔案打包入jar包中小結

mybatis_入門程式Mybatis入門

AOP程式設計_Android優雅權限架構(1)概念基礎，2021金三銀四前言正文大綱正文

Effective Java 8:通用程式設計

OOM三種類型

工廠模式-三種類型

【遞歸】高效率求2的n次幂

win10本地scala和spark安裝安裝scala安裝spark

scala (3) Function 和 Method