zookeeper

分布式服务框架 Zookeeper

	概念：为分布式应用系统提供一致性服务，是一个典型的分布式数据一致性解决方案。

	原理：通过管理(存储/读取)数据节点和监听数据节点的状态变化来实现基于数据的集群管理。

	特性：
		高性能：Zookeeper将所有的数据都保存在内存中，故读取数据很快。
		高可用：支持以集群部署。

	角色：
		Zookeeper集群：
			概念：Zookeeper集群中的server由leader和learner组成。

			leader(领导者)
				接收客户端的请求并将结果返回给客户端。
				接收learner的请求，并判断消息的类型：
					PING消息 		learner的心跳信息
					REQUEST消息 		follower发送的提议信息，包括写请求及同步请求
					ACK消息 			follower对提议的回复，超过半数的follower通过，则commit该提议
					REVALIDATE消息 	用来延长SESSION的超时时间

				负责投票的发起和决议

				说明：leader写入的数据通过paoxs算法，将所有数据同步。

			learner(学习者)
				follower(跟随者)	
					接收客户端的请求并将结果返回给客户端，注意：写请求将会转发给leader来处理。
					在选举过程中参与投票。
				observer(观察者)	
					接收客户端的请求并将结果返回给客户端，注意：写请求将会转发给leader来处理。
					在选举过程中不参与投票，只同步leader的状态。
					说明：
						1>Zookeeper在3.3.0版本引入了observer角色，引入observer的目的是为了扩展系统，提高读取速度。
						2>投票阶段，Zookeeper不能提供服务，投票阶段的延迟会随着参与投票server数量的增加而变大。
						3>引入observer后，只有少部分server会参与投票，大大减少了参与投票server的数量，从而降低了投票阶段的延迟。

			说明：集群间通过Zab协议(Zookeeper Atomic Broadcast)来保持数据的一致性。

		客户端：
			客户端向server发起请求。



	选举
		选举算法：当多数(超过一半)Server写成功，则任务数据写成功。
		server的数量一般为奇数。eg：3台server时，最多允许1个Server挂掉；4台server时，也是最多允许1个Server挂掉，即3台server和4台server的高可用性是一样的。
		

	顺序一致性
		概念：
			ZooKeeper会给客户端的每个写请求分配一个全局唯一的递增编号zxid(高32位是时间戳，低32位是递增计数)，这个编号反应了所有事务操作的先后顺序。
			由leader和follower来保证同一个Follower请求的顺序性。
		举例：
			followerA依次提交两个写请求request1、request2，
			followerB不能立即看到followerA请求的结果(zk不是强一致性),followerB和leader同步后，followerB一定是先看到request1的结果，后看到request2到结果，这两个请求的顺序不会乱序，即顺序一致性。
			

	会话(session)
		概念：Zookeeper的客户端和服务器通过长连接的方式来进行通信，每个客户端和服务器通过心跳来保持连接状态，这个连接状态称为session。
		说明：
			客户端启动时首先会与(某个)服务器建立一个TCP连接，通过这个连接客户端可以向服务器发送请求并接受响应，也可以接收来自服务器的Watch事件的通知。
			session可以设置超时时间：客户端(由于网络故障/服务器压力太大/客户端主动断掉等)连接断开后，如果客户端可以在超时时间内重新连接到服务器，那么之前创建的会话仍然有效。


	数据模型
		zookeeper提供基于类似于文件系统的目录节点树的方式来存储数据。
		ZooKeeper将所有数据存储在内存中。
		数据节点znode：
			znode是数据模型中的数据单元，每个znode都有一个唯一的路径标识。
			znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性。
			znode是有版本的，每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，那么查询这个路径下的数据需带上版本。
			znode在同一层级上可以做到按序排列，序列号由父节点维护。有序节点的路径：原路径名+序列号。
			znode有两种类型
				永久节点(persistent)：可以包含数据和子节点，不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除。
					PERSISTENT(永久节点)
					PERSISTENT_SEQUENTIAL(永久有序节点)

				临时节点(ephemeral)：没有子节点，客户端会话结束时zookeeper会将该短暂节点删除。
					EPHEMERAL(临时节点)
					EPHEMERAL_SEQUENTIAL(临时有序节点)


	Watcher
		客户端可以在节点上设置监视器(Watcher)，当监听的事件发生时，客户端会收到服务端的通知，并做相应的处理。


	ACL
		ZooKeeper采用ACL(AccessControlLists)策略来进行权限控制，类似于UNIX文件系统的权限控制，共定义了5种权限：
			create 	创建子节点
			read	获取节点数据
			write	更新节点数据
			delete 	删除子节点
			admin	设置节点的ACL权限。


	Zookeeper应用场景：

		注册中心：
			服务的消费者在进行服务调用的时候先到ZooKeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

		分布式锁：
			原理：多个客户端同时在Zookeeper上创建相同znode，只会有一个创建成功，创建成功的客户端得到锁，其他客户端等待。

		分布式队列:
			场景：一个job由多个task组成，只有所有task完成后(task由不同的机器来执行)，job才完成。
			实现：为job创建一个/job目录，每个机器在执行完对应的task后，创建一个临时znode，一旦/job目录下临时节点的数目达到task总数，则表示job运行完成。

		配置管理：
			将配置信息写入Zookeeper的一个znode上，集群中各个节点都去监听这个znode，一旦znode中的数据被修改，zookeeper将通知各个节点，各个节点收到通知后对配置进行更新处理。

		分布式调度：
			举例：
				agent：
					创建临时节点zkpath/agents/agentId，用于表明agent已上线。
					创建持久节点zkpath/tasks/agentId，用于存储需要执行的任务数据。
					监听持久节点的子节点，当子节点(发生变化)产生事件时，根据事件的类型来做出相应的处理：
						当监听到子节点新增事件时，获取任务数据，执行任务。任务完成后将zkpath/tasks/agentId/taskId节点删除。
						当监听到子节点删除事件时(这里的删除事件是由agent自己发出的)，通过http的形式通知server任务已结束。

				server：
					接收到任务(mq消息)后：
					获取临时节点zkpath/agents的子节点，判断是否存在可执行的agent，若不存在则报警。
					根据特定策略(随机等)得到执行该任务的agent：创建持久节点zkpath/tasks/agentId/taskId，用于存储指定的任务数据。此时，agent会监听到这个动作，并做出响应的处理。
						
			注意：agent和server在zookeeper集群中的扮演的角色都是client(客户端)。