Dive into the use of EhCache cache systems in a clustered environment

Introduction to EhCache Cache system

EhCache is a pure Java in-process caching framework, which is fast and capable, and is the default Cacheprovider in Hibernate.

is the location of the EhCache in the application:

Figure 1. EhCache Application Architecture Diagram

The main features of EhCache are:

1. Fast
2. Simple
3. multiple caching strategies;
4. There are two levels of cache data: memory and disk, so there is no need to worry about capacity;
5. The cached data is written to disk during the virtual machine restart;
6. It can be distributed cache through RMI, pluggable API and so on.
7. A listening interface with cache and cache manager;
8. Support multi-cache manager instances, as well as multiple cache areas of an instance;
9. Provides cache implementation of Hibernate;
10. Wait a minute...

Since EhCache is a cache system in the process, once the application is deployed in a clustered environment, each node maintains its own cached data, and when a node updates the cached data, the updated data cannot be shared among the other nodes, which not only reduces the efficiency of the node's operation, but also causes the data to become unsynchronized. For example, a Web site with a, B two nodes as a cluster deployment, when the A-node cache update, and the B-node cache has not yet been updated may occur when users browse the page, one will be updated data, one will be not updated data, although we can also pass the Session Sticky Technology to lock the user on a node, but for some systems that are highly interactive or non-Web, the Session Sticky is obviously not suitable. So we need to use the EhCache clustering solution.

Starting with version 1.7, EhCache supports five cluster scenarios, namely:

• Terracotta
• Rmi
• Jms
• JGroups
• EhCache Server

This article mainly introduces three of the most commonly used clustering methods, namely RMI, JGroups and EhCache Server.

RMI cluster mode

RMI is a remote method invocation technique in Java and is a point-to-point, Java-based object communication method. EhCache supports RMI-mode cache clusters starting with version 1.2. In a clustered environment, the keys and values of all cached objects must be serializable, that is, the Java.io.Serializable interface must be implemented, which is EhCache in other cluster modes.

Is the structure diagram of the RMI cluster pattern:

Figure 2. RMI Cluster schema structure diagram

In the RMI cluster mode, each node in the cluster is a peer relationship, there is no master node or node concept, so there must be a mechanism between nodes to understand each other, must know the information of other nodes, including host address, port number and so on. EhCache provides two ways to discover nodes: Manual configuration and automatic discovery. Manual configuration requires that the connection information for all other nodes be configured in each node, and the cache needs to be reconfigured once the nodes in the cluster change.

Since RMI is a built-in technology in Java, there is no need to introduce additional Jar packages when using RMI cluster mode, and the EhCache itself has the capability to support RMI clusters. Using RMI cluster mode requires that the Cachemanagerpeerproviderfactory node be defined in the Ehcache.xml configuration file. Assuming that there are two nodes in the cluster, the RMI binding information corresponding to each is:

Node 1	192.168.0.11	4567	/oschina_cache
Node 2	192.168.0.12	4567	/oschina_cache
Node 3	192.168.0.13	4567	/oschina_cache

Then the corresponding manual configuration information is as follows:

< 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 " />

Other nodes are configured Similarly, simply replace the two IP addresses in the rmiurls with the corresponding IP addresses of the other two nodes.

Next, configure the following on the region where you want to replicate the cache data:

<Cachename= "SampleCache2"maxelementsinmemory= "Ten"Eternal= "false"Timetoidleseconds= "+"Timetoliveseconds= "+"Overflowtodisk= "false">    <cacheeventlistenerfactoryclass= "Net.sf.ehcache.distribution.RMICacheReplicatorFactory"Properties= "Replicateasynchronously=true, Replicateputs=true, Replicateupdates=true, replicateupdatesviacopy=fals E, replicateremovals=true "/></Cache>

Please refer to the EhCache's manual for the specific meaning of each parameter, which is not detailed here.

EhCache's RMI cluster model has another way of discovering nodes, which is to maintain all the active nodes in the cluster through multicasting (multicast). This is also the most simple and flexible way, unlike the manual mode, the configuration information on each node is the same, greatly facilitates the deployment of nodes, to avoid human errors and omissions.

In the example of the above three nodes, the configuration is as follows:

< cachemanagerpeerproviderfactory     class = "Net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"     Properties= "peerdiscovery=automatic, multicastgroupaddress=230.0.0.1,    multicastgroupport= 4446, timetolive=32 "/>

Where you need to specify the node discovery mode Peerdiscovery value is automatic automatic, and the multicast address can specify the class D IP address space, ranging from 224.0.1.0 to any address in 238.255.255.255.

JGroups cluster mode

EhCache from 1.5. The version starts with the JGroups distributed cluster mode. Compared to the RMI approach, JGroups provides a very flexible protocol stack, reliable unicast and multicast messaging, with the main drawback being the complexity of configuration and the reliance of some protocol stacks on third-party packages.

The

JGroups also provides TCP-based unicast (Unicast) and UDP-based multicasting (multicast), which correspond to the manual configuration and Autodiscover of RMI. Using unicast requires specifying the host address and port of the other node, below two nodes, and using a unicast configuration:

 <  cachemanagerpeerproviderfactory  class  = "     Net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory "  Properties  = "Connect=tcp (start_port=7800): Tcpping (initial_hosts=host1[7800        ],HOST2[7800];p ort_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  = "::"  />  

Use multicast mode to configure the following:

< cachemanagerpeerproviderfactory     class = "Net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"     Properties= "connect=udp (mcast_addr=231.12.21.132;mcast_port=45566;):P ing:    merge2:fd_sock : Verify_suspect:pbcast. NAKACK:UNICAST:pbcast. STABLE:FRAG:pbcast. GMS "    propertyseparator=":: "/>

From the above configuration, the JGroups configuration is much more complex than RMI, but it also provides more fine tuning parameters to help improve the performance of cache data replication. For detailed JGroups configuration parameters, refer to the JGroups configuration manual.

The configuration information for the cache node for the JGroups method is as follows:

<Cachename= "SampleCache2"maxelementsinmemory= "Ten"Eternal= "false"Timetoidleseconds= "+"Timetoliveseconds= "+"Overflowtodisk= "false">    <cacheeventlistenerfactoryclass= "Net.sf.ehcache.distribution.jgroups.JGroupsCacheReplicatorFactory"Properties= "Replicateasynchronously=true, Replicateputs=true, Replicateupdates=true, Replicateupdatesviacopy=false, REPL Icateremovals=true " /></Cache>

Considerations for using multicast mode

The use of JGroups requires the introduction of JGroups Jar packages and EhCache package Ehcache-jgroupsreplication-xxx.jar for JGroups.

In some IPV6-enabled computers, the following error message is reported frequently when booting:

Java.lang.RuntimeException:the type of the stack (IPV6) and the user supplied addresses (IPV4) don ' t match:/231.12.21.13 2.

The workaround is to increase the JVM parameters:-djava.net.preferipv4stack=true. If it is a Tomcat server, you can add the following environment variables in Catalina.bat or catalina.sh:

SET Catalina_opts=-djava.net.preferipv4stack=true

The actual test shows that the cache data in cluster mode can be replicated to its node within 1 seconds.

EhCache Server

Unlike the two cluster scenarios described earlier, EhCache server is a stand-alone cache server that uses EhCache as a caching system, and can take advantage of the two previously mentioned methods for internal clustering. Provides non-programming language-independent HTTP-based RESTful or SOAP data cache operation interfaces externally.

The following are the methods that EhCache Server provides to manipulate cached data:

OPTIONS/{cache}}

Gets information about the available actions for a cache.

HEAD/{cache}/{element}

Gets the HTTP header information for an element in the cache, such as:

Curl--head  HTTP://LOCALHOST:8080/EHCACHE/REST/SAMPLECACHE2/2

The information returned by EhCache Server is as follows:

http/1.1-ok x-powered-by:servlet/2.5 server:glassfish/v3 Last-modified:sun, Jul 08:08:49 GMT ETag: "1217146 129490 "Content-type:text/plain; Charset=iso-8859-1 content-length:157 Date:sun, Jul 08:17:09 GMT

GET/{cache}/{element}

Reads the value of a data in the cache.

PUT/{cache}/{element}

Write Cache.

Because these actions are based on the HTTP protocol, you can use it in any programming language, such as Perl, PHP, Ruby, and so on.

Is the schema of the EhCache Server in the app:

Figure 3. EhCache Server Application Architecture diagram

EhCache Server also provides a powerful security mechanism, monitoring capabilities. In terms of data storage, the largest Ehcache single instance can cache 20GB in memory. The largest disk can cache 100GB. By consolidating nodes together, the cache data can span nodes to achieve greater capacity. The integration of 50 nodes in cache 20GB is 1TB.

Summarize

Above we introduced three kinds of EhCache cluster scheme, in addition to the third kind of cross programming language scheme, the EhCache's cluster to the application's code writing is transparent, the program person does not need to consider how the cache data replicates to other nodes. It keeps the code lightweight while supporting a large data cluster. EhCache is deeply rooted.

In 2009, Terracotta announced the acquisition of EhCache products. Terracotta's product Terracotta is a JVM-class open-source cluster framework that provides HTTP Session replication, distributed caching, POJO clustering, and a JVM spanning a cluster for distributed application orchestration. Recent EhCache major improvements have been focused on integration with the Terracotta framework, a truly enterprise-class caching solution.

This article is reproduced from http://www.ibm.com/developerworks/cn/java/j-lo-ehcache/

Dive into the use of EhCache cache systems in a clustered environment