Gemfire:分布式缓存利器

淡淡的烟草味﹌ 2022-07-14 00:10 213阅读 0赞

![Center][]

大数据时代，分布式缓存领域，大家可能较为熟悉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时代的分布式大数据产品入门款必备装备。

![Center 1][]

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

3. 核心概念

![Center 2][]

Region

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

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

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

2Shared-Nothing Persistence

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

3Distributed

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

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

Distrbuted Lock: 分布式集群锁

4Locator & Gateway

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

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

4. 拓扑结构

1. Peer-to-Peer

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

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

![Center 3][]

2. Client/Server结构

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

![Center 4][]

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

客户端服务器发现机制：

![Center 5][]

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

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

![Center 6][]

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

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

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

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

![Center 7][]

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

![Center 8][]

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

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

![Center 9][]

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

![Center 10][]

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

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

![Center 11][]

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

![Center 12][]

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

部署拓扑结构

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

![Center 13][]

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

5. Data Region

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

![Center 14][]

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

![Center 15][]

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

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

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

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

\- 持久化到磁盘

\- 跨节点数据同步

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

\- OQL

1Replicated Region

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

![Center 16][]

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

2Partitioned Region

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

![Center 17][]

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

3OQL

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？ 还真可以。

![Center 18][]

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

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

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

6. 事务支持

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

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

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

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

![Center 19][]

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

工作原理：

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

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

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

![Center 20][]

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

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

7  分布式锁

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

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

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

8. Map Reduce

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

![Center 21][]

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

![Center 22][]

9. Management

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

![Center 23][]

Gemfire支持gfsh command-line执行启动／停止，部署，创建region，执行函数，管理硬盘存储，倒入导出缓存数据，监控process等等，灵活强大；

同时Gemfire支持JMX,  Gemfire Pulse, Data Browser, VSD, JConsole/JVisualVM等。

![Center 24][]

JMX太土？当然，Gemfire提供很多集成工具用来监控内存，磁盘，Region, 网络， 统计分析等等。

下面我们看几个Gemfire Pulse的监控视图：

Cluster监控

![Center 25][]

集群中每个member的状况：

![Center 26][]

Region View:

![Center 27][]

Data Browser, 缓存当然需要一个即视的数据浏览器支持了。

![Center 28][]

10. 12306

是的，12306；国内Gemfire最牛X至少是最著名的应用。当与老外同事介绍时，'12306', 一脸萌相，这名字起的。好吧‘China's Largest Online Trading System’ , 听懂了，有时候需要吹一下。

![Center 29][]

12306的架构正是运行在Linux X86的集群Gemfire, 水平弹性扩展，当年铁道部想必也是调研了众多分布式产品，多重分析评估，最终Gemfire胜出。Gemfire在支持万次／每秒查询，以及高频写／修改，二者兼备的佼佼者。

11. DT时代的Gemfire

临时加一章了，老东家的Gemfire铁粉太多，得来点干货了。

1Roadmap

![Center 30][]

DT时代，Gemfire当然要配合，整合自家的PaaS平台，以及支持HDFS, Spark, Off-heap存储，以及在云端。

2Architecture

![Center 31][]

大数据时代，Pivotal重新定位了Gemfire以及组织了产品线。

![Center 32][]

大数据的三驾马车，涉猎In-Memory Data Grid, Data Warehouse, Haddop SQL。

总结

Gemfire是一款在金融领域称霸，被证实的好产品，目前在新秀Pivotal的领导下，全面进入下一个时代，我们拭目以待。

![Center 33][]

###        ###

**公众号：技术极客TechBooster**

![Center 34][]

[Center]: /images/20220714/c5b93e836f8d4597bc69dad455bd0034.png
[Center 1]: /images/20220714/ecf5a6daf71b40de8042605395e4887b.png
[Center 2]: /images/20220714/f32f82640cc04e73a646baeb489b96ae.png
[Center 3]: /images/20220714/684588a4d90b4771ab03d9090138cbd6.png
[Center 4]: /images/20220714/1d083947a2ce4d3b850fbef25dbfa38e.png
[Center 5]: /images/20220714/ac4b9978f0fa4716b09732942b4560f5.png
[Center 6]: /images/20220714/7197cef043ae4a2ebb1748e90b2c28df.png
[Center 7]: /images/20220714/a6d382f4629743efa4bfef82922d2a75.png
[Center 8]: /images/20220714/0aab9ab2fcc948138a7716133fbf7a9d.png
[Center 9]: /images/20220714/7a22580c448c4df090affdec115e1985.png
[Center 10]: /images/20220714/2fff44b43dcf490581058480fd32cca6.png
[Center 11]: /images/20220714/c41c5ebcedf54eb5af35cbe2d32cb442.png
[Center 12]: /images/20220714/c2574b2642a8415e9a01b8c47de4656a.png
[Center 13]: /images/20220714/eca5131a23504adba58f5daf1aadcc79.png
[Center 14]: /images/20220714/384f81fabd734e089b2a98c38e9a9f89.png
[Center 15]: /images/20220714/7b2a6e291f3f4e9bb423beb2d4204ac6.png
[Center 16]: /images/20220714/0064e0ce45a345f7baaf88aef23542aa.png
[Center 17]: /images/20220714/185db2a8cc6c42e087145384bfd4c87e.png
[Center 18]: /images/20220714/3ccaba5eb37047b6a69e0c32ab0d4155.png
[Center 19]: /images/20220714/9eda7f19bdb043fe91d2e56af276f85f.png
[Center 20]: /images/20220714/8086a756094d45a4a9945d88d16261f2.png
[Center 21]: /images/20220714/0a712519fc2540bc9607eab656bdf1b8.png
[Center 22]: /images/20220714/39ac17d537324fdbb1bd10dc89ef93dc.png
[Center 23]: /images/20220714/a227e939bf6a45d8ab76f7e5af5e8e6d.png
[Center 24]: /images/20220714/8080abc2d6f941b1addd97bd35402649.png
[Center 25]: /images/20220714/374cf5cc6e5c4967b6cc6b7e0671084d.png
[Center 26]: /images/20220714/c674ea053bba4457b9e9af8eccfc2a66.png
[Center 27]: /images/20220714/d42d51ab94cf4f96b2ad94d9b5ec42de.png
[Center 28]: /images/20220714/e7e20305b7b24d9ab5b7ae2665b79f33.png
[Center 29]: /images/20220714/e2a69b536ca04dcea439473f84fe7d91.png
[Center 30]: /images/20220714/74a266b6a2ef43feb0c44997436bb8dc.png
[Center 31]: /images/20220714/3606ef60be69403bb11aaa0ed524549a.png
[Center 32]: /images/20220714/9bb7a2f3bfa64ad1b62f53831871205d.png
[Center 33]: /images/20220714/ff3f41d3b1ab403a9619f5cb355635b3.png
[Center 34]: /images/20220714/0f696d1e48424386af3afd9dfc9ec2f9.png