zookeeper基础知识

﹏ヽ暗。殇╰゛Y 2021-09-20 08:00 277阅读 0赞

1.  理解什么是CAP定理
    
    1.  可用性、一致性、分区容错性
        
        **一致性**  
        分布式系统下的一致性是指如果对节点A进行更新操作并且更新成功后，其他的节点上的副本数据也应该是节点A更新后的最新数据，如果客户端在访问其他节点读取到在节点A更新后更旧的值，那就是出现了数据不一致的情况。在更新完后就能够访问到最新的值，这样的一致性叫做强一致性或者叫做严格一致性。
        
        **可用性**  
        可用性是指系统提供的服务必须一直处于可用的状态，对于用户的请求总是能够在有限的时间内返回结果。对于搜索引擎类的系统而言，搜索一个关键字，系统需要在0.3s内给出相应的结果。
        
        **分区容错性**
        
        分区容错性要求系统在遇到任何网络分区故障的时候，系统仍然需要保证对外提供满足一致性和可用性，除非是整个网络环境都发生故障。
        
        <table> 
         <thead> 
          <tr> 
           <th align="center"><strong>放弃CAP定理</strong></th> 
           <th align="left">说明</th> 
          </tr> 
         </thead> 
         <tbody> 
          <tr> 
           <td align="center">放弃C</td> 
           <td align="left">这里说的一致性是指数据的强一致性，而不是丢弃数据的一致性。抛弃强一致性，也就是客户端在访问时，可能会访问到数据的中间状态，但这不影响数据的最终一致性。</td> 
          </tr> 
          <tr> 
           <td align="center">放弃A</td> 
           <td align="left">做法是系统一旦遇到网络分区或者其他故障时，那么受到影响的服务需要等待一定的时间，等待期间部分系统服务无法正常对外提供服务，既不可用。</td> 
          </tr> 
          <tr> 
           <td align="center">放弃P</td> 
           <td align="left">如果希望避免出现分区容错性问题，最简单的做法是把所有的数据都放在一个分布式节点上，这样的做法虽然不能百分之百保证系统不会出现问题，但是至少不会碰到网络分区带来的问题，需要注意的是，放弃P的同时也就放弃了系统的可扩展性。</td> 
          </tr> 
         </tbody> 
        </table>
        
        **BASE**  
        BASE是Basically Available（基本可用），Soft state（软状态），Eventually consistent（最终一致性）。
        
        **基本可用**  
        基本可用是指系统在出现故障的时候，允许损失部分可用性，损失部分可用性，不代表系统是不可用的。
        
        相应时间上的损失：原本应该在1s中给出相应的，现在可以推迟到2-3s的时间给出相应。  
        功能上的损失：例如在天猫双十一的时候，当天天猫会把后台的退货功能暂时关闭，会对一些页面做降级处理，以及一些在大促期间不需要的一些功能。  
        **软状态**  
        软状态就是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响到系统的整体可用性。
        
        **最终一致性**  
        最终一致性强调的是系统中的所有的数据副本，经过一段时间的同步，最终会达到一个一致的状态。
        
        **最终一致性的五种变体**  
        因果一致性  
        读已之所写  
        回话一致性  
        单调读一致性
        
         单调写一致性
2.  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与之同步
3.  zookeeper有哪些集群模式
    
    zookeeper 有三种部署模式：
    
    单机部署：一台集群上运行；  
    集群部署：多台集群运行；  
    伪集群部署：一台集群启动多个 zookeeper 实例运行。
4.  zookeeper Server有哪些状态和哪些角色
    
    Zookeeper的角色:
    
    » 领导者（leader），负责进行投票的发起和决议，更新系统状态  
    　　» 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票  
    　　» Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度  
    　　» 客户端（client），请求发起方

相关面试题

1.  结合zookeeper详细说明CAP定理\*\*  
    （1）**C**: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.  
    （2）**A**: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()  
    （2）**P**: 有2点需要分析的.  
    **①** 节点多了会导致写数据延时非常大,因为需要多个节点同步  
    **②** 节点多了Leader选举非常耗时, 就会放大网络的问题.
    
     可以通过引入 observer节点缓解这个问题.
2.  **详述zookeeper的广播模式和恢复模式**
    
    **进入恢复模式的时机**:  
    集群刚刚启动的时候。  
    leader 因为故障宕机了。  
    leader 失去了半数的支持。
    
    然后接下来的操作就是选主操作了。
    
    **广播模式**
    
    1.  在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。
    2.  ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
    3.  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。
    4.  zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP最终实现一致性的一个体现。
    5.  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给该节点名称进行顺序编号