-
理解什么是CAP定理
-
可用性、一致性、分区容错性
一致性
分布式系统下的一致性是指如果对节点A进行更新操作并且更新成功后，其他的节点上的副本数据也应该是节点A更新后的最新数据，如果客户端在访问其他节点读取到在节点A更新后更旧的值，那就是出现了数据不一致的情况。在更新完后就能够访问到最新的值，这样的一致性叫做强一致性或者叫做严格一致性。可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的请求总是能够在有限的时间内返回结果。对于搜索引擎类的系统而言，搜索一个关键字，系统需要在0.3s内给出相应的结果。分区容错性
分区容错性要求系统在遇到任何网络分区故障的时候，系统仍然需要保证对外提供满足一致性和可用性，除非是整个网络环境都发生故障。
放弃CAP定理 说明 放弃C 这里说的一致性是指数据的强一致性，而不是丢弃数据的一致性。抛弃强一致性，也就是客户端在访问时，可能会访问到数据的中间状态，但这不影响数据的最终一致性。 放弃A 做法是系统一旦遇到网络分区或者其他故障时，那么受到影响的服务需要等待一定的时间，等待期间部分系统服务无法正常对外提供服务，既不可用。 放弃P 如果希望避免出现分区容错性问题，最简单的做法是把所有的数据都放在一个分布式节点上，这样的做法虽然不能百分之百保证系统不会出现问题，但是至少不会碰到网络分区带来的问题，需要注意的是，放弃P的同时也就放弃了系统的可扩展性。 BASE
BASE是Basically Available（基本可用），Soft state（软状态），Eventually consistent（最终一致性）。基本可用
基本可用是指系统在出现故障的时候，允许损失部分可用性，损失部分可用性，不代表系统是不可用的。相应时间上的损失：原本应该在1s中给出相应的，现在可以推迟到2-3s的时间给出相应。
功能上的损失：例如在天猫双十一的时候，当天天猫会把后台的退货功能暂时关闭，会对一些页面做降级处理，以及一些在大促期间不需要的一些功能。
软状态
软状态就是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响到系统的整体可用性。最终一致性
最终一致性强调的是系统中的所有的数据副本，经过一段时间的同步，最终会达到一个一致的状态。最终一致性的五种变体
因果一致性
读已之所写
回话一致性
单调读一致性 单调写一致性
-
-
zookeeper有哪些特性
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，
ZooKeeper是以Fast Paxos算法为基础，实现同步服务，配置维护和命名服务等分布式应用。
1.统一配置文件管理,只需要部署一台服务器 ,则可以把相同的配置文件，同步更新到其他所有服务器，比如修改了redis统一配置。
2.发布与订阅，类似消息队列MQ、amq、rmq，dubbo 发布者把数据存在znode节点上，订阅者会读取这个数据。
3.提供分布式锁，分布式环境中，不同进程之间争夺资源，类似于多线程中的的锁。
4.集群管理，在集群中保证数据的一致性。Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步 -
zookeeper有哪些集群模式
zookeeper 有三种部署模式：
单机部署：一台集群上运行；
集群部署：多台集群运行；
伪集群部署：一台集群启动多个 zookeeper 实例运行。 -
zookeeper Server有哪些状态和哪些角色
Zookeeper的角色:
» 领导者（leader），负责进行投票的发起和决议，更新系统状态
» 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
» Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
» 客户端（client），请求发起方
相关命令:
#zk服务命令
1. 启动ZK服务: sh bin/zkServer.sh start
2. 查看ZK服务状态: sh bin/zkServer.sh status
3. 停止ZK服务: sh bin/zkServer.sh stop
4. 重启ZK服务: sh bin/zkServer.sh restart
#zk 客户端命令
#创建节点，并设置初始内容
create /my "zk"
#获得一个节点信息
get /my
#查看所有节点
ls /
#查看节点信息
ls2 /
#删除节点
delete /my
#退出客户端
quit
相关面试题
-
结合zookeeper详细说明CAP定理**
（1）C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.
（2）A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()
（2）P: 有2点需要分析的.
① 节点多了会导致写数据延时非常大,因为需要多个节点同步
② 节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.
-
详述zookeeper的广播模式和恢复模式
进入恢复模式的时机:
集群刚刚启动的时候。
leader 因为故障宕机了。
leader 失去了半数的支持。然后接下来的操作就是选主操作了。
广播模式
-
在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。
-
ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
-
zookeeper中消息广播的具体步骤如下：
（1）Client通过某个follower请求写操作时，该follower会把这个请求发给leader；
（2）leader再将这个更新（proposal），顺序发送给follower；
（3）follower收到leader更新时，follower会将数据持久化到磁盘；
（4）当follower写到磁盘后，就会向leader发送ACK；
（5）当leader收到半数以上的follower向它发送ACK后，就向全部的follower发送commit；
（6）leader并在本地commit消息（commit的意思是就是这个消息可对外读了）；
（7）当follower收到leader发送的commit后，就会将磁盘里的数据写进内存数据库，同时commit（每个follower都有内存数据库，Client去向follower请求数据时，都是通过内存数据库读取的）。同时每条消息，都有一个递增的id。 -
zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP最终实现一致性的一个体现。
-
leader服务器与每个follower之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。
详述zookeeper选主的流程**
-
当leader崩溃或者leader失去大多数的follower，这时zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。
Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
第一种：全新选举
假设目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，
它们的选择举过程如下：
服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking。
服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。
服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。
服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。
服务器 5 启动，后面的逻辑同服务器 4 成为小弟
第二种：非全新选举
在Zookeeper运行期间，Leader与following服务器各司其职，即便当有following服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下：
(1) 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
(2) 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
(3) 接收来自各个服务器的投票。与启动时过程相同。
(4) 处理投票。与启动时过程相同，此时，Server1将会成为Leader。
(5) 统计投票。与启动时过程相同。
(6) 改变服务器的状态。与启动时过程相同。
Leader选举算法分析
在3.4.0后的Zookeeper的版本只保留了TCP版本的FastLeaderElection选举算法。当一台机器进入Leader选举时，当前集群可能会处于以下两种状态
· 集群中已经存在Leader。
· 集群中不存在Leader。
对于集群中已经存在Leader而言，此种情况一般都是某台机器启动得较晚，在其启动之前，集群已经在正常工作，对这种情况，该机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器而言，仅仅需要和Leader机器建立起连接，并进行状态同步即可。而在集群中不存在Leader情况下则会相对复杂，其步骤如下
(1) 第一次投票。无论哪种导致进行Leader选举，集群的所有机器都处于试图选举出一个Leader的状态，即LOOKING状态，LOOKING机器会向所有其他机器发送消息，该消息称为投票。投票中包含了SID（服务器的唯一标识）和ZXID（事务ID），(SID, ZXID)形式来标识一次投票信息。假定Zookeeper由5台机器组成，SID分别为1、2、3、4、5，ZXID分别为9、9、9、8、8，并且此时SID为2的机器是Leader机器，某一时刻，1、2所在机器出现故障，因此集群开始进行Leader选举。在第一次投票时，每台机器都会将自己作为投票对象，于是SID为3、4、5的机器投票情况分别为(3, 9)，(4, 8)， (5, 8)。
(2) 变更投票。每台机器发出投票后，也会收到其他机器的投票，每台机器会根据一定规则来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票，这个规则也是整个Leader选举算法的核心所在，其中术语描述如下
· vote_sid：接收到的投票中所推举Leader服务器的SID。
· vote_zxid：接收到的投票中所推举Leader服务器的ZXID。
· self_sid：当前服务器自己的SID。
· self_zxid：当前服务器自己的ZXID。
每次对收到的投票的处理，都是对(vote_sid, vote_zxid)和(self_sid, self_zxid)对比的过程。
规则一：如果vote_zxid大于self_zxid，就认可当前收到的投票，并再次将该投票发送出去。
规则二：如果vote_zxid小于self_zxid，那么坚持自己的投票，不做任何变更。
规则三：如果vote_zxid等于self_zxid，那么就对比两者的SID，如果vote_sid大于self_sid，那么就认可当前收到的投票，并再次将该投票发送出去。
规则四：如果vote_zxid等于self_zxid，并且vote_sid小于self_sid，那么坚持自己的投票，不做任何变更。
结合上面规则，给出下面的集群变更过程。
(3) 确定Leader。经过第二轮投票后，集群中的每台机器都会再次接收到其他机器的投票，然后开始统计投票，如果一台机器收到了超过半数的相同投票，那么这个投票对应的SID机器即为Leader。此时Server3将成为Leader。
由上面规则可知，通常那台服务器上的数据越新（ZXID会越大），其成为Leader的可能性越大，也就越能够保证数据的恢复。如果ZXID相同，则SID越大机会越大。
2、结束恢复模式
新leader被选举起来后，且大多数的follower完成与leader的状态同步后，恢复模式即结束，进入广播模式。
3、恢复模式的意义
每个消息的id（zxid）是64位，前面32位称为epoch，后面32位称为counter。
（1）发现集群中被commit的proposal的最大的zxid，之后的leader不会commit比这zxid小的 proposal，也就是说leader只能commit比这大的proposal。
（2）建立新的epoch，从而保证之前的leader不能再commit新的proposal
（每选举出一个新的leader，epoch都会改变，且比之前的大，且保证一个leader的任期内，epoch不会被改变）。
（3）集群中大部分节点都commit过前一个leader commit过的消息，而新的leader是被大部分节点锁支持的（会选举出于前leader保持最为紧密的follower作为leader），
所以被之前leader commit过的proposal不会丢失，至少被一个节点所保存。
（4）新的leader会与所有follower通信，从而保证大部分节点都拥有最新的数据。
4.列出zookeeper节点命令及其作用
1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号