共計 3540 個字符，預計需要花費 9 分鐘才能閱讀完成。

今天給大家介紹一下如何分析 GemFire 架構。文章的內容丸趣 TV 小編覺得不錯，現在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著丸趣 TV 小編的思路一起來閱讀吧。

1  什么是  GemFire

GemFire  是一個位于應用集群和后端數據源之間的高性能、分布式的操作數據 (operational data)  管理基礎架構。它提供了低延遲、高吞吐量的數據共享和事件分發。 GemFire  充分利用網絡中的內存和磁盤資源，形成一個實時的數據網格  (data fabric or grid) 。

GemFire  的主要特性有：

?  多種網絡拓撲

?  高并發的內存數據結構，避免鎖爭奪

?  可選的  ACID

?  序列化  (native serialization)  和智能緩沖  (smart buffering)  保證消息快速分發

?  同步或異步寫磁盤

?  冗余內存拷貝

2  網絡拓撲和緩存架構

考慮到問題多樣性和架構靈活性， GemFire  提供了多種選項來配置在哪  (where)  以及怎樣  (how)  管理緩存數據，這就使架構師能夠從  P2P(peer-to-peer) 、 CS(client-server) 、 WAN  三種組件構建出合適的緩存架構。

2.1 P2P  拓撲

在  P2P  分布式系統中，應用程序使用  GemFire  的鏡像  (mirroring)  功能來將大量數據跨結點分區  (sharding)  以及在這些結點間進行數據復制同步。下面主要講一下 GemFire  的  P2P  拓撲中的兩個主要角色： mirrored  鏡像結點和  partitioned  分區結點  (具體見  3.2  中  mirror-type  的配置方式  ) 。

因為在  P2P  拓撲中緩存數據與應用在一起，所以首先說一下嵌入式緩存。所謂嵌入式緩存  (embedded cache)  其實就是說緩存和應用程序在一起，直接利用應用服務器的內存空間。也就是我們常說的類似  Ehcache  的那種本地緩存  (local cache) 。

mirrored  結點   就像一塊磁鐵一樣，將其他數據區域的數據都吸附過來，形成一塊完整的數據集合。當一塊數據區域被配置為  mirrored  的結點第一次新建或重建時，GemFire  將自動執行   初始鏡像抓取  (initial image fetch)  操作，從其他結點的數據子集中還原出完整的狀態。如果此時網絡中存在另一個  mirrored  結點，那么將會執行   最優直接抓取  (optimal directed fetch) 。

所以我們很容易看出， mirrored  結點主要出于兩種目的：

?  對于大量讀的應用，應用程序通過保存全量數據，使客戶端請求可以即時訪問到想要數據，而無需經過網絡傳輸

?  當發生故障時， mirrored  結點可以用來恢復其他結點

不同于  mirrored  結點，每個  partitioned  結點   都持有唯一的一塊數據。應用程序就像操作本地數據一樣， GemFire  在幕后管理各個分區的數據，并且保證在至多一跳內 (at most one network hop)  完成數據訪問。根據  GemFire  的哈希算法，分區數據會被自動放入到各個結點的  bucket  中。同時  GemFire  也會自動分配出冗余數據的位置并進行復制。當某個結點出錯時，客戶端請求會自動被重定向到備份結點。并且 GemFire  會重新復制出一份數據，從而保證數據的冗余拷貝數。最后，我們可以隨時向網絡中加入新的結點來對  GemFire  集群進行動態擴容。

P2P  系統提供了低延遲、單跳  (one-hop)  數據訪問、動態發現以及透明化的數據存儲位置。但是，網絡中的每個結點都要維持一個  socket  連接到其他每個結點。當結點增多時，連接數將成指數級增長。為了提高擴展性， GemFire  提供了一種可靠的  UDP 多播的通信方式。在下一節中我們將看到， P2P  數據同步在服務器間復制數據時的作用。

2.2 Client-Server  拓撲

Client-Server  緩存允許大量結點相連形成客戶端  –  服務器結構。服務器即為客戶端提供緩存，也可以為其他服務器提供數據復制或緩存。

2.3 WAN  拓撲

P2P  集群由于點和點之間的緊耦合而產生了擴展性問題，這種問題在數據中心有多個集群或數據中心跨城市時被放大。 GemFire  提供另一種模型來解決。

3 GemFire  工作原理 3.1  發現機制

默認  GemFire  使用  IP  多播來發現新成員，然而所有成員間的通信都采用  TCP 。對于部署環境禁止使用  IP  多播或者網絡跨越多個子網時， GemFire  提供備用方法：使用輕量級的定位服務器  (locator server)  來追蹤所有成員的連接。新成員加入集群時，將詢問定位服務并建立類似于  IP  多播的  socket  到  socket  的  TCP  連接。

3.2  數據分發

每個成員都會創建一個或多個緩存數據區域  (data region) ，通過區域的劃分，我們能給每個區域配置不同的分發屬性、內存管理以及數據一致性模型。默認  GemFire  使用  P2P  分發模型，每個成員都能和其他任何成員通信。同時根據不同的內網特點，傳輸層可選  TCP/IP  或可靠多播  (UDP) 。在這些配置中，有兩個屬性很重要，范圍 (scope)  和鏡像類型  (mirror-type) 。

首先，范圍  (scope)  有四種選項：

? Local ：不分發。那為什么不直接保存到  HashMap  中。因為  GemFire  額外提供了數據自動持久化到磁盤、 OQL(Object Query Language)  查詢數據、數據操作的事務等特性。

? Distribute-no-ack ：發送數據給成員  1 ，在發送數據給成員  2  時不等待成員  1 的響應。適用于對數據一致性要求不高，并要求低網絡延遲的情況。這是  GemFire  的默認配置，能夠提供低延遲、高吞吐，并通過盡快分發來降低數據沖突的概率。

? Distribute-ack ：在發送給成員  2  前，發送數據并等待成員  1  的響應。這樣每條數據都是同步分發的。

? Global ：分發前在其他成員上獲得鎖，再分發數據。適用于悲觀的應用場景，通過全局鎖服務來管理鎖的獲得、釋放和超時。

現在來看一下第二個重要的配置屬性鏡像類型  (mirror-type) ：

? none ：僅當緩存中有此數據時才更新，任何其他成員發來的新數據都會被忽略掉。適用于某一數據區域僅用來保存另一區域數據的子集。

? keys ：數據區域僅保存  key  來節約內存，當真正有請求時再從其他區域抓取數據并保存到本地，之后接受對此數據項的更新。適用于無法預測哪些數據會被某一結點訪問的情況。

? keys-values ：真正的鏡像，將保存全量數據。適用于需要立即訪問所有數據的結點，以及數據冗余備份。

這兩個屬性的配置對數據區域中保存的是什么數據有很大影響：

4  持久化和溢出

持久化  (persistence)  將整個數據集拷貝到磁盤，當成員出錯時可以用來還原數據。而溢出  (overflow)  保存  key  在內存中而  value  保存到磁盤，達到節省內存的目的。兩者既可以單獨使用，也可以混合使用。

4.1  持久化

GemFire  支持兩種寫磁盤選項：操作內存數據時同步寫，或者固定間隔異步寫。后一種只當應用在出錯時能夠容忍不完整的數據還原時使用。

4.2  溢出

當內存不足時， GemFire  使用  LRU  策略來決定是否對某個數據項溢出。

4.3  混合使用

持久化與溢出可以混合使用。所有  key-value  都備份到磁盤，并且當內存不足時，只保留最近使用過的數據。由于  LRU  而被移除到磁盤的  value  不會對磁盤有影響，因為所有數據已被持久化到磁盤上了。

5  事務

GemFire  支持緩存事務與  JTA  事務兩種。

5.1  緩存事務

每個事務都有其私有的工作區域。事務開始時，數據將被拷貝到私有區域，直到事務提交。若提交時沒有沖突，則數據從私有區域拷貝回原區域。這樣事務就可以并發地修改緩存了。

對于范圍  (scope)  配置為  local  的緩存數據區域，事務提交后就算是完成了。但對于分布式  (scope=distributed-no-ack or distributed-ack) ，則在事務提交時要進行緩存同步。

以上就是如何分析 GemFire 架構的全部內容了，更多與如何分析 GemFire 架構相關的內容可以搜索丸趣 TV 之前的文章或者瀏覽下面的文章進行學習哈！相信丸趣 TV 小編會給大家增添更多知識, 希望大家能夠支持一下丸趣 TV！