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.