Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "introduction to EhCache distributed cache and cache cluster". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Development environment:

System:Windows

JavaEE Server:tomcat7.0.7

JavaSDK: jdk7+

IDE:eclipse

I. brief introduction of caching system

EhCache is a pure Java in-process cache framework, which is fast and lean, and is the default CacheProvider in Hibernate.

EhCache application architecture diagram, the following figure shows the location of EhCache in the application:

The main features of EhCache are:

1. Fast and lean; 2. Simple; 3. Multiple caching strategies; 4. There are two levels of cached data: memory and disk, so there is no need to worry about capacity; 5. Cached data will be written to disk during virtual machine restart; 6. Distributed cache can be carried out through RMI, pluggable API, etc. 7. Listening interface with cache and cache manager; 8. Support multiple cache manager instances, as well as multiple cache regions of an instance; 9. Provides a caching implementation of Hibernate

Because EhCache is a caching system in the process, once the application is deployed in the cluster environment, each node maintains its own cached data. When a node updates the cached data, the updated data can not be shared in other nodes, which will not only reduce the efficiency of the node, but also lead to the occurrence of data out of synchronization. For example, a website uses two nodes An and B as the cluster deployment. When the cache of node An is updated, but the cache of node B is not updated, it may occur when the user browses the page, one is the updated data, the other is the data that has not been updated, although we can also lock users on a node through Session Sticky technology, but for some systems with strong interaction or non-Web mode Session Sticky is obviously not a good fit. So you need to use EhCache's clustering solution.

Starting with version 1.2, Ehcache can use distributed caching. Starting from version 1.7, EhCache supports five cluster scenarios, which are:

? Terracotta? RMI? JMS? JGroups? The three most commonly used clustering methods of EhCache Server are RMI, JGroups and EhCache Server. This article mainly introduces the way of RMI. The distributed feature is implemented in plugin. Ehcache comes with some default distributed cache plug-in implementations that can meet the needs of most applications. If you need to use other plug-ins, you need to develop it yourself, and developers can implement it by looking at the source code and JavaDoc in the distribution package. Although not necessary, it is helpful to understand some of the design ideas of ehcahce when using distributed caching. This can be seen in the page of distributed cache design. The following sections show how to make distributed plug-ins work with ehcache.

Here are some of the more important aspects of distributed caching:

? How do you know about other caches in a clustered environment? ? What is the form of distributed messages? ? What needs to be replicated? Add (Puts), update (Updates) or fail (Expiries)? ? What is the method of replication? Synchronous or asynchronous? To install distributed caching, you need to configure a PeerProvider and a CacheManagerPeerListener, which are global to a CacheManager. Each cache that performs distributed operations adds a cacheEventListener to deliver messages.

II. The concept and configuration of cluster cache

Correct element type

Only serializable elements can be copied. Some operations, such as removal, require only the key value of the element instead of the entire element, in which the key value can be copied even if the element is not serializable.

Member discovery (Peer Discovery)

Ehcache has a concept of cache groups when clustering. Each cache is a peer of another cache, and there is no primary cache. We just asked a question: how do you know about other caches in a clustered environment? This problem can be named member discovery (Peer Discovery). Ehcache provides two mechanisms for member discovery, just like a car: manual and automatic. To use a built-in member discovery mechanism, specify the class attribute of the cacheManagerPeerProviderFactory element as net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory in the configuration file of the ehcache.

Automatic member discovery

Automatic discovery uses the TCP broadcast mechanism to identify and maintain a broadcast group. It only requires a simple configuration to automatically add and remove members from the group. There is no need for any knowledge of optimizing servers in a cluster, which is recommended by default. Members send a "heartbeat" to the group every second. If a member does not signal for 5 seconds, it will be removed by the group. If a new member sends a "heartbeat" it will be added to the group. Any cache that has replication installed with this configuration will be discovered and identified as available by other members. To set up automatic member discovery, you need to specify the properties attribute of the cacheManagerPeerProviderFactory element in the ehcache configuration file, like this:

PeerDiscovery=automaticmulticastGroupAddress=multicast address | multicast host namemulticastGroupPort=porttimeToLive=0-255 (for more information on timeToLive attribute, please see the description of FAQ section)

Example

Suppose you have two servers in the cluster. You want to synchronize sampleCache1 and sampleCache2. Each stand-alone server should be configured as follows:

Configure server1 and server2

Manual member discovery

Manual membership configuration requires knowing the IP address and port of each listener. Members cannot be added and removed dynamically at run time. In cases where it is technically difficult to use broadcasts, members can be found manually, for example, there is a router that cannot transmit broadcast messages between servers in the cluster. You can also use manual member discovery for one-way data replication so that only server2 knows about server1 and server1 does not know server2. To configure manual member discovery, you need to specify the properties property of the cacheManagerPeerProviderFactory in the ehcache configuration file, as follows:

PeerDiscovery=manual rmiUrls=//server:port/cacheName, / / server:port/cacheName...

RmiUrls is configured with a list of server cache peers. Be careful not to repeat the configuration.

Example

Suppose you have two servers in the cluster. You need to synchronize sampleCache1 and sampleCache2. The following is the configuration required for each server:

Configure server1

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.