如何分析GemFire架构

共计 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！