【自己动手实现一个分布式协调器之三】Paxos的工程实现-cocklebur简介(二)

Cocklebur集群的工作原理

  在集群正常工作时,整个集群只会有一个Leader,其他都是FollowerClient可以注册到某个Follower,当然也可以注册到Leader,为了减轻Leader压力,一般要选择注册到Follower。读操作直接向Follower请求数据,而写数据则直接向Leader提交请求(在Client注册到Follower时已经得知当前的Leader的地址信息并缓存在Client本地,如果Client提交写操作时发现目标主机已经不是Leader则将重新向Follower询问Leader地址)。这种状态下的集群,LeaderFollower的状态(维护的数据)满足最终一致性,而Leader拥有最新数据。

 【自己动手实现一个分布式协调器之三】Paxos的工程实现-cocklebur简介(二)

图一、Cocklebur对外服务示意图

  注意,由于最终一致性可能会导致Follower的数据更新延迟,对于整个集群来说,读数据时必然是延迟的,但是写数据时Leader是必经之路,Leader可以保证数据永远都是最新的。所以写当一个Client读到延迟信息时发出特定目的写操作时可能会失败,但最终集群的数据一定不会发生错误。

  这就好像是你明明看到一个空的座位(读取数据),当你要去坐的时候发现已经有人做了(尝试要写数据时,因为坐位子相当于是改变了座位的状态)。这实际上对于座位来说并没有什么不合适的,因为谁先来的就应该是谁坐,而不是谁先看到就谁坐,因为看到并不算改变了它的状态。所以通过这个例子,你可以想想分布式锁的场景。

Cocklebur主要功能模块

而从cocklebur总体设计来看,其主要功能模块如下图所示:

 【自己动手实现一个分布式协调器之三】Paxos的工程实现-cocklebur简介(二)

图二、Cocklebur基础功能模块

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

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

  DataTree目录结构内存版的文件系统或者指的是一个数据结构。分布式锁以及名字空间、共享文件就是通过这样的数据结构去实现的。其实这个数据结构并不是很难理解,因为Tree这种结构很擅长去组织层次化的东西,正如xmljson,文件目录那样应用广泛。

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

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

 

你可能感兴趣的:(分布式)