如果说CPU是大脑,内存是演算纸,那么存储就是我们的笔和答题卡。在我们日益追求高速计算的时候,也千万不要忽略我们的答题卡。
存储的读写速度、安全性和稳定性直接影响了大规模集群的性能。多数集群不会因为内存或者CPU损坏而损坏。但是如果因为存储出现了问题,哪怕是一点点的问题都可能让我们上百上千的计算节点瞬间变成废品。
那么我们该如何选择合适自己的存储配置呢?不妨来了解一下Pivotal的GemFire家族产品。
内存数据网格、分布式缓存以及分布式内存数据库都属于储存产品,它们的共同特点是:首先,都基于NoSQL的架构、基于内存和分布式架构;同时,这些存储产品都具有水平的弹性伸缩能力,即通过水平性的增加节点来实现数据或者计算能力的伸缩。
那么,三种主存计算的产品又有什么差别呢?
- 分布式缓存。分布式缓存是这三者中架构最简单、最能解决问题的产品类别。通过将频繁访问的数据从磁盘移到内存中,从根本上解决了磁盘IO瓶颈对于数据速度的限制。同时,分布式的架构可以实现数据的同步。作为一种简单的K86式的存储,其初期功能比较简单,便于学习和使用,后期逐步加入事务,分区,过期处理等高级功能。
- 分布式内存数据库(IMDB)。IMDB提供类似数据的SQL查询以及类MPP功能,强调查询的复杂度,通过水平扩展提升计算能力。
- 内存数据网格(In Memory Data Grid ,简称IMDG)。数据网格产品从设计之初就充分考虑网络的优势,它更强调的是一种集群的概念,让分布式系统成为了一个集群。现在成熟的产品(比如GemFire或者其开源版本)可以支持非常大规模的集群,上百个节点可以组成大规模集群,且内部自动协调一致。另一方面,在分布式缓存的基础上,内存数据网格的功能更加成熟复杂化,比如说分区、ACID事务、函数、事件处理等复杂功能。它的水平弹性扩展能力要远比前两者更高,是在成百量级上扩展。例如GemFire非常适用于现在流行的微服务架构。同时,作为一个集群性产品,其消息传递是非常可靠的,在一定程度上可以代替Kafka或者RabbitMQ的产品。
今天本文主要介绍Pivotal GemFire/Apache Geode。
一、GemFire家族图解
GemFire家族图解
介绍一下GemFire在不同形态下、不同时期、不同方向的发展。
中间是最早的、也是目前依旧维持商业属性的GemFire本身。上面是在开源方向做的Geode。这两者是GemFire家族里最重要的产品。左边是GemFire在向云端衍进所做的努力,左下角是我们在Cloud Foundry平台上推出的GemFire版本,是一种云端缓存,名称Cloud Cache ,同时GemFire也支持在AWS平台上的云端演进。
图中的两个灰绿色产品,GemFire for PCF和SSC for PCF也是历史上在PCF平台整个过程中GemFire团队曾做出的尝试,这两个产品后来都统一由Cloud Cache取代 。
右边方向是GemFire在多产品结合的方向,右下角是现在主推的GGC,它是和Pivotal公司另外一个产品Greenplum结合的组件,它可以实现两个产品之间的数据互通、互联,一一关系对应。
SQLFire或者叫GemFire XD,这个产品的设计初衷是由于曾经一度考虑对GemFire加入标准SQL的支持,GemFire自身使用的查询语言是一种类SQL,叫对象查询OQL。 这个产品比较类似于我们Geode版,后来发展成SnappyData,现在他们已经作为独立的公司自行发展。
GemFire是一个很庞大的家族,从一个最中心的数据网格产品,经过漫长的历史,发展成了家族性的产品族。事实上,GemFire在一定程度上可以取代分布式缓存,也可以取代分布式内存数据库,因为GemFire本身具有强大灵活的配置和功能。
二、Pivotal GemFire/Apache Geode的特点:
这是最新版本的GemFire的架构概览,如图所示,GemFire支持了几种不同客户端类型,并且有丰富的数据管理方式,另外在系统内部还有一种特别的功能——Locator定位器的组件,这是GemFire非常有特点的功能。凭借Locator的特殊作用,GemFire可以满足更多的特殊需求。比如在分布式系统里面有一个常见的拜占廷问题,会最终导致集群的分裂和状态不一致。而借助于Locator的管理功能,GemFire可以在很大程度下降低拜占庭问题发生的概率。
三、Pivotal GemFire典型应用场景
正因为GemFire有这样一种优势,我们可以看到GemFire一般有以下几种应用场景:
- 第一,企业缓存。GemFire最可靠的特点是,它是一种高可用而且有非常复杂的架构支撑。
- 第二,它有一种弹性内存计算,在低峰期可以减少节点,进行热伸缩。在高峰期可以直接在不影响集群正常工作的情况下,增加节点数。
- 第三,支持大型实时实务性应用程序。这个应用在金融、交通行业使用的比较多,比如说投行、交通运输等行业客户, 因为客户不仅是需要速度快,而且其中会有复杂的事故逻辑。
- 第四,弹性流处理。现在物联网的概念比较火,其特点是有大量节点会加入集群,同时伴随着大量的数据涌入,这时候GemFire会提供非常好的支撑。
- 第五,微服务推进器。现代微服务架构需要对数据请求和协调快速响应。由于微服务体系结构的基本原理是无状态,因此需要一个单独的数据层来存储其状态。随着应用程序的使用增加,要求微服务的数据高可用性和可延展性。 GemFire提供了基于云延展的状态管理系统。
四、行业案例分享
Pivotal GemFire – Usage By the Numbers
案例一:铁路订票系统
从全球来看, GemFire覆盖了全球人口中的37%的火车订票业务, GemFire不单服务于中国的12306, 也是印度铁路购票系统的核心部分。 在12306, 根据2017年春运的数据, 每天订票数量超过900万张,完成一次订票需要进行多次余票查询,多次订单查询和常用联系人的查询,所以每天对于GemFire集群的访问数量是要远远超过订票数量的。 特别是在春运高峰时期,由于抢票的原因, 查询请求的数量还会大大增加。 在印度铁路,GemFire集群更是支持了每天12亿次的点击,对于印度铁路的电子车票系统提供了有力的支持。
Data Distribution
案例二:金融行业
这张图是比较典型的金融行业的用例,用GemFire实现的全球三个地区、三大洲之间的数据沟通,不仅本地的应用要直接提交到本地的集群里,在各大洲的集群也要通过远端的广域网的架构实现数据同步。这种数据同步在一些企业里可以做到毫秒级的同步性。虽然是最终的一致性,但是它的实时时延很短暂。
案例三,是我们在南美洲的一个客户。前端包括POS机、手机在内,都是作为广义应用而直接访问GemFire集群。而GemFire集群也通过这种远端的数据一致性在不同的地方完成数据同步。同时GemFire后端也会与传统的数据库架构完成数据的连接。
Pivotal GemFire经典部署架构
这张图是2012年的GemFire部署架构图,对应的版本大概是GemFire6.6,我们可以看到这张图里的功能已经非常复杂、非常完善了,堪称GemFire非常经典的数据架构,经典数据架构里有嵌入式的部署,嵌入式的集群,分层的集群,还有分布式的集群,以及全球同步的分布式集群。
五、GemFire的新版本与新功能
时间又过了五年多,GemFire又发布了3个版本,主要做了哪些优化和改进呢?
GemFire7的新增功能
- 支持存取JSON文档。向GemFire Cache增加JSON文档时,可以通过调用JSONFormatter API 把JSON 文档转化成 PDX格式(PdxInstance),允许GemFire从字段级别理解JSON 文档。
- 支持逻辑成员组以及针对成员组执行函数。用成员组(Member groups)替换了服务器组(server groups), 成员组可以用来进行备份操作,部署Jar。
- 通过 Gemcached 原生支持 Memcached 客户端。
- WAN-网关优化。
- 为分布式Region添加了一致性检查:一致性检查确保在所有成员和客户端上的分布式Region最终达到一致状态,也包括在广域网上部署的使用Region事件的成员。
- 统一的 GemFire SHell (‘gfsh’) 命令行工具:重新改写GemFire SHell (‘gfsh’) ,可以支持Locator和CacheServer启停操作,查看状态,创建和修改Region,发布Jar,备份和导出数据等。
GemFire 8 的新增功能
GemFire 8 的改进更为有效,意义更为重大。
- 首先是管理和监控方面,开始提供图形化工具以达到更好的维护管理集群目的。gfsh支持更多的命令,可以更好地管理集群,并使用集成的JMX vs.单独的代理进程。
- 其次是自适应能力。GemFire本身是一个自动管理能力非常强的系统,GemFire 8在产品的自适应能力上又做了很强的改进,推出了集群的自动重联功能。由于网络或其他原因,节点可能会不定时的掉线。推出集群的自动重联功能之后,这些节点就可以自动重联。
- 同时还提出了并行WAN连接,也开始支持主版本之间的滚动升级,比如从GemFire8.1到8.2的升级里,可以做到7×24小时不停机,通过逐步的滚动升级,最终完成整个集群升级的操作,而不影响服务的连续性。
- 最后也是比较流行的一点,即支持RESTFUL API,用一个命令就能拿到反馈的结果,实现对集群的访问和管理。
GemFire 9 的新增功能
- 第一个比较明显的变化是支持JAVA堆外内存管理。GemFire是基于JAVA开发的产品,最初,其服务器端完全依靠JVM来管理内存,但是随着用户的增加,发现单节点容量也不断增加,在全球或者国内一些客户里,单节点一个JVM里面就开始存放上百G的内存。而这种方式放在JVM中完全管理是不太合理的。针对这个问题,我们提出了堆外内存。JVM管理内存控制在32G大小,假如有100G或者200G的内存,则全部放在堆外,用操作系统控制,以提升数据管理的有效性,支持使用更多内存,减少GC停顿,提升性能。
- 整合式安全机制。GemFire有很多种拓扑逻辑,包括多种不同的客户端,比如C++、JAVA等等,每一种不同的通讯协议都有自主的安全协议。在GemFire9中推出了统一的安全机制,不管是哪种类型的通讯协议,集群内、集群外、客户端,以及全球的广域网,都用统一的安全认证机制进行管理,以此提升整个系统的安全性,且所有的功能均可控。
- SSL方面的配置简化,功能加强。
- 与其他内存数据网格一样,GemFire也支持session的外置化,提供应用服务器的会话管理功能,同步开始支持Tomcat8的使用。
- GemFire加入Lucene引擎索引的支撑,进而可以不使用GemFire自身自带的查询语句,而使用Lucene去查询。
- 验证性功能。通过内置模块,可以替换Redis。GemFire 9推出了Redis适配器。在前端使用Redis的应用无需做任何改变,就可以用同样的方式访问GemFire。此外,还加强了OQL——GemFire自带的数据库查询功能,支持max,min,avg和order by。以及Rebalance的性能优化,这个功能指的是在上百个节点中如何去平均的分配数据存储、数据负载。在GemFire9之后,可以支撑自动定时按需的Rebalance操作。
六、开源社区和商业版本同步发展
GemFire最优秀的一个特点,就是百分之百的开源化。大概是在GemFire 8的时代就开始筹划将其开源,于是在GemFire9的时代把Geode这个开源社区版本正式开源,如今已经过了三个版本的更新。
这两个产品来自同一个分支,其代码也是完全百分百的一致。这两者的区别在于:商业版本经过更多测试,可靠性自然更强一些;而开源版本的更新速度更快。因此大家可根据自己需要而选择。但是有一点要注意,不管GemFire9.0也好,Geode1.1也好,并没有严格的对应一致性关系。 这两个版本虽然共享代码,但是它们是独立发展的。两者的版本并不存在完全的一对一的对应关系。
GemFire官方产品的网址:https://network.pivotal.io/products/pivotal-gemfire
GemFire全球社区网址:http://geode.apache.org/
中文社区的网址:http://opengeode.cn/
技术咨询: 400-135-8900
责任编辑:
版权声明:
本文来源网络,所有图片文章版权属于原作者,如有侵权,联系删除。
本文网址:https://www.mushiming.com/mjsbk/12006.html