分布式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.