【分布式协调器】Paxos的工程实现-cocklebur简介（二）

Cocklebur集群的工做原理

　　在集群正常工做时，整个集群只会有一个Leader，其余都是Follower。Client能够注册到某个Follower，固然也能够注册到Leader，为了减轻Leader压力，通常要选择注册到Follower。读操做直接向Follower请求数据，而写数据则直接向Leader提交请求（在Client注册到Follower时已经得知当前的Leader的地址信息并缓存在Client本地，若是Client提交写操做时发现目标主机已经不是Leader则将从新向Follower询问Leader地址）。这种状态下的集群，Leader和Follower的状态（维护的数据）知足最终一致性，而Leader拥有最新数据。

 

图1、Cocklebur对外服务示意图

　　注意，因为最终一致性可能会致使Follower的数据更新延迟，对于整个集群来讲，读数据时必然是延迟的，可是写数据时Leader是必经之路，Leader能够保证数据永远都是最新的。因此写当一个Client读到延迟信息时发出特定目的写操做时可能会失败，但最终集群的数据必定不会发生错误。

　　这就好像是你明明看到一个空的座位（读取数据），当你要去坐的时候发现已经有人作了（尝试要写数据时，由于坐位子至关因而改变了座位的状态）。这实际上对于座位来讲并无什么不合适的，由于谁先来的就应该是谁坐，而不是谁先看到就谁坐，由于看到并不算改变了它的状态。因此经过这个例子，你能够想一想分布式锁的场景。

Cocklebur主要功能模块

而从cocklebur整体设计来看，其主要功能模块以下图所示：

 

图2、Cocklebur基础功能模块

　　除了Thrift RPC序列化框架是第三方库以外，其余cocklebur不依赖其余库。而负责通讯这部分属于十分基础的技术，故不详细介绍。另外你们能够看到，cocklebur并无实现ACL（访问控制列表，访问权限相关），其实ACL能够在数据操做模块完成，本人时间有限因此就没有实现ACL。以后的博客也主要围绕上面四块展开，介绍完功能模块设计，就开始介绍一些主要的控制流程。

　　类Paxos选举算法：目前Paxos的工程实现都不是Paxos原版，都是在其基础上进行了化简和改变。这样有助于节约带宽、化简设计等等。该部分主要功能就是负责集群启动选举Leader，以及当集群不构成集群对外服务条件时进行从新选举。最终目的就是尽量让集群最快的对外服务。那么什么是集群对外服务条件呢？那就是当前有Leader且Leader与其领导的Followers可以组成一个多数派（超过集群节点半数）。

　　DataTree目录结构：内存版的文件系统或者指的是一个数据结构。分布式锁以及名字空间、共享文件就是经过这样的数据结构去实现的。其实这个数据结构并非很难理解，由于Tree这种结构很擅长去组织层次化的东西，正如xml，json，文件目录那样应用普遍。

　　日志快照系统：用于为每一个节点容灾考虑设计，事实上光写日志就能够保证容灾，快照是为了更快的去恢复当前内存状态，就像你玩游戏的检查点（check point），下次开机玩就不用从第一关开始了。

　　数据操做的Client/Server：一方面集群要对外服务，提供Client和Server。另外一方面，集群节点之间内部同步数据时也须要使用这些组件。另外注册-通知机制（观察者模式）也是这部分实现的。