Zookeeper学习总结（一）提问与回答
以不断提问题的方式进行更多的思考。本人经验尚缺，如有错误之处，还请帮忙指正，让咱们共同成长。
- Zookeeper产生的背景?
答： 引用《从PAXOS到ZOOKEEPER分布式一致性原理与实践》4.1.2中的原语。从该段话中，有两个重要的关键词为分布式协调、单点问题。后面用2和3进行解答。
Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型的系统需要依赖一个类似的系统进行分布式协调，但是这些系统往往存在分布式单点问题。所以雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架。在立项初期，考虑到很多项目都是用动物的名字来命名的(例如著名的Pig项目)，雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家Raghu Ramakrishnan开玩笑说：再这样下去，我们这儿就变成动物园了。此话一出，大家纷纷表示就叫动物园管理员吧——因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好用来进行分布式环境的协调——于是，Zookeeper的名字由此诞生了。
2）何为分布式协调？
答：对分布式系统之间的交互进行处理，比如：分布式锁，集群管理（如：kafka集群）都属于一种交互。
3）何为分布式协调框架？
答： 对分布式系统中各种交互进行统一的处理抽象，做到精简性，扩展性等。比如说，zookeeper基本概念中没有出现具体的一种分布式交互，只说了我们可以把zookeeper用于各种场景中。
4）Zookeeper如何解决单点问题？
答：Zookeeper仍然沿用Master/Slave集群模式。若Master宕机后，集群可用数量仍在一半以上，就会在集群服务器之间重新选举新的Master，这个新的Master可能是原先的Slave或Master（Master宕机后重新恢复）。注意：Zookeeper采用类似paxos协议的分布式算法，要求集群可用数量在一般以上才能正常工作。如果问为什么要有一般以上的集群服务器才可以正常工作的话，只能说这个算法就是这样。
5）Zookeeper如何解决自身集群中数据的一致性？
答：Master存活时采用Zab（Zookeeper Atomic Broadcast）协议进行数据同步。若Master宕机后，集群在重新选举新的Master时，整个集群是不可用的，新的Master选举出来后会自动进行数据同步，达到数据一致性。
6）Zookeeper是否支持高可用?
答：不能很好的支持高可用。因为集群在选举Master和选举Master后的数据同步期间，并不能对外提供服务。不同系统对高可用的指标有可能不同，所以是否支持高可用还得看具体系统。
7）Zookeeper是否能支持高并发？
答：一个5节点的Zookeeper集群的TPS在万级。所以并不能直接对接大量高并发的请求，再说它主要解决的问题并不在于如何提高吞吐量和存储量，它主要解决的是分布式系统之间交互的问题。这种吞吐量和存储量的问题还得交由那些消息中间件们解决。
8）为什么Zookeeper不能支持高并发？
答：因为Zab协议同步和Master选举，以及选举后的同步都是耗时的操作。必须得在一致性，容错性，和高并发等之间进行取舍。
9）zookeeper是否能作为储存用？
答： 不能，因为zookeeper将所有数据存储在内存中。内存中采用树状结构进行存储，我们称树中的每个节点为ZNode，每个ZNode都可以包含数据。ZNode可以分为持久节点和临时节点。持久节点一旦创建后将会一直保存在Zookeeper上，除非主动删除。临时节点的生命周期与客户端绑定，一旦客户端失效，那么这个客户端创建的所有临时节点都会被移除。另外Zookeeper还允许用户为每个节点添加一个特殊的属性Sequential，一旦节点被标记上这个属性，那么在这个节点被创建时，Zookeeper会自动在其节点名后追加上一个整型数字，这个整型数字是由父节点维护的自增数字。
10）Zookeeper是否能保证强一致性？
答：关于这个问题，网上各有各的回答，有说通过Sync操作能保证强一致性，还有单调一致性，最终一致性等。这里不再累述。
11）Zookeeper的一些典型应用场景有哪些？
答：
1、数据发布/订阅（比如：作为配置中心。客户端首先订阅主题ZNode，然后数据一旦有变更Zookeeper就发布更新，最后客户端收到最新的配置）
2、负载均衡（客户端从Zookeeper上获取服务器列表，然后采用负载均衡算法选取服务器。服务器列表一旦有变化，也会及时通知客户端。当然这里也涉及到服务器的心跳检测，若检测失败则及时更新服务器列表）
3、命名服务（对分布式系统中一些资源进行命名）
4、集群管理（一个非常重要的用途是集群Master节点的选举，比如Kafka集群。可以利用临时节点的特性，因为多个服务器同时创建一个临时节点时，只有一个会成功。一旦Master宕机，则临时节点会自动删除并通知其他节点进行Master的选举）
5、分布式锁（比如排它锁：多个服务器节点同时创建一个临时节点Znode，只有一个A能创建成功，即该服务器A获得了拍它锁。A操作完了业务逻辑后就可以删除临时节点，然后其他节点会自动获得通知进行新一轮的抢占）
其实这5个应用场景都是只用了Zookeeper的一些特性（节点ZNode和Watch机制），所以说它是分布式系统交互的高度抽象处理方式。能应用到很多场景，就怕想不到。
