Ehcache has several methods of cluster, including rmi, jgroup, and jms. Here we will talk about the merits of using ehcache to copy the cache in rmi mode, for the following reasons: 1. rmi is the default Remote Mechanism of java. 2. You can tune tcp options. 3. Elements must have been serialized because it is stored on a disk. Therefore, you do not need to use xml to format anything.
Ehcache has several methods of cluster, including rmi, jgroup, and jms. Here we will talk about the merits of using ehcache to copy the cache in rmi mode, for the following reasons: 1. rmi is the default Remote Mechanism of java. 2. You can tune tcp options. 3. Elements must have been serialized because it is stored on a disk. Therefore, you do not need to use xml to format anything.
There are several methods for ehcache clusters: rmi, jgroup, and jms. Here we will talk about the use of ehcache.
The reason why ehcache uses rmi to copy the cache is as follows:
1. rmi is the default Remote Mechanism of java.
2. You can optimize tcp options.
3. Because Elements must be stored on a disk, it must have been serialized. Therefore, you do not need to use xml to format anything.
4. You can use the Firewall
Cluster interaction diagram in rmi mode:
The rmi method of Ehcache is a point-to-point protocol, so it will generate a lot of Intranet Communication. Of course, Ehcache will solve this problem through an asynchronous batch replication mechanism.
To configure ehcache, You need to configure the elements.
PeerProvider
CacheManagerPeerListener
Configure the Provider. There are two methods: automatic discovery and manual configuration.
Automatic mode: the automatic discovery mode uses tcp broadcast to create and contain a broadcast group. It features a minimum configuration and automatic addition and Management of member groups. No server has a priority. The peer node sends heartbeat to the broadcast group every second. If a peer node is not sent within five seconds, the peer node is deleted. If a new peer node is added to the cluster
The properties of cacheManagerPeerProviderFactory has the following Configuration:
PeerDiscovery = automatic
MulticastGroupAddress = 230.0.0.1
MulticastGroupPort = 40001
TimeToLive = 0-255
HostName = hostname
PeerDiscovery mode: atutomatic is automatic; mulicastGroupAddress broadcast group address: 230.0.0.1; mulicastGroupPort broadcast group port: 40001; timeToLive indicates that the search range: 0 is the same server, and 1 is the same subnet, 32 refers to the same site, 64 refers to the same region, 128 is the same continent, and there is another 256, I will not talk about it; hostName: Host Name or ip address, interface used to receive or send information
In my experiment, the details are as follows:
Of course, there is also a way to manually configure and paste the example, but it is not described.
Server1
Server2
After configuring the method, you need to configure listener. Next, let's talk about Listener.
Listener is used to listen for information sent from the cluster.
The Listenner has two attributes: class and propertis.
Class A complete factory class name
Properties are well-separated attributes that are useful for facoprocessor.
The specific configuration of this experiment is as follows:
HostName refers to the local host. Note that if localhost is used, it will only be valid for the local host. Use the IP address or host name in the subnet, port 40001, socketTimeoutMillis refers to the timeout time of the socket sub-module. The default value is 2000 ms. Note that the port can be the same between the two hosts. It is best to share the same, personal suggestion
Then configure the cache copy Replicators:
The local configuration is as follows:
Name indicates the cache name. maxEntriesLocalHeap: specifies the maximum number of elements that can reside in the memory. The lifecycle of timeToLiveSeconds is 10000 s. overflowToDisk: Indicates whether to enable the disk when the memory is insufficient. This parameter is set to false, then it is asynchronous. In the put, update, copy, and remove operations, whether to copy data or not, and then the synchronization time is 1 s. The bootstrapCacheLoaderFactory indicates that data is synchronized at startup.
Complete configurations are as follows:
In server2, that is, 192.168.1.116, configure this address in hostName.
The following is the test code.
package com.ehcache;import java.io.IOException;import java.io.InputStream;import net.sf.ehcache.Cache;import net.sf.ehcache.CacheException;import net.sf.ehcache.CacheManager;import net.sf.ehcache.Element;public class Test2 { public static void main(String[] args) throws InterruptedException { InputStream is=null;CacheManager manager=null;try {is = Test2.class.getResourceAsStream("/ehcache.xml"); manager = CacheManager.newInstance(is);} catch (CacheException e1) {try {if(is!=null){is.close();is=null;}} catch (IOException e) {e.printStackTrace();}e1.printStackTrace();} Cache cache = manager.getCache("myCache"); Element element = new Element("client3" + System.currentTimeMillis(), "client3"); cache.put(element); int i=0; while (true) { Element element2 = new Element("client-3-"+i,i); cache.put(element2); Thread.sleep(3000); System.out.println("\n"); for (Object key : cache.getKeys()) { System.out.println(key + ":" + cache.get(key).getObjectValue()); } i++; } }}
Run the server2 test code to change the element to client-2 -.
Then paste the following picture:
Data synchronized from client3 to client2
The following is an algorithm used to describe the cache elimination of ehcache:
LRU is the Least Recently Used algorithm for Least Recently Used;
FIFO in a queue Mode
LFUleast frequently used is the least frequently used page replacement algorithm.
This is the project file: Click to open the link
Note: The author's level is limited, and these configurations have only been used in the LAN. If there is an error, please note.
I have also written and tested the separation of Server Load balancer, tomcat clusters, session calls in the LAN, and hot standby. I hope I will have the opportunity to build a large-scale cluster in the future.