Zookeeper理论知识

前言
：开发和维护开源服务器

概念

：Apache ZooKeeper致力于开发和维护实现高度可靠的分布式协调的开源服务器。

	目的：开发和维护开源服务器		
	干什么：做分布式协调
	特点：高度的可靠性

诞生过程

：ZooKeeper诞生于Yahoo，后转入Apache孵化，最终孵化成Apache的顶级项目，是Hadoop和Hbase的重要组件。

作用

：ZooKeeper是开源的分布式的协调服务框架，是Apache Hadoop的子件，适用于绝大部分分布式集群的管理（ZooKeeper是一种集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用）

分布式引发的问题

	死锁：至少有一个线程占用了资源，但是不占用CPU
	活锁：所有线程都没有把持资源，但是线程却是在不断地调度占用CPU
	需要引入一个管理节点
	为了防止入口的单点问题，需要引入管理节点集群	
	需要确定一套选举算法
	主节点和从节点之间要保持数据的一致

特点

	本身是一个树状结构 --- Znode树
	每一个节点称之为znode节点
	根节点是 /
	zookeeper 的所有操作都必须以根节点为基准进行计算 /
	每一个znode节点都必须存储数据
	任意一个持久节点都可以有子节点
	任意一个节点的路径都是唯一的
	Znode树是维系在内存中 --- 目的是为了快速查询
	Zookeeper 不适合存储海量数据
	（维系在内存中，如果存储大量数据会消耗内存，
			不是一个存储框架而是一个服务协调框架）
	ZooKeeper会为每一次事务（除了读取以外的所有操作都是事务）
			分配一个全局的事务id ---Zid

节点类型

  	持久节点
  	临时节点（在客户端退出之后就自动删除）
  	持久顺序节点
  	临时顺序节点

命令

	create /子节点名字 "文本信息"：在根节点下创建子节点并且为其赋值内容
	set /子节点名字 "新的文本信息" ：更新子节点的内容为新的文本信息
	get /子节点名字：获取子节点的信息
	ls /：查看根节点下所有的子节点
	delete /子节点名称：删除子节点（要求这个节点中没有子节点）
	rmr /子节点名称：删除子节点（报括他的子节点）
	quit  ：退出客户端
	create -e /子节点名称：在根目录下创建临时节点
	create -s /子节点名称：在根目录下创建持久顺序节点
	create -e -s /子节点名称 ：在根目录下创建临时顺序节点

节点信息

	cZxid：全局分配的创建的事务id
	ctime：创建时间	
	mZxid：修改的事务id（记录自己本身修改）
	mtime：修改时间
	pZxid：子节点的变化的事务id（记录子节点的创建和删除）
	cversion：记录字节点变化次数
	dataVersion：数据版本
	aclVersion：记录当前节点的acl的变化次数
	ephemeralOwner：如果当前节点不是临时节点，那么这个属性的值为0
			（如果是临时节点，这个属性的值记录的是当前临时节点的session id）
	dataLength：数据长度（实际上是字节个数）
	numChildren 子节点个数	

节点状态

    Looking：选举状态
    follower：追随者
    leader：领导者
    observe：观察者

选举机制

	第一阶段：数据恢复阶段（会从数据目录中（dataDir）中恢复数据）
	第二阶段：选举阶段
	 1.所有的节点都会推荐自己当leader并且发动自己的选举信息（
						 最大事务id（pZxid） 编号（myid），逻辑时钟值）
	 2.选举原则：先比较最大事务id，谁的事务id大谁就胜出，如果
	                     最大事务id一样，则比较myid，谁的myid大谁就胜出
	 3. 选举出的leader的胜出要满足过半性（即要比至少一般的节点大）
	 4. 如果在集群中新加入一个节点，节点的事务id比leader的事务id大
	 					（新的id不会成为leader，只要选定了一个leader，
	 					  那么后续节点的事务id和myid无论是多少，
	 					  一律都是follower）
	 5.如果leader宕机，集群中会自动选举一个新的leader；
	 6.如果超过一般的服务器宕机，那么此时Zookeeper不再对外提供服务（过半性）
		
		{	01 02 03 --》02成为leader
		 	01 03 02 --》03成为leader	}

ZAB协议

	Zookeeper的投票是ZAB协议，ZAB是2PC协议的基础上来进行的延伸
	2PC:将节点分为了协调者和参与者，当来一个请求的时候，协调者是
	    将请求者分发给每一个参与者，如果所有的参与者决定执行这个请
	    求，那么协调者就真正提交操作，有参与者执行，参与者在执行完
	    成之后返回Ack表示执行成功，如果协调者将请求分发给每一个参与
	    者之后，有一个或者多个参与者不同意执行或者是没有返回消息，那
	    么将这个操作回滚，不执行（一票否决）
	    
	    在Zookeeper中，接收一个请求之后，leader会将请求分发给每一个
	    节点，由所有的节点投票确定是否执行这个请求（如果有一半的节点同意
	    执行这个请求，那么这个时候leader才会决定这个操作）

过半性

	1.选举leader的要满足过半性
	2.请求操作也要满足过半性
	3.过半集群才能对外提供服务，防止脑裂，一般将集群点设置为奇数
					（脑裂：集群中产生2个及以上的leader）

观察者

	执行操作，但是不参与选举和投票
	（21个节点 （14个观察者，6个follower，1个leader）
	    12个观察者宕机，依然对外提供服务
	    4个follower宕机，不对外提供服务
	    观察者不参与投票，所以就不影响集群的运行）