Gemfire:分布式缓存利器

大

数据时代，分布式缓存领域，大家可能较为熟悉Redis，当红一哥，还有经典老将Memcached, 以及新秀Apache Ignite, 当然还有Oracle的Coherence内存数据网格，今天我们主要关注投行金融领域的分布式缓存一哥Gemfire。

1. 前世今生

Gemfire的第一个商业版本由GemStone公司操刀正式发布于2002-2003年间，成为业界J2EE JCache -JSR107标准的中间件，兼容Java, C , C#, 并在CEP(Complex Event Processing)处理领域一枝独秀。2008年借着金融危机之际凭着其实力击败老牌厂商Oracle, 大举进入华尔街金融领域，而其中Citi则是Gemfire的铁粉，据称全球2/3的Gemfire应用跑在Citi的服务器上，尤其是固定收益类交易系统的最爱，各位老友看到请自动点赞举牌。

之后GemStone被Spring之父Rod Johnson在当时的VMare时慧眼识珠，2010年收购并入SpringSource部门作为进军Cloud以及大数据的入口，目前则与Spring一并成为Pivotal中重要的In-Memory Data Grid, 并于2015年其核心模块开源为Apache Geode核心项目。

2. Gemfire整体分布式架构

总体来说Gemfire提供了基于内存的海量数据实时处理平台，包括低延迟高吞吐，线性动态扩展

（流行的话叫“弹性水平扩展”），HA，MapReduce，听起来很Hadoop, 这些是一切后SQL时代的分布式大数据产品入门款必备装备。

可以粗略看出Gemfire一些精髓，如支持CEP Subscribers, 数据支持Replicated, Partitioned, 线性水平扩展，Shared Nothing Disk Persistence, Cache同步Read/Write Through与异步Write Behind。

3. 核心概念

Region

Region是Gemfire中一Map的分布式实现，同时具备了支持查询，事务。这个是Gemfire的核心中核心，一切的一切始于此。

Replicated Region: 一个Replicated Region保存所有分区的数据拷贝。

Partitioned Region: 只保存一部分分区的数据拷贝。

Shared-Nothing Persistence

支持非共享持久化，每一个peer持久化数据到本地磁盘，Gemfire持久化允许在磁盘维护一份配置的数据拷贝

Distributed

Distributed Member: Gemfire托管的集群中成员

Distributed Transaction: 跨节点，集群更新事务，分布式事务。

Distrbuted Lock: 分布式集群锁

Locator & Gateway

Gemfire的Locator类似ZooKeeper, 协调客户端与服务器成员，相互发现，以及简单负载均衡（非负荷均载）。

Gateway: 作为Gemfire跨WAN网同步数据，如HK, TK, NY等。

4. 拓扑结构

1. Peer-to-Peer

缓存潜入应用，共享堆内存，适合小型缓存应用。

原以为这种架构在企业，金融机构无用武之地，殊不知一些大型金融机构的小型IT项目竟然采用此架构，没办法cowboy，今天需求明天生产。

2. Client/Server结构

缓存层由分布式集群系统来组成，是多数中大型系统首选。

其中分布式引入Loactor来管理，结耦，离散，分布客户端与服务器端。

客户端服务器发现机制：

上图可以看出客户端与服务器通信要先透过Locator提供的发现机制，当然鉴于此所有的服务器端必须与Locator进行通信广播其生死状态，类似ZK。Locator通过JVM广播消息或者TCP实现通信定位。每个新加入或者离开的成员都会更新Loactor，并从Locator上发现目前可用成员列表。

我们看一下客户端完整通信图：

另外，Locator可以提供简单负载均衡，只是基于当前服务器是否有客户端连接而已。

Gemfire提供了垮节点将键值对均匀分布到节点，以及一致性哈希算法等。

如果希望定制负载负荷均衡，Gemfire提供了Member Groups，可以把某些服务器分组，固定为某些客户／某类请求服务，再获得负荷均衡的优势同时也失去了全局分布式的优势，正所谓有利有弊。

Server内部提供了connection poor，queue以及subscription机制，以并行处理以CEP事件通知机制。同样，Gemfire客户端也提供了connection pool。

经验丰富的老司机看到这里肯定会说，全局就一个Locator一定会造成单点故障，当然分布式系统的必备。Gemfire也提供了启动多个Locator的能力。

3.多地／多数据中心WAN部署

互联网世界比较流行，行话异地多活，全国甚至全球多地多数据中心部署。大型金融系统中也是不可或缺的，如全球多金融中心部署，NY, London, HK, TK等分布式多数据中心缓存。做的好的话，可以做到任意一个数据中心瘫痪，系统自动切换到其他数据中心运营，差的话就要人工干预了，不过至少不会完全瘫痪。

多数据中心的数据同步则是靠gateway来同步的，gateway receiver与gateway sender来发送接受数据中心的变化，如上图东京如果有缓存数据变化，新增或者变化，则会通过gateway发送给纽约的集群，通过gateway receiver来更新纽约的缓存，由于跨多地，网络，所以非实时同步更新，做到最终一致性。当然sender中必须提供了queue。

一个数据中心的集群是靠Locator来维系发现各个服务器的，对于跨多数据中心，Gemfire则通过每个集群的distributed-system-id，依靠remote-locators来发现数据中心集群是否存活。

如下图定型的全球部署系统架构：

多数据中心支持多种拓扑结构，如Parallel则是每个数据中心均相互感知，当然其数据同步，通信也必然耗资源。

当然，还有其它多种网络拓扑，介于每个数据中心网络，带宽以及其它因素，最好与网络系统人员一起设计网络拓扑结构。

部署拓扑结构

新版的Gemfire 8.x支持多种部署拓扑结构：

图是Pivotal的黑酷炫风格，放到微信图太小了，不解释，基本是我们上面的细分与组合。

5. Data Region

上文介绍过，Region是Gemfire中用来管理，存储数据的核心数据结构，本身实现了Map接口，类似于ConcurrentMap，同时支持分布式跨物理节点。

Region同时支持嵌套，子Region。Region又区分为Patitioned，Replicated, Distributed non-replicated, Non-distributed(local)。

Gemfire的Data Region的读写操作支持同步读，同步写，异步写。

数据分布模型支持D-no-Ack, D-Ack, Global（锁)。

此外，Region还进行分布式支持以下高阶：

- 溢出至磁盘持久化（LRU）

- 持久化到磁盘

- 跨节点数据同步

- 外部数据源（数据库）延迟加载数据

- OQL

Replicated Region

Replicated Region在每个Gemfire成员上都同步的保存一份完整的数据拷贝。Proxy：数据不存在本地缓存，Proxy成员提供了对Region的访问，需要其它成员配置Region的Non-Proxy拷贝用以存放数据。

显然这是以空间换时间；这种Data Region适用于小型数据集并且读很频繁的操作；

Partitioned Region

Partitioned Region顾名思义，将数据分散，每个成员近保存数据一部分，时间换空间；

既然分区存储了，一定是适合大数据的数据集了，以及写／修改较多的数据集，并提供给了分布式并行查询，处理, MapReduce。

OQL

Region提供类SQL, 基于SQL-92子集的OQL查询，注意可以跨分布式节点以及并行查询，这点是很多缓存不具备的，尽管简单。

SELECT, WHERE, DISTINCT, COUNT, IN, LIKE, 嵌套自查询，Map查询（ p['key'] = '1.0' ），ORDER BY,。

注意，OQL仅支持COUNT, 不支持其它SUM, MIN, MAX。

另外，OQL支持Limit, 类似TOP:

SELECT * FROM /Region1 limit 100;

这里还提供高阶的Join, 大多数No-SQL都不支持，这里因为更类似二维表格，也提供了Join操作，如下：

SELECT * FROM /Region1 r1, /Region2 r2 WHERE r1.status = r2.status;

可见，还是相对较熟悉，强大。当然这里的Join仅支持内连接，并不支持左右连接，毕竟没有那么强大。

既然可以提供OQL查询，支持Join, 那老司机又问是否可以做Index？还真可以。

当然也支持代码动态创建了。当然，没有免费的午餐，与RDBMS类似，索引是把双刃剑，提供索引必然会降低修改，更新性能，提升查询性能。

用惯了Oracle了老鸟，这里居然也支持HINT，好吧。

当然，也不建议用过度负载的OQL，毕竟不是强大的RDBMS，况且考虑到兼容性，可移植性，以及没有那么强大的调试支持。

6. 事务支持

事务的操作首先作用在数据主拷贝节点，然后分布到其它成员。其中：

- 运行事务代码的成员被称作事务初始化器

- 管理事务和数据的成员被称为事务数据节点

Gemfire提供了分布式事务支持，难能可贵，在分布式世界里，提供分布式事务可比较重！所以尽量少用，开销太大，甚至可能全局死锁。

Gemfire同样提供了分布式锁支持，可以显示创建分布式锁，在任何一个时间点，

工作原理：

在并发访问缓存的时候，事务之间是隔离的。每一个事务都有自己的私有空间，包括已经读取的数据及其变更；当一个数据条目进入事务时，将在事务视图／空间生成一个数据状态的快照，此事务能保存数据的原始状态，快照的另一个作用则用于题解恢复写冲突。

当事务提交成功时，事务视图中的记录被合并到缓存上，如果提交失败或者回滚，则所有变更将放弃。提交事务时，Gemfire采用了两阶段提交协议, Two-Phase commit Protocol。

Gemfire甚至支持了JTA分布式事务：

惨不忍睹，自己官方文档都放不下该图，可见复杂。不推荐，不建议。

通常，非必需，不建议使用分布式事务，因为会大大降低整体的性能，这与使用缓存的本意背驰。

7 分布式锁

Gemfire也提供了分布式锁支持，在任何一个时间节点，Gemfire系统保证只有一个线程可以用于该锁。另外线程将锁定整个服务，防止系统中其它线程锁定这个服务。可见其成本之高。

分布式锁分为隐式锁与显示锁。大多数情况下，系统自动利用隐式锁进行数据操作。锁服务从系统成员接受锁请求，并放入队列，按顺序授予锁。授予者负责运行锁服务。

当分布式锁服务创建时，分布式系统中某个成员通过选举成为分布式锁服务的授予者，授予者负责管理这个锁。当这个成员出现故障时，锁授予功能将被迁移到其它成员，且不丢失锁状态；这些细节处处可以看到分布式设计的目标及精髓。

8. Map Reduce

Gemfire与时俱进，提供了在分布式节点进行Map Reduce的操作函数。

函数用Java自行编写，部署，运行。Gemfire支持两种形式的函数运行模式，方式1，提前注册并部署自定义函数到每个成员，运行时指定函数名字，显然不灵活，高耦合，每次改动函数都要全局部署；方式2，运行时动态ship函数，所谓ship function rather than data；更加现代的模式（从Gemfire 6.x开始支持）当然为了做到这种高效，必然要RPC 序列化，所谓有利有弊，好处显然易见，首选推荐。

9. Management

分布式系统的Dev & Ops中的Ops也是重中之重，侧面反映一个分布式系统的成熟度。