GemFire 是一個位於應用集羣和後端數據源之間的高性能、分佈式的操做數據(operational data) 管理基礎架構。它提供了低延遲、高吞吐量的數據共享和事件分發。 GemFire 充分利用網絡中的內存和磁盤資源,造成一個實時的數據網格 (data fabric or grid) 。算法
GemFire 的主要特性有:後端
Ø 多種網絡拓撲緩存
Ø 高併發的內存數據結構,避免鎖爭奪服務器
Ø 可選的 ACID網絡
Ø 序列化 (native serialization) 和智能緩衝 (smart buffering) 保證消息快速分發數據結構
Ø 同步或異步寫磁盤架構
Ø 冗餘內存拷貝併發
考慮到問題多樣性和架構靈活性, GemFire 提供了多種選項來配置在哪 (where) 以及怎樣 (how) 管理緩存數據,這就使架構師可以從 P2P(peer-to-peer) 、 CS(client-server) 、 WAN 三種組件構建出合適的緩存架構。異步
在 P2P 分佈式系統中,應用程序使用 GemFire 的鏡像 (mirroring) 功能來將大量數據跨結點分區 (sharding) 以及在這些結點間進行數據複製同步。下面主要講一下GemFire 的 P2P 拓撲中的兩個主要角色: mirrored 鏡像結點和 partitioned 分區結點 (具體見 3.2 中 mirror-type 的配置方式 ) 。socket
由於在 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 數據同步在服務器間複製數據時的做用。
Client-Server 緩存容許大量結點相連造成客戶端 - 服務器結構。服務器即爲客戶端提供緩存,也能夠爲其餘服務器提供數據複製或緩存。
P2P 集羣因爲點和點之間的緊耦合而產生了擴展性問題,這種問題在數據中心有多個集羣或數據中心跨城市時被放大。 GemFire 提供另外一種模型來解決。
默認 GemFire 使用 IP 多播來發現新成員,然而全部成員間的通訊都採用 TCP 。對於部署環境禁止使用 IP 多播或者網絡跨越多個子網時, GemFire 提供備用方法:使用輕量級的定位服務器 (locator server) 來追蹤全部成員的鏈接。新成員加入集羣時,將詢問定位服務並創建相似於 IP 多播的 socket 到 socket 的 TCP 鏈接。
每一個成員都會建立一個或多個緩存數據區域 (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 :真正的鏡像,將保存全量數據。適用於須要當即訪問全部數據的結點,以及數據冗餘備份。
這兩個屬性的配置對數據區域中保存的是什麼數據有很大影響:
持久化 (persistence) 將整個數據集拷貝到磁盤,當成員出錯時能夠用來還原數據。而溢出 (overflow) 保存 key 在內存中而 value 保存到磁盤,達到節省內存的目的。二者既能夠單獨使用,也能夠混合使用。
GemFire 支持兩種寫磁盤選項:操做內存數據時同步寫,或者固定間隔異步寫。後一種只當應用在出錯時可以容忍不完整的數據還原時使用。
當內存不足時, GemFire 使用 LRU 策略來決定是否對某個數據項溢出。
持久化與溢出能夠混合使用。全部 key-value 都備份到磁盤,而且當內存不足時,只保留最近使用過的數據。因爲 LRU 而被移除到磁盤的 value 不會對磁盤有影響,由於全部數據已被持久化到磁盤上了。
GemFire 支持緩存事務與 JTA 事務兩種。
每一個事務都有其私有的工做區域。事務開始時,數據將被拷貝到私有區域,直到事務提交。若提交時沒有衝突,則數據從私有區域拷貝回原區域。這樣事務就能夠併發地修改緩存了。
對於範圍 (scope) 配置爲 local 的緩存數據區域,事務提交後就算是完成了。但對於分佈式 (scope=distributed-no-ack or distributed-ack) ,則在事務提交時要進行緩存同步。
( 待補充: OOL)
( 待補充 )