EHCACHE采用分布须要注意的地方

分布式EHCACHE系统,有两种同步方式

• 方式1 :  RMI组播方式

这也是最经常使用的方式,配置简单,关键一点,各EHCACHE的节点配置都是同样的

原理:
这样当缓存改变时,ehcache会向230.0.0.1端口4446发RMI UDP组播包

(230.0.0.1 是D类网络地址，专门用于广播)

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

究其缘由, 组播/广播转发是一个很复杂的过程. 简单的说, 一个组播缺省只能在一个网段内传输,不能跨网段.
举个简单的例子, PC机网卡的自动获取地址,还有WINDOWS里的网上邻居,都属于典型的广播服务,因此这些服务都是不能跨网段(跨路由)的,固然也不是彻底不行,借助一些工具,好比CISCO路由器上的udp-broadcast helper,或者微软的netBIOS on Tcp/ip,就能够实现.
咱们本身安装一些软件时,也常常遇到好比"将网卡的广播转发打开"之类的操做.
 
而在多网卡的主机,或同一网卡多IP的主机上,尽管地址多是一个网段内的,但其实地址间已经存在跳数了(hop),其实就是从一个地址向另外一个地址跳. 这时广播/组播就容易被阻断.
好比: 咱们本身的WINDOWS上装一个VMWARE虚拟机,尽管IP地址是一个网段的,但由于虚拟机采用的桥模式不是标准的网桥模式(也多是须要配置一下,但说实话懒得研究VMWARE了),因此广播/组播也常常出现不通的状况.

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

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

• 方式2 : p2p方式

其实就是每一个节点和其余n-1个节点都创建TCP的P2P PEER。

这种方式各个节点关于同步到其余IP的的配置都不相同。

总结:
上面说了,组播方式同步不可靠.
P2P方式其实也存在不可靠的地方.这就是P2P要求每一个节点的EHCACHE要指向其余的N-1个节点,
当在云环境,或集群域下, 多个子节点部署项目都是被自动发布的,这时很难作到不一样节点有不一样的配置,由于自动发布,配置每每都是相同的,这样P2P就很难实现.
总之,这种同步型应用是很难适应大规模分布式部署的,仍是建议采用一些集中软件好比MEMCACHED.