zookeeper系列2

　　分布式学习之zookeeper-2几个基本概念会话
　　客户端与服务端的一次会话连接，本质是TCP长连接，通过会话可以进行心跳检测和数据传输； znode持久节点：持久节点只能用delete来删除，通常用来保存应用的持久化数据，比如主从模式下的任务分派情况，这种数据不应该由于主节点的崩溃而丢失。 临时节点:顾名思义，除了客户端主动删除该节点时会消失外，创建该znode的客户端断开连接时该节点也会消失，因此它常用来检测会话的有效性，例如主从模式下的主节点注册一个znode，当该主节点崩溃或断开时，该znode会立即消失，于是应用可以检测到该故障并重新选举主节点，这种用法极为常见比如kafka。另外， 临时节点不允许有子节点 。 有序节点：znode还可以被设置为有序节点，当这样的节点被创建时，一个会自动递增的序号会加到路径之后，比如客户端创建一个有序znode并指定路径为/tasks/task，则第一个创建的节点是/tasks/task-0000000001，该节点消亡后再创建这样的节点会产生/tasks/task-0000000002，以此类推。有序znode提供了创建具有唯一命名的znode的方式。
　　这几种类型互相结合后就会产生znode的四种类型：持久的，临时的，持久有序的，临时有序的。
　　znode有如下属性
　　属性名称
　　含义
　　cZxid
　　创建节点时的事务ID
　　ctime
　　创建节点时的时间
　　mZxid
　　最后修改节点时的事务ID
　　mtime
　　最后修改节点时的时间
　　pZxid
　　表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID
　　cversion
　　子节点版本号，子节点每次修改版本号加1
　　dataversion
　　数据版本号，数据每次修改该版本号加1
　　aclversion
　　权限版本号，权限每次修改该版本号加1
　　dataLength
　　该节点的数据长度
　　numChildren
　　该节点拥有子节点的数量
　　ephemeralOwner
　　如果此节点为临时节点，那么它的值为这个节点拥有者的会话ID；否则，它的值为0
　　dataLength
　　节点数据域的长度
　　numChildren
　　节点拥有的子节点个数
　　Tip: 节点大小一般最大数据量为1M watch
　　客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
　　访问ZooKeeper的基本方式是使用API，很多场景我们需要访问一个znode，如果使用轮询的方式，不仅不能实时知晓变更（取决于轮询间隔），更恶劣的是会大大增加ZooKeeper的负载。比较好的方式是，对该znode设置一个监视（watch），当某些事件发生时触发一个通知（notification）。注意监视点是一次性的，如果通知被触发后还需要继续监视该znode，则需要设置一个新的watch。
　　Znode可以设置两类watch，一个是Data Watches（该znode的数据变更导致触发watch事件），另一个是Child Watches（该znode的孩子节点发生变更导致触发watch事件）
　　Java API
　　Data Watches
　　Child Watches
　　getData
　　设置
　　exists
　　设置
　　setData
　　触发
　　create
　　触发
　　getChildren
　　设置
　　create某znode的子节点
　　触发
　　delete
　　触发
　　触发、如删除的znode有父节点，其父节点上也触发 集群中的几个角色leaderLeader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO followerFollower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交 observer如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。 ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。 Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的『过半写成功』策略，因此 Observer可以在不影响写性能的情况下提升集群的读性能。
　　tip: ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。 zk的选举过程
　　Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
　　Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。
　　当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
　　各节点状态:
　　LOOKING：当前Server不知道leader是谁，正在搜寻 LEADING：当前Server即为选举出来的leader FOLLOWING：leader已经选举出来，当前Server与之同步
　　集群的master选举分为 服务器初始化启动 master挂掉需要重新选举
　　选举是半数通过即认为通过。
　　集群初始化阶段 ，当有一台服务器ZK1启动时，其单独无法进行和完成Leader选举，当第二台服务器ZK2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。 每个Server发出一个投票。由于是初始情况，ZK1和ZK2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时ZK1的投票为(1, 0)，ZK2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行比较，规则如下 优先检查ZXID。ZXID比较大的服务器优先作为Leader。　　　　如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。 　　对于ZK1而言，它的投票是(1, 0)，接收ZK2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时ZK2的myid最大，于是ZK2胜。ZK1更新自己的投票为(2, 0)，并将投票重新发送给ZK2。 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于ZK1、ZK2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出ZK2作为Leader。 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。当新的Zookeeper节点ZK3启动时，发现已经有Leader了，不再选举，直接将直接的状态从LOOKING改为FOLLOWING。
　　在Zookeeper运行期间，如果 Leader节点挂 了，那么整个Zookeeper集群将 暂停对外服务 ，进入新一轮Leader选举。 变更状态。Leader挂后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定ZK1的ZXID为124，ZK3的ZXID为123；在第一轮投票中，ZK1和ZK3都会投自己，产生投票(1, 124)，(3, 123)，然后各自将投票发送给集群中所有机器。 接收来自各个服务器的投票。与启动时过程相同。 处理投票。与启动时过程相同，由于ZK1事务ID大，ZK1将会成为Leader。 统计投票。与启动时过程相同。 改变服务器的状态。与启动时过程相同。