JAVA复习笔记分布式篇：zookeeper
前言：终于到分布式篇，前面把JAVA的一些核心知识复习了一遍，也是一个JAVA程序员最基本要掌握的知识点，接下来分布式的知识点算是互联网行业的JAVA程序员必备的技能；
概念:ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是谷歌的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等
关键词：分布式，一致性服务
讲得通俗一点，zookeeper的诞生就是为了解决分布式一致性的问题。
什么是分布式一致性？
分布式：分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。
一致性：指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的 ；
PS：通俗一点以前一台服务器支撑一个系统的模式升级为多台服务器（多个容器）去支撑一个系统，这样这个系统的并发、容灾等各方面的能力将得到大大提升（传统的ngix和集群也能做到），分布式和集群最大的一个区别是分布式的节点都是不同业务（比如账号 系统，订单系统，物流系统，商品系统各自部署在不同服务器上）这样做的好处是可以根据不同模块的特性合理地分配资源（比如账号系统访问量很大，需要部署3-5台机器，而物流系统的访问量较小，只需要部署1-2台服务器即可），一致性就是虽然账号系统部署 了3台服务器，对于client而言是透明的（订单系统调用账号系统的服务，不用知道调用的哪台服务器上的系统， 结果每次都能得到幂等），那么如何保证每次都能得到这个幂等结果？也就是zookeeper的要解决的问题
基本架构图
角色：
领导者（leader）： Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求；
追随者（follower）：除了响应本服务器上的读请求外（exists，getData，getChildren等只读请求），follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交
观察者（observer）：Observer和Follower比较相似，只有一些小区别：首先observer不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。
整个zookeeper集群只有这3种角色，可以看到leader只有一个，所有对数据变更的请求都需要有leader去调度（leader会向所有节点发送原子广播，收到一半以上的节点都同意的消息后才真正提交这个事务），所以leader这个节点相当重要，那如何确立这个 learder 呢？
答案是选举，zookeeper采用选举的方式确立leader（触发选举的场景分为2种，一种是服务器初始化启动时候，还有一种是服务器运行期间无法和Leader保持连接）
讲解选举过程前先需要了解几个名词
electionEpoch（时钟）：每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次
peerEpoch：每次leader选举完成之后，都会选举出一个新的peerEpoch，用来标记事务请求所属的轮次
zxid：事务请求的唯一标记，由leader服务器负责进行分配。由2部分构成，高32位是上述的peerEpoch，低32位是请求的计数，从0开始。所以由zxid我们就可以知道该请求是哪个轮次的，并且是该轮次的第几个请求。
lastProcessedZxid：最后一次commit的事务请求的zxid
选举过程：
整个选举流程如上图
每个节点开始第一轮选举，逻辑时钟（当前投票轮数）+1，投票给自己节点（myid,zxid），广播给所有节点，并且开始接收其他节点发来的投票信息（第一轮的投票每个节点都会投给自己），每接收到一个其他节点的投票就先判断对方节点是否满足投票条件（只有PARTICIPANT类型的节点并且处于Looking才能参与选举），判断对方的Epoch和自己节点的逻辑时钟大小
1：如果对方的Epoch小与自己节点的逻辑时钟，那么就舍弃对方的这次投票（认为它是过期无效的），判断当前节点的状态节点是否满足投票条件，如果满足则继续接收其他节点的投票
2：如果对方的Epoch等于自己节点的逻辑时钟，则判断zxid大小
2.1如果自己节点所投票的zxid小于对方的zxid，则需要更新自己的投票为对方的投票，并广播所有节点，把对方的票放到自己的投票箱
2.2如果自己节点所投票的xid等于对方的zxid，则需要判断节点id大小（对方节点id较大，执行2.1的逻辑，反之执行2.3）
2.3如果自己节点所投票的zxid大于对方的zxid，把对方的票放到自己的投票箱
3：如果对方的Epoch大于自己节点的逻辑时钟，更新自己的逻辑时钟为对方的Epoch， 清空自己的投票箱（认为之前的投票都是无效的）执行上面这一步(比较zxid大小)
4：每次投完票都会统计自己投票箱的情况，如果超过一半的票数投了相同的节点，就可以认为那个节点是leader节点。不过还需要再确认一遍（那么当前线程将被阻塞等待一段时间(这个时间在finalizeWait定义)）从队列中继续接收，如果没有更优选票，投票就能结束(判断投票的节点id和当前服务器的Id一致，则认为是leader节点,如果节点类型是PARTICIPANT节点Following节点，反之Observing节点)
如果接收到的节点状不是Looking(Following,Observing,leading):
Observing:放弃该投票（Observer不参与投票）
Following或leading：对比当前的逻辑时钟与对方的逻辑时钟大小
a) 如果逻辑时钟相同,将该数据保存到recvset,如果所接收服务器宣称自己是leader,那么将判断是不是有半数以上的服务器选举它,如果是则设置选举状态退出选举过程
b) 否则这是一条与当前逻辑时钟不符合的消息,那么说明在另一个选举过程中已经有了选举结果,于是将该选举结果加入到outofelection集合中,再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟,设置选举状态,退出选举过程.
可以查看部分核心源码
public Vote lookForLeader() throws InterruptedException { try { this.self.jmxLeaderElectionBean = new LeaderElectionBean(); MBeanRegistry.getInstance().register(this.self.jmxLeaderElectionBean, this.self.jmxLocalPeerBean); } catch (Exception var23) { LOG.warn("Failed to register with JMX", var23); this.self.jmxLeaderElectionBean = null; } if(this.self.start_fle == 0L) { this.self.start_fle = System.currentTimeMillis(); } FastLeaderElection.Notification n; try { HashMap<Long, Vote> recvset = new HashMap(); HashMap<Long, Vote> outofelection = new HashMap(); int notTimeout = 200; synchronized(this) { ++this.logicalclock; this.updateProposal(this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch()); } LOG.info("New election. My id = " + this.self.getId() + ", proposed zxid=0x" + Long.toHexString(this.proposedZxid)); this.sendNotifications(); while(this.self.getPeerState() == ServerState.LOOKING && !this.stop) { n = (FastLeaderElection.Notification)this.recvqueue.poll((long)notTimeout, TimeUnit.MILLISECONDS); if(n == null) { if(this.manager.haveDelivered()) { this.sendNotifications(); } else { this.manager.connectAll(); } int tmpTimeOut = notTimeout * 2; notTimeout = tmpTimeOut < '\uea60'?tmpTimeOut:'\uea60'; LOG.info("Notification time out: " + notTimeout); } else if(!this.self.getVotingView().containsKey(Long.valueOf(n.sid))) { LOG.warn("Ignoring notification from non-cluster member " + n.sid); } else { Vote endVote; Vote var6; switch(FastLeaderElection.SyntheticClass_1.$SwitchMap$org$apache$zookeeper$server$quorum$QuorumPeer$ServerState[n.state.ordinal()]) { case 1: if(n.electionEpoch > this.logicalclock) { this.logicalclock = n.electionEpoch; recvset.clear(); if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch())) { this.updateProposal(n.leader, n.zxid, n.peerEpoch); } else { this.updateProposal(this.getInitId(), this.getInitLastLoggedZxid(), this.getPeerEpoch()); } this.sendNotifications(); } else { if(n.electionEpoch < this.logicalclock) { if(LOG.isDebugEnabled()) { LOG.debug("Notification election epoch is smaller than logicalclock. n.electionEpoch = 0x" + Long.toHexString(n.electionEpoch) + ", logicalclock=0x" + Long.toHexString(this.logicalclock)); } break; } if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.proposedLeader, this.proposedZxid, this.proposedEpoch)) { this.updateProposal(n.leader, n.zxid, n.peerEpoch); this.sendNotifications(); } } if(LOG.isDebugEnabled()) { LOG.debug("Adding vote: from=" + n.sid + ", proposed leader=" + n.leader + ", proposed zxid=0x" + Long.toHexString(n.zxid) + ", proposed election epoch=0x" + Long.toHexString(n.electionEpoch)); } recvset.put(Long.valueOf(n.sid), new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch)); if(!this.termPredicate(recvset, new Vote(this.proposedLeader, this.proposedZxid, this.logicalclock, this.proposedEpoch))) { break; } while((n = (FastLeaderElection.Notification)this.recvqueue.poll(200L, TimeUnit.MILLISECONDS)) != null) { if(this.totalOrderPredicate(n.leader, n.zxid, n.peerEpoch, this.proposedLeader, this.proposedZxid, this.proposedEpoch)) { this.recvqueue.put(n); break; } } if(n == null) { this.self.setPeerState(this.proposedLeader == this.self.getId()?ServerState.LEADING:this.learningState()); endVote = new Vote(this.proposedLeader, this.proposedZxid, this.logicalclock, this.proposedEpoch); this.leaveInstance(endVote); var6 = endVote; return var6; } break;
Leader与Follower同步数据(ZAB 原子广播)
Fast Leader选举算法中提到的同步数据时使用的逻辑时钟,它的初始值是0,每次选举过程都会递增的,在leader正式上任之后做的第一件事情,就是根据当前保存的数据id值,设置最新的逻辑时钟值。
随后,leader构建NEWLEADER封包,该封包的数据是当前最大数据的id,广播给所有的follower,也就是告知follower leader保存的数据id是多少,大家看看是不是需要同步。然后,leader根据follower数量给每个follower创建一个线程LearnerHandler,专门负责接收它们的同步数据请求.leader主线程开始阻塞在这里,等待其他follower的回应(也就是LearnerHandler线程的处理结果),同样的,只有在超过半数的follower已经同步数据完毕,这个过程才能结束,leader才能正式成为leader.
leader所做的工作：
所以其实leader与follower同步数据的大部分操作都在LearnerHandler线程中处理的,接着看这一块.
leader接收到的来自某个follower封包一定是FOLLOWERINFO,该封包告知了该服务器保存的数据id.之后根据这个数据id与本机保存的数据进行比较:
1) 如果数据完全一致,则发送DIFF封包告知follower当前数据就是最新的了.
2) 判断这一阶段之内有没有已经被提交的提议值,如果有,那么:
a) 如果有部分数据没有同步,那么会发送DIFF封包将有差异的数据同步过去.同时将follower没有的数据逐个发送COMMIT封包给follower要求记录下来.
b) 如果follower数据id更大,那么会发送TRUNC封包告知截除多余数据.（一台leader数据没同步就宕掉了，选举之后恢复了，数据比现在leader更新）
3) 如果这一阶段内没有提交的提议值,直接发送SNAP封包将快照同步发送给follower.
4）消息完毕之后,发送UPTODATE封包告知follower当前数据就是最新的了,再次发送NEWLEADER封包宣称自己是leader,等待follower的响应.
follower做的工作：
（1）会尝试与leader建立连接,这里有一个机制,如果一定时间内没有连接上,就报错退出,重新回到选举状态.
（2）其次在发送FOLLOWERINFO封包,该封包中带上自己的最大数据id,也就是会告知leader本机保存的最大数据id.
（3）根据前面对LeaderHandler的分析,leader会根据不同的情况发送DIFF,UPTODATE,TRUNC,SNAP,依次进行处理就是了,此时follower跟leader的数据也就同步上了.
（4）由于leader端发送的最后一个封包是UPTODATE,因此在接收到这个封包之后follower结束同步数据过程,发送ACK封包回复leader.
以上过程中,任何情况出现的错误,服务器将自动将选举状态切换到LOOKING状态,重新开始进行选举.
zookeeper的机制
分布式锁：
用zookeeper实现分布式锁有2种
方式一：根据zookeeper命名的唯一性，每个想要竞争资源的节点，创建一个相同名字的临时节点（相同路径），只能有一个节点创建成功，创建成功的节点就获得了锁
方式二：根据zk的“临时顺序”节点 ， 每个想要竞争资源的节点，在同一个节点下注册一个临时顺序节点，然后将所有临时节点按小从到大排序，如果自己注册的临时节点正好是最小的，表示获得了锁(zk能保证临时节点序号始终递增，所以如果后面有其它应用也注册了临时节点，序号肯定比获取锁的应用更大），其余节点watch排在前面的节点，只要监测到节点被删除了（锁释放之后就删除=该节点），马上重新竞争锁
