Java面试题分享-Zookeeper

问：CAP定理
答：1)CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性
2)一致性(Consistency) ：客户端知道一系列的操作都会同时发生(生效)
3)可用性(Availability) ：每个操作都必须以可预期的响应结束
4)分区容错性(Partition tolerance) 即使出现单个组件无法可用,操作依然可以完成

问：BASE理论
答：在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢前人已经给我们提出来了另外一个理论，
就是BASE理论，它是用来对CAP定理进行进一步扩充的，BASE理论指的是：Basically Available(基本可用)，Soft state(软状态)
Eventually consistent(最终一致性)，BASE理论是对CAP中的一致性和可用性进行一个权衡的结果理论的核心思想就是：我们无法做到强一致
但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

问：分布式事务的解决方案
答：在分布式系统中，要实现分布式事务，无外乎那几种解决方案，两阶段提交(2PC)，第一阶段：事务协调器要求每个涉及到事务的数据库预提交
(precommit)此操作，并反映是否可以提交.第二阶段：事务协调器要求每个数据库提交数据，补偿事务(TCC)，本地消息表，MQ 事务消息

问：zookeeper是如何保证事务的顺序一致性的
答：zookeeper采用了递增的事务Id来标识，所有的proposal都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch用来标识
leader是否发生改变，如果有新的leader产生出来,epoch会自增，低32位用来递增计数，当新产生proposal的时候，会依据数据库的两阶段过程,
首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

问：Paxos算法
答：Paxos算法是分布式选举算法，可以用来来选举leader，是分布式系统如何对一个问题达成共识，从提案到表决流程涉及到三个角色：
Proposer：提案者，可能有多个，它门负责提出提案。
Acceptor：接受人，一定要有多个，它们对指定提案进行表决，同意则接受提案，不同意则拒绝。
Learner：学习人，收集每位Acceptor接受的提案，并根据少数服从多数的原则，形成最终提案。
两个阶段，第一阶段，提案并编号，第二阶段，看各方意见是否接受提案

问：zookeeper中的节点类型
答：zk中znode类型有四种
1)持久化目录节点，
2)持久化顺序编号目录节点(有顺序 能够在注册机器等许多场景用到)
3)临时目录节点
4)临时顺序编号节点

问：zk的通知机制
答：client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。

问：zk的配置管理
答：程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发生改变时，也就是znode发生变化时
可以通过改变zk中某个目录节点的内容，利用water通知给各个客户端从而更改配置。

问：zk的命名服务
答：命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径这个路径就可以作为一个名字，
指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

问：分布式通知和协调
答：对于系统调度来说：操作人员发送通知实际是通过控制台改变某个节点的状态，然后zk将这些变化发送给注册了这个节点的watcher的所有客户端
对于执行情况汇报：每个工作进程都在某个目录下创建一个临时节点，并携带工作的进度数据,这样汇总的进程可以监控目录子节点的变化获得工
作进度的实时的全局情况。

问：机器中为什么会有master
答：在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能
于是就需要进行master选举。

问：Zookeeper应用场景
答：Zookeeper的功能很强大,应用场景很多,结合我实际工作中使用Dubbo框架的情况，Zookeeper主要是做注册中心。