Ehcache use the distribution needs to be aware of the place

Distributed Ehcache System, there are two methods of synchronization

• Mode 1:rmi Multicast mode

This is also the most common way, the configuration is simple, the key point, each ehcache node configuration is the same

Principle:
So when the cache changes, Ehcache will send RMI UDP multicast packets to 230.0.0.1 Port 4446

(230.0.0.1 is a Class D network address, specifically for broadcast)

The drawbacks of this multicast approach:
Ehcache multicast is done relatively elementary, the function is only the basic implementation (such as a simple hub, two single-card servers, the multicast synchronization between each other is no problem),
For some complex environment (such as multiple servers, multiple addresses on each server , especially clusters, there is a cluster address with multiple physical machines, each physical machine with multiple virtual station sub-address ), it is prone to problems.

The reason for this is that multicast/broadcast forwarding is a very complicated process. Simply put, a multicast default can only be transferred within a network segment, not across the network segment .
As a simple example, the auto-fetch address of the PC NIC and the Network neighborhood in Windows are typical broadcast services, so these services are not cross-section (cross-routing), and of course not completely, with tools such as Udp-broadcast on Cisco routers Helper, or Microsoft's NetBIOS on TCP/IP, can be implemented.
When we install some of our own software, we often encounter actions such as "turn on the broadcast of the network card."

and in the multi-card host, or the same network card multi-IP host, although the address may be a network segment, but in fact there is already a hop number of the address (hop), in fact, from one address to another to jump. Broadcast/multicast is easily blocked .
For example: We have a VMware virtual machine installed on our own windows, although the IP address is a network segment, but because the virtual machine uses the bridge mode is not the standard bridge mode (may also need to configure, but to tell the truth lazy study of VMware), so broadcast/multicast also often appear to be out of the picture.

What's more, in some cloud computing environments, clusters are often distributed across network segments and even across geographies. It is more difficult to rely on this primary multicast synchronization.

In summary, the distributed cluster architecture suggests that Ehcache be changed to Peer-2-peer synchronization mode.

• Way 2:P2P Way

In fact, each node and other n-1 nodes establish TCP peer peer.

In this way, each node has different configurations for synchronizing to other IPs.

Summarize:
It says that the multicast mode synchronization is unreliable .
There are also unreliable points of contact. This is the peer-to-peer requirement that the ehcache of each node point to the other N-1 nodes,
When in a cloud environment, or cluster domain, multiple child node deployment projects are automatically released , it is difficult to do different nodes have different configurations , because the automatic release, configuration is often the same, so that peer-to be difficult to achieve .
In short, this synchronous application is difficult to adapt to large-scale distributed deployment, or it is recommended to use some centralized software such as memcached.

Ehcache use the distribution needs to be aware of the place