、zookeeper是什么框架？
zookeeper是一个开源的分布式协调服务框架。
2、有哪些应用场景？
应用场景：分布式通知/协调、负载均衡、配置中心、分布式锁、分布式队列等。
3、使用什么协议？
使用ZAB协议。
4、说说分布式一致性算法Paxos
5、说一说选举算法及流程
6、zookeeper有哪几种节点类型？
节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。
7、zookeeper对节点的watch监听通知是永久的吗？
不是永久的，一次性的，需要借助第三方工具实现重复注册。
8、有哪几种部署模式？
部署模式：单机模式、伪集群模式、集群模式。
9、集群中的机器角色都有哪些？
集群角色：leader、foller、observer。
10、集群最少要几台机器，集群规则是怎样的
集群规则为2N+1台，N>0，即3台。
11、集群如果有3台机器，挂掉一台集群还能工作吗？挂掉两台呢？
集群需要一半以上的机器可用，所以，3台挂掉1台还能工作，2台不能。
12、集群支持动态添加机器吗？
3.5版本开始支持动态扩容。
13、zookeeper的java客户端都有哪些？
java客户端：zk自带的zkclient及Apache开源的Curator。
14、chubby是什么，和zookeeper比你怎么看？
chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。
15、说几个zookeeper常用的命令。
常用命令：ls get set create delete等。
应用场景
Zookeeper的功能很强大，应用场景很多，结合我实际工作中使用Dubbo框架的情况，Zookeeper主要是做注册中心用。基于Dubbo框架开发的提供者、消费者都向Zookeeper注册自己的URL，消费者还能拿到并订阅提供者的注册URL，以便在后续程序的执行中去调用提供者。而提供者发生了变动，也会通过Zookeeper向订阅的消费者发送通知。
Paxos算法& Zookeeper使用协议
Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播），二者有相同的地方，比如都有一个Leader，用来协调N个Follower的运行；Leader要等待超半数的Follower做出正确反馈之后才进行提案；二者都有一个值来代表Leader的周期。
不同的地方在于：
ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。
Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿，自1990年莱斯利·兰伯特提出Paxos算法以来，因为晦涩难懂并没有受到重视。后续几年，兰伯特通过好几篇论文对其进行更进一步地解释，也直到06年谷歌发表了三篇论文，选择Paxos作为chubby cell的一致性算法，Paxos才真正流行起来。
对于普通开发者来说，尤其是学习使用Zookeeper的开发者明确一点就好：分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。
选举算法和流程
详情可参看我之前的文章《ZooKeeper集群安装配置使用》第6节“ZooKeeper选举机制”，有个简单的描述。
Zookeeper有哪几种节点类型
持久：创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。
持久顺序：跟持久一样，就是父节点在创建下一级子节点的时候，记录每个子节点创建的先后顺序，会给每个子节点名加上一个数字后缀。
临时：创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。
临时顺序：不用解释了吧。
Zookeeper对节点的watch监听通知是永久的吗？
不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。
为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。
一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。
部署方式？集群中的机器角色都有哪些？集群最少要几台机器
单机，集群。Leader、Follower。集群最低3（2N+1）台，保证奇数，主要是为了选举算法。
集群如果有3台机器，挂掉一台集群还能工作吗？挂掉两台呢？
记住一个原则：过半存活即可用。
集群支持动态添加机器吗？
其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：
全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。
逐个重启：顾名思义。这是比较常用的方式。
列举至少3个Mysql的具体优化？
（1）适当的对表里的字段建立索引
索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行。但是索引不能随便建立，具体建立索引的地方，建议如下：
1）查询语句当中包含有MAX(),MIN()和ORDERBY这些命令的时候
2）用于JOIN,WHERE判断和ORDERBY排序的字段上
3）尽量不要对数据库中某个含有大量重复的值的字段建立索引，比如如果这个字段是性别的枚举值。
（2）使用联合(UNION)来代替手动创建的临时表
union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效
（3）针对select查询语句进行优化
1）在建有索引的字段上尽量不要使用函数进行操作
例如：在一个DATE类型的字段上使用week()函数时，将会使索引不能发挥应有的作用。
2）尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
2. 分布式协调zookeeper的如何进行领导选举的？
（1）选举原理图：
（2）具体解释如下：
1）每个Server启动以后都询问其它的Server它要投票给谁。
2）对于其他server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）
3）收到所有Server回复以后，就计算出zxid最大的哪个Server，并将这个Server相关信息设置成下一次要投票的Server。
4）计算这过程中获得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则该server被选为leader。否则，继续这个过程，直到leader被选举出来。
3. 简述Tcp协议中的CLOSE_WAIT的发生过程？引发的问题?解决方法
（1）该状态发生的阶段，先看整体流程图
具体解释如下：
客户端主动关闭时，发出FIN包，收到服务器的ACK，客户端停留在FIN_WAIT2状态。而服务端收到FIN，发出ACK后，停留在COLSE_WAIT状态。
（2）Close_Wait引发的问题
Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 甚至会耗尽连接池的网络连接数，导致无法建立网络连接
（3）解决方法：
从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。一定程度上，可以使用TCP的KeepAlive功能，让操作系统替我们自动清理掉CLOSE_WAIT连接。
4. Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？
Leader服务器是整个zookeeper集群工作的核心，负责进行选举投票的发起和决议，更新系统状态。
Follower服务器是zookeeper集群状态的跟随者，用于接收客户端的请求并向客户端返回结果，在选举过程中参与投票。
1.每个Sever服务器启动以后都会询问其他的Sever服务器要投票给谁
2.对于其他服务器的询问，服务器每次都会根据自己的状态恢复自己推荐的Leader的id和上一次处理事务的zxid，但是系统启动的时候每个服务器都会推荐自己的
3.自己服务器收到其他所有的服务器回复以后，就计算出zxid最大的那个服务器，并将这个服务器相关信息设置成下一次要投票的Sever
4.计算的过程中获得的票数最多，且票数要过半数的服务器就选为Leader，否则要一直继续这个选举的过程，知道Leader被选举出来
5.选出的Leader开始等待其他服务器Follower的连接
6.Follower连接Leader将最大的zxid发送给Leader
7.Leader根据Follwer的zxid来确定同步点，，完成同步后通知Follower已经成为update（现时）状态
8.Follower收到update消息后，就可以接受Client的请求服务了。