| Apache顶级项目介绍之8，我们重新恢复Apache顶级项目系列，较之前介绍系列，我们本文直入代码分析，原因有二，Geode即上文我们分析的Gemfire的开源版本，其二被逼无奈，阅读源码查找问题。
1. Geode
2016年11月21日，Apache 软件基金会（ASF）宣布 Apache? Geode? 已从 Apache
孵化器毕业成为顶级项目（TLP），表明该项目的社区和产品已根据 ASF 的精英流程和原则得到良好管理。
Apache Geode 是一个数据管理平台，提供实时的、一致的、贯穿整个云架构地访问数据关键型应用，最初由
GemStone Systems 公司开发，商标为 GemFire。 此项技术初期被广泛应用在金融领域，用于华尔街交易平台，作为事务性、
低延时的数据引擎。2015年4月将代码提交给 Apache 孵化器作为孵化项目。目前 Apache Geode
有超过600家大中型企业级用户, 主要是必须满足低延时和24x7 高可靠要求的，高可扩展的关键业务应用系统。
2. 适用场景
可以参考上文，分布式缓存利器-Gemfire.
4个主要使用场景：
高可用性的分布式缓存
网格计算
事件通知和处理（CEP类似）
交易处理（Transaction），采用最终一致性
Geode 池化了服务器上的内存, CPU, 网络资源, 和本地磁盘，跨多个进程来管理应用对象和行为.
它使用了动态数据复制和分区技术来实现高可用, 高性能, 高可扩展性, 和容错. 另外, 对于一个分布式数据容器,
Apache Geode 是一个基于内存的数据管理系统, 提供了可靠的异步事件通知和可靠的消息投递.
3. 数据结构源码
如上文所说，系统目前遇到一个分布式系统异常复杂之难题，难到不遍历源码无法解开谜题的地步。注意，笔者写此文时，此难题尚无答案，我们希望当此文发布时，已有解药。
另外，强烈建议看官先自行了解Gemfire功能以及部分原理，否则此文较为吃力。
3.1 Region
进入正题，先来看一下核心类Region。
Region继承Java的ConcurrentMap，实现了分布式K,V的HashMap，并提供了高阶的事务，Persistence，分区等分布式功能。
接口继承Map的get, put无须多说，看几个比较重要的。
Geode的Region可以像树形一样，形成一种Hierarchy结构嵌套，使用”/”来分隔多个子Region.所以有向上获取父亲，自然也有向下导航获取子女：getSubregion(String
path)
RegionDistributedLock
第一个分布式锁，全局Region。注释写很到位，其中提到当region创建时会自动开启全局region锁，所有对region级别的操作，如invalidateRegion,
destroyRegion也可能会自动用到region级别锁，这个么可以理解，毕竟是重量级操作。
getDistributedLock（key）
提供了更细粒度的region级别分布式锁控制。
然而，除非必要，所有分布式操作不建议用如此之重的锁，否则后患无穷。
public void writeToDisk();
当然，支持持久化到磁盘，分布式的一种表现形式，相对于普通的HashMap。
public void becomeLockGrantor();
不赘述，如注释所描述，LockService的担保，前提当前region必须是Global类型，有点类似对于分布式全局变量加锁，所以每当调用此方法，线程将阻塞直到担保被转移到当前member。
超级重量级方法，请自保。注释强调了，相互调用可能造成死锁，说的比较委婉，back and force。
public void registerInterest(K key);
后续很多分布式，多个member交互的入口之一。
注释提到用于向CacheServer提交注册一个感兴趣的key，后续还有按照正则表达式注册，或者注册所有key。其注册目的是用于被通知，类似ems
queue的subscription功能，或者回调通知。
public List getInterestList();
返回当前region已经注册的所有感兴趣key。
对了，每个类代码小于500行都是骗人的，随便看看这些开源代码，少则1000，多则6-7千行代码。
3.2 AbstractRegion
AbstractRegion抽象类，主要封装实现了关于RegionAttributes, AttributesMutator,
and some no-brainer method implementations。
其中，主要cache操作的读写则由上面loader与writer代理实现。Usually there
will be only one CacheWriter in the distributed system.所以，通常整个分布式系统只有一个cache
writer，其它特殊情况暂时不提。
截获entry更新事件，其中entryEvent包含了整个操作的信息，如KeyInfo, EventID,
newValue, oldValue, Operation, originated member等。BTW,
这个看起来普通的EntryEvent类也有2856行，此处省略无数。。。
protected Set asyncEventQueueIds;
隐隐觉得，其分布式的消息事件处理会放到queue中，这里用了set结构，我们继续看下去。
protected booleanenableSubscriptionConflation;
这个参数对于高频写region非常有用，主要是同一个key高速写，类似实时报价。这个参数效果类似于Leaky
Bucke。
漏桶算法(Leaky Bucket)是网络世界中流量整形（Traffic Shaping）或速率限制（Rate
Limiting）时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。
3.3 Regions UML
当我们越加深入，发现代码越来越复杂，很多类少则几千，多则上万行，类也有上千万个，对于大型开源项目，还是来一张类图吧，掌握整体宏观很重要。
可以看到LocalRegion继承自AbstractRegion，最重要的是内部封装了Region的数据结构。
了解HashMap内部数据结构的朋友应该知道，其内部为数组+链表组合的二维空间；同理，Geode的Region内部数据结构则由RegionMap来抽象，持有真正的数据，而究其内部则是内置了一个ConcurrentHashMap，想想让我们来设计的话也大概如此吧。
3.4 AbstractRegionMap
可以看到里面内置一个CustomEntryConcurrentHashMap map；应该是这个map,
这是什么神器？
如果你看到了Doug Lea的大名，不要惊奇，难道Doug也为Gemfire/Geode操刀？非也。
Gemfire/Geode当年直接copy Doug老人家的ConcurrentHashMap, 你可以去比较一下源码，当然，GemStone也进行了一些定制化，如读锁等。
了解完其真实内部存储数据结构后，心中略有一二，而然这也是预期之中，我们继续看如何实现分布式的精髓。
3.5 DistributedRegion
我们还是先上UML图吧。
DistributinRegion代表了分布式的ReplicatedRegion, 而其中则是靠CacheDistributionAdvisor来帮忙跟踪保持数据同步的。
3.6 Partitioned Regions
Partitioned Region为PatitionedRegion的实例化，内部则基于key的hash
code来检测定位Bucket。
PartitionedRegion，Geode中的核心分布式结构。通过hash算法（可以自定义）来把key映射到相应的bucket从而达到分布式存储，并提供routing消息到相应的bucket。
PartionedRegion中的PartitionedRegionDataStore则实际负责分布式管理bucket，以及存储。
PRHARedundancyProvider
类如其名:
主要提供针对Reduancy Copy的管理，包括：
bucket创建，以及node的管理。
当创建并配bucket的时候，其内部创建出BucketRegion的实例, 来看一下BucketRegion中经典的virtualPut:
注释很好，
如果当前是Primary, 则op locally, 之后分发操作op到secondaries及bridge
server，同时cache listerner同步其结果；
反之，则首先op locally，之后更新local bridge server， gateway
来个序列图吧： 
4. 分布式管理Client + Server
Geode的分布式消息通信分为主要两大类，一类是Peer to Peer，主要使用了InternalDistributedMember。
4.1 Peer to Peer 消息机制
InternalDistributedMember封装了分布式member的信息，当需要发送p2p消息时，需要用该对象表明目标。
DM提供了获取所有当前cluster中的peers列表，并通过listerners来获取动态信息，而其底层则是通过DistributionAdvisor实现，统一的模式，所以真正筹谋画册的都是幕僚。DM主要封装了相关的网络通信信息，包含netMember,
dcPort（direct channel port）, vmPid（member machine’s
process id）等，当然实现特定内部序列化接口（DataSerializableFixedID）是必不可少的。
而消息则是DistributionMessage封装，包含了上述InternalDistributedMember信息的sender与destination,以及多个recipients的InternalDistrbutedMember[]数组，还有万恶的用于direct
ack的ReplySender等。
整个消息通信过程大概是先创建DistributionMessage, 设定recipient（可以多个）,之后调用(DistrbutManager
DM) DM.putOutgoing(message)。
如果需要不但发送消息，而且还要确认消息回复response，则要使用著名的ReplyProcessor21,
如果你看到过Gemfire/Geode的ThreadDump, 你就明白我说什么了。
还是来个序列图吧，一图抵千言。
最后在远端则是通用的处理：
最后，远端返回replyMessage，并使用相同的unique id，sender收到消息后，找到ReplyProcessor，并wakeup
thread waitForRepliesUninterrupibly()。
4.2 Client / Server 通信
Client/Server通信机制与p2p略有不同。Server端封装了command，引入智囊团BridgeServerImpl,
AcceptorImpl, Client端则封装了AbstractOp。
Server: 
Acceptorimpl主要监听socket端口，接受客户端的链接。而其中又通过区分max-connections,
max-threads而分为使用dedicated thread还是selector模式的NIO处理。
Client:
客户端则使用PoolImpl来管理连接connections，client region则持有serverRegionProxy以便实现调用。
值得注意的是，客户端可以通过subscribe events于特定／多个region或者通过内置的continuous
queries，这样当服务器端有数据更新则client端可以受到更新的通知event。
5. 总结
好吧，时间，篇幅受限，我们先到此。我们把核心的数据结构以及分布式通信的核心类大概介绍了一下，详细细节还需要仔细阅读源码。 |
