Zookeeper

2. ZooKeeper 提供了什么？
是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，
Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式
3. Zookeeper 文件系统
Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。 Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
4. ZAB 协议？
  ZAB协议是一种专门为zookeeper设计的一种支持崩溃回复的原子广播协议，是一种通用的分布式一致性算法，基于该协议，zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。具体来说，zookeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更为以事务的形式广播到所有的副本进程上去，该协议的这个主备模式架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更。 简言之，该协议核心就是定义了对于那些会改变zookeeper服务器数据状态的事务请求的处理方式，所有事务请求都必须由一个全局唯一的服务器来协调处理，即leader服务器。5. 四种类型的数据节点 Znode
1.持久化节点
2.临时节点
3.持久化顺序节点
4.临时顺序节点
6. Zookeeper Watcher 机制 – 数据变更通知
ZooKeeper的watcher机制，当ZNode的发生节点删除添加的操作或者节点内容发生改变，子节点的操作等，监听的Client会收到通知，然后我们可以在程序中进行自己进行处理
7. 客户端注册 Watcher 实现
创建一个 new ZooKeeper（） 客户端对象实例时，可以传入一个 Watcher .      new ZooKeeper(String connectString,int sessionTimeout, Watcher watcher)          这个Watcher 将作为整个 ZooKeeper 回话期间的默认 Watcher，会一直被保存在客户端 ZKWatchManager 的 defaultWatcher 中。 另外，ZooKeeper 客户端也可以通过 getData、 getChildren 和 exist 三个接口来向 ZooKeeper 服务器注册 Watcher。 列举个getData 例：            public byte[] getData(String path,boolean watch, Stat stat)      public byte[] getData(final String path,Watcher watch, Stat stat)        第一个通过一个 boolean 参数来标识是否使用默认 Watcher 进行注册，具体注册逻辑与第二个接口一致。注册 Watcher 后        在 getData 接口注册 Watcher 后，客户端首先会对当前客户端请求 request 进行标记， 将其设置为 ”使用Watcher“监听。同时会封装一个 Watcher 的注册信息，WatchRegistration 对象。 用于暂时保存数据节点的路径 和 Watcher 的对应关系。 Packet 与 WatchRegistration。 Packet 类        在 ZooKeeper 中 Packet 可以看做是一个最小的通信协议单元，用于进行客户端与服务端之间的网络传输，任何需要传输的对象都需要包装成一个 Packet 对象。 因此，在 ClientCnxn 中 WatchRegistration 又会被封装到 Packet 中去， 然后放入发送队列中等待客户端发送。随后，ZooKeeper 客户端就会向服务端发送这个请求，同时等待请求的返回。完成请求发送后，会由客户端 SendThread 线程的 readResponse 方法负责接收来自服务端的相应， finishPacket 方法会从 Packet 中取出对象的 Watcher 并注册到 ZKWatchManager 中去。         WatchRegistration 封装到了 Packet 对象中去，但事实上，在底层的网络传输过程中，没有将 WatchRegistration 对象完全的序列化到底层字节数组中去。ZooKeeper 只会将 requestHeader 和 request 两个属性进行序列化。 也就是说，即使WatchRegistration 对象呗封装在了 Packet 中，但是并没有被序列化到底层字节数组中去。因此也就不会进行网络传输了。 客户端 Watcher 的注册流程如下：        
8. 服务端处理 Watcher 实现
服务端处理 Watcher 的序列图：  1 FinalRequest Processor.processRequest( ) 中会判断当前请求是否是需要注册 Watcher：        1） 如果 ZooKeeper 判断当前客户端需要进行 Watcher 注册，于是就会将当前的 ServerCnxn 对象和数据路径传入 getData 方法中去。 ServerCnxn 是一个 ZooKeeper 客户端和服务器之间的连接接口，代表了一个客户端和服务器的连接。我们可以 ServerCnxn 看做是一个 Watcher 对象。因为他实现了 Watcher 的 process 接口 WatcherManager    是 ZooKeeper 服务端 Watcher 的管理者，其内部管理的 watchTable 和 watch2Paths 两个存储结构，分别从两个维度对 Watcher 进行存储。    1） watchTable     是从数据节点路径的粒度管理 Watcher。    2） watch2Paths   是从 Watcher 的粒度来控制事件触发的数据节点在服务端，DataTree 中会托管两个 WatchManager， 分别是 dataWatches （数据变更Watch） 和 childWatches（子节点变更Watch）
9. 客户端回调 Watcher      1    反序列化                字节流转换成 WatcherEvent 对象      2    处理 chrootPath                如果客户端设置了 chrootPath 属性，那么需要对服务器传过来的完整节点路径进行 chrootPath 处理，生成客户端的一个相对节点路径。 例如客户端 cPath路径 /Test/test1 那么针对服务端传过来的相应包含的节点路径为/Test/test1/1_19， 经过chrootPath 处理后 会变成一个相对路径：/ 1_19.      3    还原 WatchedEvent                WatcherEvent 转换成 WatchedEvent.      4    回调 Watcher。                最后将 WatcherEvent 对象交给 EventThread 线程，在下一个轮询周期中进行 Watcher 回调。
10. ACL 权限控制机制
ACL（Access Control List）访问控制列表包括三个方面：一、权限模式（Scheme）1、IP：从 IP 地址粒度进行权限控制2、Digest：最常用，用类似于 username:password 的权限标识来进行权限配 置，便于区分不同应用来进行权限控制3、World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标 识“world:anyone”4、Super：超级用户二、授权对象授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器灯。三、权限 Permission1、CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点2、DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点3、READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内 容或子节点列表等4、WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作5、ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置 操作

12. 会话管理
在人机交互，会话管理是保持用户的整个会话活动的互动与计算机系统跟踪过程。会话管理分类：桌面会话管理、浏览器会话管理、Web服务器的会话管理（通常指的SESSION以及COOKIE）。
13. 服务器角色
所有的服务器角色都是“固定的”角色，并且，从一开始就存在于那里——自安装完SQL Server的那一刻起，你将拥有的所有服务器角色就已经存在了。
14. Zookeeper 下 Server 工作状态
1.Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。2.Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式。3.当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。00001. 步骤阅读00002. 00003. 400004. 4为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。00005. · 
15. 数据同步
数据同步是指掌上电脑能够迅速实现与台式电脑、笔记本电脑的数据同步与信息共享，使您的数据保持完整性和统一性。数据同步是通过各种数据传输接口实现的，如USB同步底座
16. zookeeper 是如何保证事务的顺序一致性的？
FollowerRequestProcessor为Follower的首个处理器，如果是写请求，先将请求写入commitprocessor的queuedRequests（方便后续commit时判断是否本Follower提交的写请求），然后转Leader· Leader为每个请求生成zxid，下发proposal给Follower，Follower会将请求写入到pendingTxns阻塞队列及txnLog中，然后发送ack给Leaderpublic void logRequest(TxnHeader hdr, Record txn) {        Request request = new Request(hdr.getClientId(), hdr.getCxid(), hdr.getType(), hdr, txn, hdr.getZxid());        if ((request.zxid & 0xffffffffL) != 0) {            pendingTxns.add(request);        }        syncProcessor.processRequest(request);    }proposal这步是会发给所有的follower的（放到LearnerHandler的请求处理队列中，一个Follower一个LearnerHandler），之后Follower的ack就不一定全返回了· ack过半，Leader发送commit请求给所有Follower，Follower对比commit request的zxid和前面提到的pendingTxns的zxid，不一致的话Follower退出，重新跟Leader同步long firstElementZxid = pendingTxns.element().zxid;        if (firstElementZxid != zxid) {            LOG.error(“Committing zxid 0x” + Long.toHexString(zxid)                    + " but next pending txn 0x"                    + Long.toHexString(firstElementZxid));            System.exit(12);        }· Follower处理commit请求，如果不是本Follower提交的写请求，直接调用FinalRequestProcessor做持久化，触发watches；如果是本Follower提交，则做一些特殊处理（主要针对客户端连接断开的场景），然后调用FinalRequestProcessor等后续处理流程· FinalRequestProcessor做持久化，返回客户端总之：Follower通过队列和zxid等顺序标识保证请求的顺序处理，一言不合就会重新同步Leader

17. 分布式集群中为什么会有 Master？
  在分布式存储中，master也只不过是用来存储元数据信息和各种管理工作，那么如果废除master会有什么结果？    master不在，群龙无首，当权限下放的时候，chunkserver能正常的进行读写服务，但是如果是一个新的请求，那么这些chunkserver就懵逼了，根本就不能提供服务。。。其实我就想说。。。当成为了一个master节点之后，如果单纯的是数据流存储数据，其实在这个过程中，master的参与感是很弱的。。。而对于其他的整体对外服务，整体的负载均衡。。。master的作用很重大。。
18. zk 节点宕机如何处理？Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。
如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；
如果是一个Leader宕机，Zookeeper会选举出新的Leader。
ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
所以
3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)
2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)

19. zookeeper 负载均衡和 nginx 负载均衡区别
zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比zk大很多，应该说按业务选择用哪种方式。
20. Zookeeper 有哪几种几种部署模式？
部署模式：单机模式、伪集群模式、集群模式。
21. 集群最少要几台机器，集群规则是怎样的?
集群规则为2N+1台，N>0，即3台
22. 集群支持动态添加机器吗？
其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：· 全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。· 逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。3.5版本开始支持动态扩容。
23. Zookeeper 对节点的 watch 监听通知是永久的吗？为什么不是永久的?
不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。
一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。· 
24. Zookeeper 的 java 客户端都有哪些？
java客户端：zk自带的zkclient及Apache开源的Curator。
25. chubby 是什么，和 zookeeper 比你怎么看？
chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。
26. 说几个 zookeeper 常用的命令。
常用命令：ls get set create delete等。
27. ZAB 和 Paxos 算法的联系与区别？
相同点：· · 两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行· Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交· ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为Ballot· 不同点：
ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。· 
28. Zookeeper 的典型应用场景
Zookeeper是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员可以使用它来进行分布式数据的发布和订阅。通过对Zookeeper中丰富的数据节点进行交叉使用，配合Watcher事件通知机制，可以非常方便的构建一系列分布式应用中年都会涉及的核心功能，如：· 数据发布/订阅· 负载均衡· 命名服务· 分布式协调/通知· 集群管理· Master选举· 分布式锁· 分布式队列