Cocklebur集群的工作原理
在集群正常工作时，整个集群只会有一个Leader，其他都是Follower。Client可以注册到某个Follower，当然也可以注册到Leader，为了减轻Leader压力，一般要选择注册到Follower。读操作直接向Follower请求数据，而写数据则直接向Leader提交请求（在Client注册到Follower时已经得知当前的Leader的地址信息并缓存在Client本地，如果Client提交写操作时发现目标主机已经不是Leader则将重新向Follower询问Leader地址）。这种状态下的集群，Leader和Follower的状态（维护的数据）满足最终一致性，而Leader拥有最新数据。
图一、Cocklebur对外服务示意图
注意，由于最终一致性可能会导致Follower的数据更新延迟，对于整个集群来说，读数据时必然是延迟的，但是写数据时Leader是必经之路，Leader可以保证数据永远都是最新的。所以写当一个Client读到延迟信息时发出特定目的写操作时可能会失败，但最终集群的数据一定不会发生错误。
这就好像是你明明看到一个空的座位（读取数据），当你要去坐的时候发现已经有人做了（尝试要写数据时，因为坐位子相当于是改变了座位的状态）。这实际上对于座位来说并没有什么不合适的，因为谁先来的就应该是谁坐，而不是谁先看到就谁坐，因为看到并不算改变了它的状态。所以通过这个例子，你可以想想分布式锁的场景。
Cocklebur主要功能模块
而从cocklebur总体设计来看，其主要功能模块如下图所示：
图二、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。另一方面，集群节点之间内部同步数据时也需要使用这些组件。另外注册-通知机制（观察者模式）也是这部分实现的。