一，有什么场景提案不被大多数follower所接受?
不被接受的表象：leader没有收到过半的ack
原因：
-
follower宕机
-
网络延迟
-
follower资源不足
-
follower执行proposal失败
二，提案三个单词都不一样，是三种东西吗
Kung
三，follower同意和不同意proposal的依据是什么？
Coding
不是文字意义上的同意与否，应该理解为：
-
follower是否接收到proposal
-
follower是否成功执行proposal
-
follower是否成功响应ack给leader
以上为否即为不同意proposal
四，那不同意的那些节点，最后会保存这些数据吗？如果会的话，什么时候保存呢？
不同意即表示保存数据失败（实际有可能是保存成功，但leader未成功收到ack），会导致follower和leader的数据不一致。对于不同意的场景，zookeeper提供了最终一致性语义确保follower能够在某个时机同步leader中的新数据。
同步发生的时机：
1，集群启动时完成leader选举后；
2，leader故障恢复后；
3，客户端sync强制同步；
4，leader在收到半数成功的请求后，会向所有节点发送commit，未成功同步的节点会再次同步
五，那些没有执行成功的follow server，最后是怎样？
leader在收到半数成功的请求后，会向所有节点发送commit，为成功同步的节点会再次同步
六，如果因为网络原因导致先发的后到，这个只能通过业务代码处理吗，还是会携带发送时候机器的时间戳呢
zookeeper只能按照请求达到的时间进行排序，无法按照客户端发送请求的时间进行排序。
七，选举leader的原则是啥，随机吗
集群启动后，各server结点进入Looking状态，启动各自内部的选举客户端、服务端，大myid结点客户端连接小myid服务端，开始Election选举。
第一轮投票，各节点首先投自己一票，并将投票发送到其他各个结点，此轮无法选出leader，因为各得一票，无过半数的票。
各节点内部启动新一轮的投票，将接收到的所有投票按照epoch(选举轮次)、zxid(事务id)、myid进行大小比较，先比较epoch，epoch大的作为下一轮投票，如果epoch相等，则比较zxid，zxid大的作为下一轮投票，如果zxid相等，则比较myid，myid大的作为下一轮选票。
第二轮投票，各结点将自己的选票广播给其他结点，各节点接收到选票后进行唱票统计，过半数的投票代表的服务器即为leader，如果未有过半的选票，继续选举、投票。
八，有两种情况，一种是不在zk集群中，自然就不统一了；如果在zk集群中，最终数据会一致？
-
1，集群启动后选主成功后的同步阶段；
-
2，集群崩溃恢复选主成功后的同步阶段；
-
3，leader提交proposal后，follower同步当前proposal；
-
4，第三步如果同步失败，leader在commit时会广播消息给所有follower，follower根据zxid进行再次同步；
-
5，如果上一步再次失败，则在leader提交下一个proposal前，follower不会主动同步差异，此时会出现数据的不一致。直到leader下一次广播proposal，follower发现自己的zxid与leader的zxid有较大差别，follower请求同步所有数据。
九，实际上master和follower存在数据不一致的情况。 那读的时候又可以从所有结点，那岂不是会从不同follower读的数据不一样？ zk是咋解决这个的？
zk不能保证每次读取的数据都是最新数据，因为过半成功即认为成功，可能存在结点同步失败，同步失败结点对外提供的数据就不是最新数据。
客户端可以通过sync接口强制同步后查询数据。
十，最后可能可用的follow server越来越少？
不会，出现follower失败会被监控到，需要介入处理，不能一致宕机
十一， 选举leader的原则是啥，随机吗？
集群启动后，各server结点进入Looking状态，启动各自内部的选举客户端、服务端，大myid结点客户端连接小myid服务端，开始Election选举。
第一轮投票，各节点首先投自己一票，并将投票发送到其他各个结点，此轮无法选出leader，因为各得一票，无过半数的票。
各节点内部启动新一轮的投票，将接收到的所有投票按照epoch(选举轮次)、zxid(事务id)、myid进行大小比较，先比较epoch，epoch大的作为下一轮投票，如果epoch相等，则比较zxid，zxid大的作为下一轮投票，如果zxid相等，则比较myid，myid大的作为下一轮选票。
第二轮投票，各结点将自己的选票广播给其他结点，各节点接收到选票后进行唱票统计，过半数的投票代表的服务器即为leader，如果未有过半的选票，继续选举、投票。
十二，zookeeper为什么不支持线性扩展？
zk如果线性扩展的话，写请求leader 所在机器的性能就成了瓶颈，因为所有的同步都从leader同步，未同步完成前不能写入下一事务的数据，会造成阻塞，降低写入性能。
十三，observer不接受ZAB，那么是如何保持数据同步的？
observer不接受ZAB，即为observer同步数据失败，但其仍有机会进行下一同步，同步的几个时机如下：
-
1，集群启动后选主成功后的同步阶段；
-
2，集群崩溃恢复选主成功后的同步阶段；
-
3，leader提交proposal后，follower同步当前proposal；
-
4，第三步如果同步失败，leader在commit时会广播消息给所有follower，follower根据zxid进行再次同步；
-
5，如果上一步再次失败，则在leader提交下一个proposal前，follower不会主动同步差异，此时会出现数据的不一致。直到leader下一次广播proposal，follower发现自己的zxid与leader的zxid有较大差别，follower请求同步所有数据。
十四，zk不是cp么？今天第一次听说zk实现ap，有点懵
十五，client读取follower，返回数据之前，follower先读取leader？
十六，读取Observer上的数据时，Observer会不会每次都确认下是否和leader一致？
十七，leader的高可用性 是怎么保证的？ （也许某个时候leader挂掉了）
十八， 这个两段提交里， leader第一段 里面 有做真实写入么，还是说只是广播了提案
十九， 如果因为网络原因导致先发的后到，这个只能通过业务代码处理吗，还是会携带发送时候机器的时间戳呢
二十，这个选举算法的原则是啥，为啥不随机
二十一，如果假如 sync 机制， 是不是leader需要处理的事务更多了，负载更大会怎样 。会不会崩溃
二十二，目前大数据组件里面用的zk都是用sync吧？
二十三，节点越多，性能越差怎么理解呢？
二十四，observer为啥不能选举和被选举？？？？
二十五，问一个极端情况 如果一共有10个follow server ，在10分钟内 ，如果leader只收到3个回复（比如7个follow死机了），那么leader会一直等下去？
如果是follower宕机，集群无法自动恢复，需要运维干预。实际使用过程中，会有监控系统，如果有follower宕机，会发出警告信息，需要人工及时处理。
二十六，leader挂掉之后，剩下的集群就变成双数，选举数一半对一半怎么办
二十七，能不能让leader不处理读写 ，专心服务大家
二十八，zookeeper通过什么工具做rpc
二十九，proposal就是leader发送给follower的数据同步请求吧，ack是指follower是否同步成功？
三十，leader的三个服务端指的是进程吗
三十一，那observer 和Leader同步，不也得同步数据吗，和follower同步数据有啥区别
三十二，如果3个写请求排队写，第一次写失败了，影响后续两次的正常写吗？
三十三，leader挂掉之后，选举leader 数一半对一半怎么办
三十四，那写失败的会重试吗？
对于leader来说，过半就认为成功，不会重试
对于follower来说，失败意味着数据不一致，会主动从leader拉取数据？
三十五， zookeeper服务报错，懂原理就能解决吗？很多时候解决报错稀里糊涂的
三十六，这些node为什么不写入mysql中呢
三十七，znode有深度限制吗，一般建议值是多少？
三十八，写完内存再发commit还是 写完磁盘再发commit
三十九，内存和磁盘中都有一份， 那他们有双缓冲buffer机制吗？ hdfs就有，感觉很香。 有可能zk不怎么高并发，所以就没hdfs这种设计？
四十，一个临时节点代表一个连接？ 大量的临时节点 那就造成大量的连接 这会不会有什么问题？ 是nio?bio?还是其他呢
四十一，etcd的租约和zk的临时节点有什么区别，哪个更有优势
四十二，客户端怎么判断哪个节点是oberver 哪个是 follower
四十三，zk如果内存的数据太多了，怎么办？ hdfs为了解决元数据过多，引入了联邦机制， zk对这种问题有做什么措施吗？还是zk基本不会出现这种问题？
四十五，如果客户端把写请求发送到observer，observer 怎么办
四十六，同一件事情，多个客户端关注，先通知哪个呢？ 先进先出还是先进后出。。
四十七，那通知的实现原理是什么
四十八，通知失败了会怎样？
四十九，注册了/b watch 子节点/b/c 改变了也算吗？
五十，监听是通过长连接实现的吗，太多长连接是不是性能隐患？
五十一，问题来了，如何一直监听呢
五十二，如果前台通知老板的时候，老板没有收到，前台不就不会通知了吗，这时候怎么办
五十三，curator有一直监听的实现吗
五十四， 如果前台通知老板的时候，老板没有收到，前台不就不会通知了吗，这时候怎么办
五十五，zk生成的唯一id是有序的自增的，容易被猜到，不安全，这种问题怎么解决
五十六，集群管理这块，先上线namenode，再上线datanode， 这样才能监听datanode的变化， 如果我先上线datanode会怎么样呢
五十七，zookeeper的两阶段提交时，如果第二阶段的commit失败了，有对应的处理机制吗？
五十八，zookeeper的数据同步是拉取还是推送？
五十九，ZNode 的约束（ZNode 的节点存储的最大数据是 1M，最好不要超过 1kb）为什么？
zookeeper是分布式协调系统，不是数据存储系统，它的设计制约着其在大数据量下不能提供高效的服务。
1，zk不是分布式存储系统，所有节点的数据保持一致，即一份数据在zk集群上存储n份（n是集群节点数），且zk不支持线性扩展，注定其不能存储海量数据；
2，zk写入数据时严格按照顺序，数据量大必然导致延迟大，继而导致阻塞；
3，zk写入数据后会通知其他节点同步，并且半数写入成功才会提交事务，如果数据量大会增大写入失败的概率和事务提交的延迟，降低集群的性能；
集群性能降低，依赖其提供的集群管理等功能都会收到影响。