【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014，关注关注中国数据库技术大会公众号）现场演讲嘉宾杨旭钧老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼
讲师简介
▲杨旭钧
Apache Geode官网开源社区贡献者、提交者，中国社区发起人，宝隆捷(Bloom)信息技术有限公司CTO，有着多年的银行、保险行业的金融系统的规划，设计和开发经验，参与过多个国内外银行、互联网电商与移动支付领域项目。曾就职于VMware和 Accenture两家公司，服务客户包括花旗银行、中国外汇交易中心、中国央行、中国银行、中国交通银行等。 Gemfire开源社区发起人，负责在国内推广Apache Geode在国内的使用，对国内Gemfire用户的提供技术咨询和培训工作。 目前正在创办一家提供大数据分析处理服务的公司，公司产品Jaguar快数据处理平台主要可应用于电子商务、电信、物流交通、金融、医疗、信息安全等多个行业。
正文
大家好，我今天分享的主题是《GemFire在移动互联网或电商应用方面的技术分享》，我的议题主要分为如下四部分:
首先我借鉴了Facebook典型应用架构，它把主页的页面进行了拆分，把页面点击存在不同的Memcached集群，同时做了贯通，但自身还是有一定问题。
首先拆分主页和其他页面的点击访问，使之变成一个分布式集群，数据不保存在单台服务器上，保存于多台服务器集群中，跨所有集群的服务器快速拉取数据到前端页面。
采用并发数据查询其实就是并行转发get请求，不同的object有不同的大小和方式，同时它也拆分不同的object类型，以达到高效的内存利用率，其实这些东西在GemFire上全有，其本身的内核平台已经支持了。
其次是解决前端连接拥塞问题，比如服务器运行50到100个进程，Memcached可能有10万个请求进行连接，这个也是有双模式的，TCP长连接也可以连，UDP也可以连。目前来讲，压缩是使用gzcompress压缩序列化字符串。
目前 GemFire 与Web Server已经做了很深的集成，将GemFire客户端嵌入到Web server当中，Web Server从GemFire客户端读写数据再同步给GemFire Server。
GemFire客户端可以有好多，如果采用拆分的方式可以有10个，20个，30个客户端，并发访问下面的集群，中间通过协调器维护整个集群的客户端和节点的关系。如果后面还有DB的话，也可以跟DB进行交互。整体架构大致如图所示：
12306余票查询现在的集群规模是100多个节点，实际可以达到256个节点，因为这是性能集群节点数整体的平衡，256个应该是没问题的，再大就不行了。因为其底层基于TCP 协议, 维护集群成员关系的网络开销较大，测量的是整个集群中最低的延迟来维护节点之间的关系，各节点之间如果掉了的话，反应就不太灵敏了。
Memcached整个集群的扩展有一个标准，Magent利用一致性hash分配值到Memcached节点，进而告诉前端应用把数据存到哪。这样会出现一个问题，它并没有服务端的分布式，只是一个伪分布式，不能达到完全分布式。如果集群动态添加节点的话，会严重影响缓存命中率。
GemFire开发了一个叫Gemcached的东西，它也是一个服务器，把它嵌入到GemFire服务器的节点当中，当成一个单独的进程来运行。
前端应用或者其它应用，都可以访问Gemcached，因为Gemcached写了很多与Memcached相兼容的协议，或者说标准的Memcached操作，它都可以无缝接管。原来怎么写的，现在直接切过来就可以了，后端数据的缓存和集群管理就全不用管了。
至于GemFire这么做的原因，如果你要用Memcached也可以，但如果你的团队能力并不是很强，就会出现很多问题。比如秒杀系统经常会出现数据一致性问题，前端应用访问Memcached，当这个数据Memcached节点掉了，就会导致数据命中不到，紧接着会到数据库访问这个数据，虽然最后也可以成功，但需要付出双倍的精力，显然很不划算。
如果Memcached集群发生故障瘫痪，就会出现惊群效应，导致缓存和DB之间数据不一致，因为一旦出现故障或者命中率数据没有找到，就会到数据库找数据，如果是写操作的话，很可能会跟数据库之间的数据不一致。另外它也会破坏应用的业务逻辑，这也是不小的问题。
如果用Gemcached构建后端分布式集群的话，前面的应用都不用改，直接访问Gemcached就行。后端的数据保存都可以用GemFire整体的Cache Server来做，它也有分布式事务，分布式锁。后端不挂DB也没问题，挂DB也没问题。
因为其跟DB之间有一个数据环路，比如写入数据到DB的话，它会有异步事件监听器，如果写回到cache的话，会有loader，让数据在Cache和DB之间保持一致性。如果前端应用不再直接与DB交互，可以大大简化代码。
很多电商网站后台是有轻量级的，传统的MVC架构，迁移、改造或者升级，代码的调整会比较少。性能其实和Memcached差不多，对主副本的同步是自动的。
其实Memcached也可以双主或多主，如果采用同步模式，一个节点掉了，它可以瞬间切换到其它节点，因为它全是主节点，并且数据是实时同步的，一个节点在执行写操作时，它会向其它节点同步。这样可以有效保证数据的一致性。
除此之外，它还开发了一个异步队列——AsyncEventListener，你可以把数据缓存到Gemcached中，也可以开启异步队列，让异步队列把数据不断地写入MySQL。
由于GemFire的总体架构和AWS Dynamo的整体架构理念很相近，总结一下就是事件驱动，一切基于消息。淘宝也开始意识到这个问题，开发时很多应用模块看似都耦合在一起，性能就是有问题，就只好拆。从分布上来说阿里主要是研究怎么把整体架构变成面向异步的，面向消息的，数据驱动的架构。但GemFire本身是做金融交易系统的，所以它在很早的时候就考虑了这个问题，这个理念就不谋而合了。
另外一个比较重要的特性就是IO，流控和故障切换。在这些方面，GemFire做的比较好，如果原来使用的Memcached的话，只需要通过简单的配置，更改一下参数再调优就可以了。
多数据中心集群GemFire本身有一个Gateway，如果大家对GemFire有所了解的话应该知道，Gateway可以在各个数据中心之间进行数据同步。如果考虑容灾就不需要做了。如果是MySQL集群，跨数据中心或者数据同步的话，做异地容灾的延迟是比较大的，但GemFire完全不需要考虑这么多，如果整个数据中心，或者某个数据中心，某个组瘫痪或出现故障，可以平滑迁移到其他数据中心。
GemCache相比于Memcached的优势：
因为近几年Redis比较火，所以去年开始，GemFire就开始对Reids做集成，它也采用接管Reids客户端的方式，直接接管Reids操作，不需要对服务器进行操作，还是什么简便的。
至于二者的关系，也并不是替代关系。Redis可以作为GemFire的一个缓存，Redis在前，GemFire在后，最后可以做一个MySQL集群，这样做成一个大的并发访问，页面或评论。GemFire也可以作为Redis的数据缓存，如果要存内存模式，没有数据可以到GemFire取，GireFire把数据推给Redis。写redis的话，也有一些写好的版本(链接如上图所示)，可以在此基础上，稍作修改。
在GemFire内核中，新添加了一个GemFireRedis Server服务器进行读写操作，自己做一个原数据表，存入原数据。每个Redis数据类型(String和HyperLogLog都会被保存在单独的Region中，默认的Region类型为RegionShortcut#ARTITION。同时也支持分布式事务，Redis自己处理事务可以到GemFire里做。但有一个限制，只能在本地进行事务处理或开启事务处理持久化Region。此外，还做了隔离，默认情况下看不到Key键。同时GemFire也支持很多Redis命令，比如：
GemFire如何通过java堆栈保存Redis数据结构呢?GemFire 利用 java 程序实现了 类似Redis的数据结构。其整体架构和Memcached差不多，如果Memcached嵌到这个当中，也是通过端口。
GemFire日志里有很多挖掘，在具体应用上比如银行，它把很多交易数据写到日志中便于分析挖掘。同时GemFire自身的运行数据写到HDFS里，上端用Hadoop进行挖掘分析，GemFire集群出现任何问题都可以及时发现，数据本身出现的问题，也可以分析出来。不仅是IC层面，最终达到运营体系架构的支撑。如果需要使用前端的PV点击，也可以通过GemFire传数据。
虽然，GemFire可以做很多事情，但相对于传统数据库而言，仍然有很多做不了的事情。很多用户喜欢把GemFire当作数据库使用，这是不行的，但作为分布式事务处理还是有一定优势的。另外它也有自己的分布式文件系统，所以对于小文件，比如KB级或几兆的直接存到GemFire自己的分布式文件系统是完全没问题的，可以当成云存储。
GemFire也可谓是命运多舛，一开始做了三十多年的大型衍生品交易系统，后来基于交易系统做了C/C++分布式处理系统，主要对交易进行处理，九十年代初，java比较火，GemFire就开始把这套系统往java上转。被收购之后在非金融的领域推广并不是很顺利，虽然其既不是中间件，也不是数据库，但既可以当中间件用也可以当数据库用，也可以当缓存用、当并行计算平台用，当计算引擎用，也当相对队列用，有很多的CEP处理。也有很多的技术点，我没有提及。
今天的分享到此结束，谢谢大家!
