Zookeeper

Zookeeper

CAP原则

CAP 

        一致性（C）：数据在操作以后各节点进行同步，同步的过程中不能进行其他的操作，最终保证一致性。

                强一致性：进行广播时，所有的节点都广播。

                弱一致性：在广播时，只要广播超过一半的节点就可以。

        可用性（A）：对数据操作以后，在一定时间内返回结果，无论成功或失败

        分区容错性（P）：在分布式系统中，当有的节点宕机不可用时，仍有其他节点提供服务。

        以上的原则，只能保证同时两种原则在分布式系统中。

       

Base理论    

        强一致性：进行广播时，所有的节点都广播。

        弱一致性：在广播时，只要广播超过一半的节点就可以

如何选择CAP原则 

       1. 对于要求强一致性的系统，可以牺牲掉可用性或者分区容错性，因为一致性会增加延迟和负载。例如在银行系统，或者支付系统等要求强一致性的系统。

        2.对于可用性要求强的系统，可以牺牲掉一致性或者分区容错。例如在电商平台，社交网络。

        3.对于分区容错性要求的系统，可以牺牲掉一致性或者可用性。例如数据中心之间的分布式系统，要求保证网络分区容错性。

Paxos算法

算法演变过程

        拜占庭将军问题

        Paxos算法基本模型

        Paxos工作流程

         Paxos算法冲突

         冲突问题:当1节点正要广播至2节点时，2节点向3节点发出询问，此时3节点拒绝2节点的询问，当1节点广播完成后，2节点再发起询问，过半即可 。

         Paxos算法活锁问题(无主模式)

        活锁指的是一种并发控制问题，当多个线程或进程在竞争获取资源时，它们可能会出现互相等待的情况，导致无法进行进一步的处理。不同于死锁，活锁中的线程一直在运行，但是它们却无法执行预期的操作，因为它们被迫一直重试相同的操作，从而无法进展。活锁通常是由于设计问题或者算法的错误导致的。(A B都想打印东西，A拿着纸，B占着打印机，如果其中一方不想打印东西了，另一个就可以继续完成工作，存在资源的抢夺)

        死锁是指多个进程或线程因互相占有其他进程或线程所需要的资源而陷入一种互相等待的状态，而无法继续执行下去，直到外部干预才能解决。(A调用B，B调用A，A需要拿到B的锁取执行任务，B需要拿着A的锁去执行任务，而A B又同时执行者任务，谁也拿不到对方的锁) 

        Paxos算法有主模式

        Paxos算法选主 

        zookeeper的脑裂问题通过过半原则解决，只有票数过半才能当选为主。

 ZAB协议(Paxos算法优化)

        ZAB 协议，全称 ZooKeeper Atomic Broadcast（ZooKeeper 原子广播协议）。它是专门为分

布式协调服务——ZooKeeper 设计的一种支持崩溃恢复和原子广播的协议。

        崩溃恢复就是选主流程

        原子广播就是二阶段

 三种角色

        leader:负责投票的发起和广播，更新系统状态，参与投票。

        follower:负责接受客户端请求，响应数据给客户端，并转发给leader,参与投票。

        observer:将客户端的写请求转发给leader,响应客户端的读请求，不参与投票，只是为了扩展系统，提高读取速度。

Zookeeper零碎知识

        Zookeeper是弱一致性，投票过半即可，AP架构。

        Redis是AP架构。

Zookeeper的特点 

        zookeeper是一个树状结构，维护的是一个小型数据节点znode;

        数据以KeyValue的形式存在，目录（znode）是数据的key；

        所有的数据访问必须以绝对路径的方式访问；

Znode的特点

        层次结构：每个znode都有一个唯一的路径表示；

        临时节点：会话断开以后失效；

        持久节点：一直存在，知道显示删除，用于存储配置信息，状态信息；

        序列节点：每个Znode都可以设置一个单调递增全局唯一的序列号(一个目录下持久节点和临时节点共同维护一个序列号)，用于实现分布式队列等场景。

zookeeper的存储模型

持久节点（默认创建的）：create /path data 默认创建持久节点

持久序列节点：create -s /path data 创建顺序节点

临时节点（会话断开后失效自动删除）：create -e /path data 创建临时节点

临时序列节点 （会话断开后失效自动删除）：create -es /path data 创建临时节点

  -e:代表临时节点           -s:代表顺序节点          -es代表临时顺序节点

Zookeeper的监听机制 

        zookeeper的监听机制通过注册监听器实现，客户端可以对节点的创建，删除，节点数据更新监听，当事件发生时，zookeeper会通知对应的监听器，zookeeper会保证每个事件通知一次，客户端需要在接收到事件通知后从新注册监听器才能继续监听。

        使⽤addWatch命令注册监听器， 它是 针对指定节点添加事件监听，⽀持两种模式：                  PERSISTENT ：持久化订阅(一直监听)，针对当前节点的修改和删除事件，以及当前节点的⼦节点的添加和删除事件。

        PERSISTENT_RECURSIVE ：持久化递归订阅(一直监听当前节点和他的子节点)，在 PERSISTENT 的基础上，增加了⼦节点修改的事件触发

 

      注:这里的分布式锁成为主，然后执行完任务后再释放锁，并不是真正的在选主，这里的分布式锁只是为了去理解监听机制。  

---

        瞎写

         addWatch命令

       1. addWatch  /path data   监听非序列节点 ，如果该序列为临时节点，会话结束后失效(自动删除)，这可以是zookeeper帮其他组件选主抢，谁先注册该节点谁为主，当他宕机后，其他节点通过监听器得知后，抢者创建create -e /path data该节点。如果监听的是持久节点，当他宕机后其他节点都不知道，无法释放分布式锁，我们可以设置过期时间的节点来释放锁(只要超过了设置的时间就会释放分布式锁资源)

       2. addWatch  /path data0000002    监听序列节点，谁的节点数低谁就是主(谁先来创建了目录谁就是主)，根据顺序，下一个只对上一个节点监听，只要一释放锁资源，就按序号创建目录(分布式锁)，实现了公平。

        1是抢着创建，只要一宕机或者释放分布式锁谁先注册谁是主，所以监听的是非序列节点。2是排队创建，他们共同维护的一个队列，后一个节点只对紧挨着自己的前一个节点监听，只有前一个节点宕机或者释放了分布式锁下一个节点才能创建。

        这里的创建成为主，然后释放资源并不是真正意义上的主，这里只是为了方便理解监听机制。

---

Zookeeper选主的过程

        集群启动后，

        如果集群是一台一台启动的，只要票数超过节点的一半，该节点就成为主。

        如果服务器同时启动，服务器id（myid）最大的成为主。

        宕机恢复以后的选主

        1.选择具有最大朝代的节点。

        2.如果朝代相同，选择具有最大 zxid 的节点。

        3.如果朝代和 zxid 都相同，选择具有最大节点 ID 的节点

        如果是其他的follower服务器宕机了，就去找主同步数据

Zookeeper如何帮助其他组件选主(通过存储模型和监听机制)

        集群启动后，谁先创建了节点谁就成为了主，其他接点对主进行监听，当主宕机后，监听的节点收到通知后创建成为主。