分布式EHCACHE系统在缓存同步上存在着不小的缺陷分布式EHCACHE系统,如何实现缓存数据同步? 方式1: RMI组播方式 这也是最常用的方式,配置简单,关键一点,各EHCACHE的节点配置都是一样的 例子: spring 配置中调用的ehcache文件 classpath:ehcache_mc.xml userCache ehcache_mc.xml:
原理: 这样当缓存改变时,ehcache会向230.0.0.1端口4446发RMI UDP组播包 这种组播方式的缺陷: 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. 下面是一个3节点的ehcache分布式部署: 节点1: spring 配置中调用的ehcache文件 classpath:ehcache_p2p_40001.xml userCache ehcache_p2p_40001.xml
节点2: spring 配置中调用的ehcache文件 classpath:ehcache_p2p_40002.xml userCache ehcache_p2p_40002.xml
节点3: spring 配置中调用的ehcache文件 classpath:ehcache_p2p_40003.xml userCache ehcache_p2p_40003.xml
测试 节点1添加一条缓存条目 节点1日志: 2012-08-28 17:00:39,859 INFO CustomActionSupport.getParameter(188)-/admin/inputEntry.do? submit=提交&cachekey=mac1228&cachevalue=1228 2012-08-28 17:00:39,859 INFO TestAction.inputEntry(97)-mac1228:1228 2012-08-28 17:00:39,875 INFO CacheEvent.log(65)-in notifyElementPut[ key = mac1228, value=1228, version=1, hitCount=0, CreationTime = 1346144439875, LastAccessTime = 1346144439875 ] 2012-08-28 17:00:39,875DEBUG ServletDispatcherResult.debug(57)-Forwarding to location /index.jsp 节点2日志: 2011-09-22 14:25:51,262 INFO CacheEvent.log(65)-in notifyElementPut[ key = mac1228, value=1228, version=1, hitCount=0, CreationTime = 1346144440000, LastAccessTime = 1316672751253 ] 节点3日志: 2011-09-22 14:25:51,198 INFO CacheEvent.log(65)-in notifyElementPut[ key = mac1228, value=1228, version=1, hitCount=0, CreationTime = 1346144440000, LastAccessTime = 1316672751198 ] 节点2添加一条缓存条目 节点1日志: 2012-08-28 16:54:55,890 INFO CacheEvent.log(65)-in notifyElementPut[ key = mac25181904, value=25181904, version=1, hitCount=0, CreationTime = 1316672407000, LastAccessTime = 1346144095890 ] 节点2日志: 2011-09-22 14:20:06,041 INFO CustomActionSupport.getParameter(188)-/admin/inputEntry.do? submit=提交&cachekey=mac25181904&cachevalue=25181904 2011-09-22 14:20:06,042 INFO TestAction.inputEntry(97)-mac25181904:25181904 2011-09-22 14:20:06,050DEBUG ServletDispatcherResult.debug(57)-Forwarding to location /index.jsp 节点3日志: 2011-09-22 14:20:06,568 INFO CacheEvent.log(65)-in notifyElementPut[ key = mac25181904, value=25181904, version=1, hitCount=0, CreationTime = 1316672407000, LastAccessTime = 1316672406568 ] 总结: 上面说了,组播方式同步不可靠. P2P方式其实也存在不可靠的地方.这就是P2P要求每个节点的EHCACHE要指向其他的N-1个节点, 当在云环境,或集群域下, 多个子节点部署项目都是被自动发布的,这时很难做到不同节点有不同的配置,因为自动发布,配置往往都是相同的,这样P2P就很难实现. 总之,这种同步型应用是很难适应大规模分布式部署的,还是建议采用一些集中软件比如MEMCACHED.