轉載：http://in.relation.to/Bloggers/StrongLiu

為什麼需要使用分散式快取（資料網格）呢? 本文旨在回到這個問題.

首先, 它是進化的產物.

本地快取 > 叢集快取 > 分散式快取(資料網格)

使用分散式快取的原因中包括了為什麼使用快取叢集, 而使用快取叢集的原因中包括了為什麼使用本地快取.(譯註: 這句話感覺上真怪.)

效能

訪問本地快取中的一個物件比直接訪問遠端資料儲存引擎(例如資料庫)要快很多.

直接訪問一個已經存在的物件比從資料建立一個物件要快.

• 資料可能已經被儲存在某(幾)個地方了
• 資料可能需要通過多條查詢來被獲取
• 資料可能很複雜

另外, 資料網格支援一些效能調優特性 可能不被叢集快取所支援. 例如, 應用程式可以根據資料之間關聯關係的緊密程度來確保相互關聯的物件被儲存在相同的快取節點上.

更進一步, JBoss Data Grid還有一些自己所特有的效能調優方法, 例如, 它可以被配置成使用非同步通訊並且提供了一個非同步API.

一致性

本地快取只有在應用程式被部署到單一的應用伺服器上的時候才有意義, 如果它被部署到了多臺應用伺服器上的話, 那麼本地快取一點意義都沒有, 問題出在過期資料. 叢集快取通過複製和讓快取資料失效來解決這個問題的.

除了支援JTA事物之外, 資料網格還支援XA(分散式)和兩階段提交事物.

最後, JBoss Data Grid還支援額外支援某些其它資料網格產品可能不支援的保證資料一致性的特性, 例如它支援事物處理恢復, 和基於版本號的更新或刪除.

可伸縮性

叢集快取和資料網格的區別就在於可伸縮性. 資料網格是可伸縮的. 快取資料是通過動態的分割槽被分發的. 結果就是, 增加一個快取節點即提高了吞吐量也提高了容量.

JBoss Data Grid通過使用一致性Hash演算法, 最小化的降低了增加或者刪除一個結點所帶來的結點(譯註: 推薦閱讀這篇文章, 或者這篇, 是中文的), 當增加或者刪除一個結點的時候, 只有一部分資料被重新移動已達到平衡. 所以, 增加或者刪除一個結點只會對資料網格中的一部分結點產生影響, 而別的演算法就很可能會影響到資料網格中的所有結點了.

獨立性

另外一個叢集快取和資料網格之間的不同點即是否支援獨立訪問了.

如果把一個數據網格整合進應用程式裡面的話, 那麼它就和應用程式耦合在一起了, 也就是, 當擴充套件這個內建的資料網格的時候, 同事也需要擴充套件應用程式, 結果, 擴充套件網格的同時, 增加了與之關聯的應用程式(和應用伺服器)的管理成本.

如下面的例子, 一個web應用被部屬到了多個應用伺服器, 並且它使用了內建的資料網格系統, 當這個資料網格快取了足夠多的內容的時候, 它就需要被擴容了.

這意味著什麼呢?

需要安裝並配置一個新的應用伺服器, 然後把應用也部屬到這個新的應用伺服器中.

這意味著?

IT人員需要多管理一個應用伺服器, 增加了管理成本.

• 如果應用被重新部署, 內建的資料網格結點就被重新部署.*
• 如果資料網格升級, 應用升序也得跟著升級(並且重新部署)

* 一個數據網格結點被重新部署的話, 那麼整個資料網格的拓撲結構是會變化兩次的: 一次是當結點被移出的時候, 另外一次是結點被部屬的時候. 並且, 一旦資料網格拓撲結構發生變化, 網格內的資料會在結點之間被移動已達到平衡的(儘管只是一部分資料). 所以, 重新部屬一個應用程式會對其它節點上執行著的資料網格產生影響, 並且是兩次.

如果資料網格需要被調整的執行更快而應用不需要呢?

部屬應用到額外的應用伺服器, 儘管瓶頸並不在應用這裡的話, 這樣合理麼? 考慮了資源利用率了麼? 僅僅為了增加資料網格的吞吐量就增加應用伺服器, 儘管會出現應用伺服器空載, 這樣又合理麼?

解決方案就是使用獨立的資料網格.

如下面的例子. 同樣的, 一個web應用被部署到多個應用伺服器, 但是, 這裡, 它使用一個獨立的資料王哥系統. 這時候, 資料網格達到了它所支援的最大容量, 需要被擴容.

這又意味著?

一個新的資料網格結點被安裝並且配置, 就這麼簡單.

這樣的架構允許資料網格能夠獨立於應用伺服器而被獨立的擴充套件. 也讓資料網格的伺服器能夠被指派與應用伺服器不同的資源. 例如, 一個數據網格結點伺服器可能需要更多的記憶體但是更少的CPU, 相比於應用伺服器的伺服器.

這樣的架構也讓資料網格的基礎架構能夠獨立於應用伺服器的被慣例和調整.

資料網格能夠獨立於應用而被升級, 應用的重新部署也不會對資料網格本身產生任何影響.

基礎架構

對比在基礎架構中作為頂級系統的獨立資料網格和內置於其它系統之中的二級資料網格服務.

舉個例子, 一個企業有一個應用程式部屬於應用伺服器叢集當中, 並且這個應用程式內建了一個數據網格系統. 接著, 這個企業有…

• 增加了一個基於ESB的服務, 這個服務內部也內建了一個數據網格系統
• 增加了一個門戶, 部屬於Portal平臺, 它也內建了資料網格
• 增加了業務流程服務跑在規則管理系統之上, 同樣的, 它也內建了資料網格

能看出問題吧.

現在, 這個企業擁有多個獨立的(內建)資料網格需要被管理, 也就增加了管理成本. 如果它們快取的相同的資料(例如客戶資訊), 那麼, 如同使用本地快取的應用被部署到多臺應用伺服器一樣, 面臨著資料過期的風險. 如果資料被一個數據網格更新了, 那麼, 在別的資料網格當中的相同資料也就沒有意義了, 並且, 如果都儲存的一樣的資料的話, 那麼資料網格的效率也是個問題, 這樣, 只有他們容量總和的一部分是有效被利用的, 如同快取叢集一樣, 重複的資料.

解決方案就是使用在基礎架構中作為頂級系統的獨立資料網格服務.

當然, 使用內建的資料網格服務也有其自身的優點, 可能會也可能不會超過使用獨立快取服務所帶來的好處.

最後, 扼要重述, 使用資料網格的好處是它的可擴充套件性, 和獨立性, 並且, 作為頂級基礎設施元件, 它能夠同時提供本地快取和叢集快取所能夠提供的效能和一致性.