这种组播方式的缺陷:
EHCACHE的组播做得比较初级,功能只是基本实现(比如简单的一个HUB,接两台单网卡的服务器,互相之间组播同步就没问题),
对一些复杂的环境(比如多台服务器,每台服务器上多地址,尤其是集群,存在一个集群地址带多个物理机,每台物理机又带多个虚拟站的子地址),就容易出现问题.

究其原因, 组播/广播转发是一个很复杂的过程. 简单的说,一个组播缺省只能在一个网段内传输,不能跨网段.
举个简单的例子,PC机网卡的自动获取地址,还有WINDOWS里的网上邻居,都属于典型的广播服务,所以这些服务都是不能跨网段(跨路由)的,当然也不是完全不行,借助一些工具,比如CISCO路由器上的udp-broadcasthelper,或者微软的netBIOS on Tcp/ip,就可以实现.
我们自己安装一些软件时,也经常遇到比如\"将网卡的广播转发打开\"之类的操作.

而在多网卡的主机,或同一网卡多IP的主机上,尽管地址可能是一个网段内的,但其实地址间已经存在跳数了(hop),其实就是从一个地址向另一个地址跳.这时广播/组播就容易被阻断.
我们自己的WINDOWS上装一个VMWARE虚拟机,尽管IP地址是一个网段的,但因为虚拟机采用的桥模式不是标准的网桥模式(也可能是需要配置一下,但说实话懒得研究VMWARE了),所以广播/组播也经常出现不通的情况.

更何况在一些云计算的环境,集群的分布往往是跨网段的,甚至是跨地域的.这时更难以依赖这种初级的组播同步.

总之,分布式集群架构,建议EHCACHE改为PEER-2-PEER的同步方式.

其实就是每个节点和其他n-1个节点都建立TCP的P2P PEER.
下面是一个3节点的ehcache分布式部署: