zookeeper整体概览
Zk 的特性
? 这块是重点之中的重点，包括实战，都是建立在这基础之上的。其中数据模型和 watch 机制又是最最重要的
zk 高级知识
? 客户端的简单使用能解决一些问题，方便查看信息，简单省事，但真正对于我们 java 架构师来说最重要的是 java 客户端，包括原生的zkclient 以及 curotor，最少要熟练使用其中的一种
分布式系统是什么
? 分布式系统：一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递 进行通信和协调的系统
? 这是分布式系统: 在不同的硬件，不同的软件，不同的网络，不同的计算机上，仅仅通过消 息来进行通讯与协调
? 它的特点，更细致的看这些特点又可以有：分布性、对等性、并发性、缺乏全局时钟、 故障随时会发生。
分布性
? 既然是分布式系统，最显著的特点肯定就是分布性，从简单来看，如果我们做的是个电商项目，整个项目会分成不同的功能，专业点就不同的微服务，比如用户微服务，产品微服务， 订单微服务，这些服务部署在不同的 tomcat 中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点， 这是第一个特性
对等性
? 对等性是分布式设计的一个目标，还是以电商网站为例，来说明下什么是对等性，要完成一 个分布式的系统架构，肯定不是简单的把一个大的单一系统拆分成一个个微服务，然后部署 在不同的服务器集群就够了，其中拆分完成的每一个微服务都有可能发现问题，而导致整个电商网站出现功能的丢失。
? 比如订单服务，为了防止订单服务出现问题，一般情况需要有一个备份，在订单服务出现问 题的时候能顶替原来的订单服务。
? 这就要求这两个（或者 2 个以上）订单服务完全是对等的，功能完全是一致的，其实这就是一种服务副本的冗余。
? 还一种是数据副本的冗余，比如数据库，缓存等，都和上面说的订单服务一样，为了安全考 虑需要有完全一样的备份存在，这就是对等性的意思。
并发性
? 并发性其实对我们来说并不陌生，在学习多线程的时候已经或多或少学习过，多线程是并发的基础。
? 但现在我们要接触的不是多线程的角度，而是更高一层，从多进程，多 JVM 的角度，例如在一个分布式系统中的多个节点，可能会并发地操作一些共享资源，如何准确并高效的协调 分布式并发操作。
缺乏全局时钟
? 在分布式系统中，节点是可能反正任意位置的，而每个位置，每个节点都有自己的时间系统，因此在分布式系统中，很难定义两个事务纠结谁先谁后，原因就是因为缺乏一个全局的时钟序列进行控制，当然，现在这已经不是什么大问题了，已经有大把的时间服务器给系统调用
故障随时会发生
? 任何一个节点都可能出现停电，死机等现象，服务器集群越多，出现故障的可能性就越大， 随着集群数目的增加，出现故障甚至都会成为一种常态，怎么样保证在系统出现故障，而系统还是正常的访问者是作为系统架构师应该考虑的
大型网站架构图
? 知道什么是分布式系统，接下来具体来看下大型网站架构图，首先整个架构分成很多个层，应用层，服务层，基础设施层与数据服务层，每一层都由若干节点组成，这是典型的分布式架构
? 那么 zookeeper 在其中又是扮演什么角色呢，如果可以把 zk 扮演成交警的角色，而各个节点就是马路上的各种汽车（汽车，公交车），为了保证整个交通（系统）的可用性，zookeeper必须知道每一节点的健康状态（公交车是否出了问题，要派新的公交【服务注册与发现】），公路在上下班高峰是否拥堵，在某一条很窄的路上只允许单独一个方向的汽车通过【分布式锁】。
? 如果交通警察是交通系统的指挥官，而 zookeeper 就是各个节点组成分布式系统的指挥官。
分布式系统协调“方法论”
分布式系统带来的问题
? 如果把分布式系统和平时的交通系统进行对比，哪怕再稳健的交通系统也会有交通事故，分布式系统也有很多需要攻克的问题，比如：通讯异常，网络分区，三态，节点故障等。
通信异常
? 通讯异常其实就是网络异常，网络系统本身是不可靠的，由于分布式系统需要通过网络进行数据传输，网络光纤，路由器等硬件难免出现问题。只要网络出现问题，也就会影响消息的发送与接受过程，因此数据消息的丢失或者延长就会变得非常普遍。
网络分区
? 网络分区，其实就是脑裂现象，本来有一个交通警察，来管理整个片区的交通情况，一切井然有序，突然出现了停电，或者出现地震等自然灾难，某些道路接受不到交通警察的指令，可能在这种情况下，会出现一个零时工，片警零时来指挥交通。
? 但注意，原来的交通警察其实还在，只是通讯系统中断了，这时候就会出现问题了，在同一个片区的道路上有不同人在指挥，这样必然引擎交通的阻塞混乱。
? 这种由于种种问题导致同一个区域（分布式集群）有两个相互冲突的负责人的时候就会出现这种精神分裂的情况，在这里称为脑裂，也叫网络分区。
三态
? 三态是什么？三态其实就是成功，与失败以外的第三种状态，当然，肯定不叫变态，而叫超时态。
? 在一个 jvm 中，应用程序调用一个方法函数后会得到一个明确的相应，要么成功，要么失败， 而在分布式系统中，虽然绝大多数情况下能够接受到成功或者失败的相应，但一旦网络出现异常，就非常有可能出现超时，当出现这样的超时现象，网络通讯的发起方，是无法确定请求是否成功处理的。
节点故障
? 节点故障在分布式系统下是比较常见的问题，指的是组成服务器集群的节点会出现的宕机或“僵死”的现象，这种现象经常会发生。
CAP 理论
? 前面花费了很大的篇幅来了解分布式的特点以及会碰到很多会让人头疼的问题，这些问题肯定会有一定的理论思想来解决问题的。
? 接下来花点时间来谈谈这些理论，其中 CAP 和 BASE 理论是基础，也是面试的时候经常会问到的
? CAP 其实就是一致性，可用性，分区容错性这三个词的缩写
一致性
? 一致性是事务 ACID 的一个特性【原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）】
? 这里讲的一致性其实大同小异，只是现在考虑的是分布式环境中，还是不单一的数据库。
? 在分布式系统中，一致性是数据在多个副本之间是否能够保证一致的特性，这里说的一致性和前面说的对等性其实差不多。如果能够在分布式系统中针对某一个数据项的变更成功执行后，所有用户都可以马上读取到最新的值，那么这样的系统就被认为具有【强一致性】
可用性
? 可用性指系统提供服务必须一直处于可用状态，对于用户的操作请求总是能够在有限的时间内访问结果。
? 这里的重点是**【有限的时间】**和【返回结果】
? 为了做到有限的**时间需要用到缓存，需要用到负载，**这个时候服务器增加的节点是为性能考虑；
? 为了返回结果，需要考虑服务器主备，当主节点出现问题的时候需要备份的节点能最快的顶替上来，千万不能出现 OutOfMemory 或者其他 500，404 错误，否则这样的系统我们会认为是不可用的。
分区容错性
? 分布式系统在遇到任何网络分区故障的时候，仍然需要能够对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。不能出现脑裂的情况
具体描述
? CAP 理论具体描述：
? 一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能 同时满足其中的两项
? 不可能把所有应用全部放到一个节点上，因此架构师的精力往往就花在怎么样根据业务场景在 A 和 C 直接寻求平衡。
BASE 理论
? 根据前面的 CAP 理论，架构师应该从一致性和可用性之间找平衡，系统短时间完全不可用肯定是不允许的，那么根据 CAP 理论，在分布式环境下必然也无法做到强一致性。
? BASE 理论：即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性
? BASE是Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）的简写。BASE是对CAP中一致性和可用性的一个权衡，核心思想是即使无法做到强一致性，但系统要达到最终一致性。
Basically Avaliable 基本可用
? 当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”；
? e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理；
Soft state 软状态
? 其实就是前面讲到的三态,既允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性；
? e.g：12306 网站卖火车票，请求会进入排队队列；
Eventually consistent 最终一致性
? 所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态；
? e.g：理财产品首页充值总金额短时不一致；
一致性协议
? 为了解决分布式一致性问题，涌现了一大批经典的一致性协议和算法，最有名的有二阶段提交协议、三阶段提交协议和Paxos算法。
? 当一个事务操作需要跨越多个分布式节点时，为了保持事务处理的ACID特性，就需要引入一个“协调者”的组件来统一调度所有分布式节点的执行，这些被调度的分布式节点则称为“参与者”，协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。
? 基于这种思想，衍生出了二阶段和三阶段提交协议。
2PC二阶段协议
? 2PC是Two-Phase Commit的缩写，目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。
? 顾名思义，二阶段提交协议是将事务的提交过程分成两个阶段来进行处理
阶段一：提交事务请求
? 阶段一也被称为“投票阶段”。即个参与者投票表明是否需要继续执行接下去的事务提交操作。
阶段二：执行事务提交
? 在阶段二中，协调者会根据各参与者反馈的情况来决定最终是否进行事务提交
二阶段提交协议优缺点
? 优点：原理简单，实现方便
? 缺点：同步阻塞、单点问题、数据不一致
? 同步阻塞：各参与者都需要等待其他参与者的响应，期间什么都做不了
? 单点问题：协调者有明显的单点问题
? 数据不一致：协调者发送部分节点commit指令后挂了，数据出现不一致
3PC三阶段协议
? 2PC在运行中存在同步阻塞、协调者单点问题、数据不一致的问题，因此在其基础上进行了改进，提出了三阶段协议。
? 3PC，是Three-Phase Commit的缩写，是2PC的改进版
- 阶段一：CanCommit
- 阶段二：PreCommit
- 阶段三：doCommit
? 与两阶段提交不同的是，三阶段提交有两个改动点
? 1、引入超时机制。同时在协调者和参与者中都引入超时机制。
? 2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
2PC和3PC的区别
? 相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
? 了解了2PC和3PC后，两者都无法彻底解决分布式一致性问题。
Paxos算法
? Paxos是一种基于消息传递且具有高度容错性的一致性算法，是目前公认的解决分布式一致性问题的最有效的算法之一。
算法陈述：
阶段一：
1、Proposer选择一个提案编号Mn，然后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。
2、如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的所有Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于Mn的提案。举个例子，假定一个Acceptor已经响应过的所有Prepare请求对应的提案编号分别是1、2…、5和7，那么该Acceptor在接收到一个编号为8的Prepare请求后，就会将编号为7的提案作为响应反馈给Proposer。
阶段二：
1、如果Proposer收到来自半数以上的Acceptor对于其发出的编号为Mn的Prepare请求的响应，那么它就会发送一个针对[Mn，Vn]提案的Accept请求给Acceptor。注意，Vn的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么它就是任意值。
2、如果Acceptor收到这个针对[Mn，Vn]提案的Accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求做出响应，它就可以通过这个题案。
Zookeeper 简介
? zookeeper是由雅虎创建，zookeeper并没有直接采用Paxos算法，而是采用了一种被称为ZAB（zookeeper Atomic Broadcast）的一致性协议。是 Google 的 Chubby 一个开源的实现，也是 Hadoop 和 Hbase 的重要组件。
? zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
zookeeper基本概念
集群角色
? Leader：Leader服务器为客户端提供读写服务
? Follower：Follower为客户端提供读服务
? Observer：Observer为客户端提供读服务，不参与选举Leader，不参与事务投票，不影响写性能提高集群的读性能。
会话（Session）
? Session是指客户端会话，是客户端连接服务端的一个TCP长连接。服务端的Watch事件通知也是通过该TCP连接。
数据节点（Znode）
? zookeeper将所有的数据存储在内存中，数据模型是一棵树（Znode Tree），由斜杆进行分割的路径，就是一个Znode，每个Znode上都会保存自己的数据内容，同时还会保存一些列的属性信息。
? 在zookeeper中，Znode分为持久节点和临时节点，持久节点是指一旦创建，除非主动删除，否则这个Znode会一直在Zookeeper中，临时节点它的生命周期是跟会话绑定，一旦客户端会话失效，临时节点将会删除。另外，zookeeper可以为每个节点添加SEQUENTIAL属性，一旦有这个属性，那么节点就是一个有序节点。
版本
? zookeeper会对每一个Znode维护一个Stat的数据结构，Stat中记录了Znode的三个数据版本，分别是version（当前Znode的版本）、cversion（当前Znode子节点的版本）和aversion（当前Znode的ACL版本）
Watcher
? Watcher（事件监听器），zookeeper允许用户在指定节点上注册watcher，并且在一些特定事件触发的时候，zookeeper服务端会将事件通知到感兴趣的客户端上去，该机制是zookeeper实现分布式协调服务的重要特性
ACL
? zookeeper采用ACL（Access Control Lists）策略来进行权限控制
-
CREATE：创建子节点的权限
-
READ：获取节点数据和子节点列表的权限
-
WRITE：更新节点的数据权限
-
DELETE：删除子节点的权限
-
ADMIN：设置节点ACL的权限
ZAB协议
? ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为zookeeper设计的崩溃可恢复的原子消息广播算法。
? zookeeper服务器数据状态的事务请求的处理方式：
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader，其他的服务器就是Follower。Leader服务器负责将一个客户端事务请求转换成 一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
ZAB基本模式：
? 1、崩溃恢复，Leader选举
? 2、消息广播，事务消息
? 注意: 如果集群中其他机器接收到客户端的事务请求，那么这些非Leader服务器首先将这个事务请求转发给Leader服务器。
消息广播
消息广播二阶段提交过程要点：
? 1、所有Follower要么正常反馈事务Proposal要么抛弃
? 2、Leader只要有过半数的Follower反馈了ack就进行事务提交，不要等待所有Follower都反馈ack
? 3、整个消息广播过程是具有FIFO特性的，能够保证消息提议的发送和接收的顺序性
? 4、Leader会为事务Proposal分配一个全局单调递增的唯一ID即ZXID
? 5、消息广播时，Leader会为每一个Follower分配一个单独队列，将需要广播的Proposal放入队列
? 6、每一个Follower接收到Proposal后，会以事务日志的方式写入到本地磁盘，写入磁盘成功后反馈ack给Leader
? 7、Leader收到半数ack反馈后，广播一个Commit消息给所有Follower，此时Leader完成事务提交，Follower收到Commit消息后进行事务提交。
崩溃恢复
崩溃恢复模式开启的条件：
Leader出现崩溃或者网络原因导致Leader失去了与过半Follower的联系。
ZAB协议要确保两点：
? 1、ZAB协议需要确保那些已经在Leader服务器上提交（commit）的事务最终被所有的服务器提交
? 2、ZAB协议需要确保丢弃那些只在Leader上被提出的事务(只是被提出还没有被提交)
Leader选举算法：
确保提交已经被Leader提交的事务，丢弃只被提出的事务，如果让Leader选择算法能够保证新选举出来的Leader拥有集群中所有机器最高编号（ZXID最大），那么一定能保证新Leader一定具有所有已经提交的提案。
数据同步
新Leader会为每一个Follower准备一个队列，并将那些没有被各Follower同步的事务以Proposal消息的形式逐个发送给Follower，并在每一个Proposal消息后面紧接着再发送一个Commit消息，标识该事务已经被提交。等所有Follower都从Leader同步过来后，Leader就会将该Follower加入到真正可用的Follower列表并开始之后的流程。
? ZAB如何处理被丢弃的事务Proposal？
? ZXID设计，ZXID是一个64位数字，低32位是一个单调递增的计算器，每一个新增的事务请求低32位都会+1,高32位代表Leader周期epoch编号，每当选举产生一个新的Leader，就会从这个Leader上取出本地日志中最大的事务Proposal的ZXID，并从ZXID解析出对应的epoch值，然后再对其进行加1操作。这个就是新Leader的epoch值。并将低32位设置为0.(整个zxid还是变大了)
? 通过zxid的大小直接确定。zxid的编码方式为高32位为epoch（即纪元，可以理解为代），低32位为每个proposal顺序递增的数字。每次变换一个leader，则epoch加一，可以理解为改朝换代了，新朝代的zxid必然比旧朝代的zxid大，新代的leader可以要求将旧朝代的proposal清除。
为什么要学习 zookeeper
互联网架构师必备技能
高端岗位必考察的知识点
zk 面试问题
Zookeeper 是什么框架 分布式服务框架
应用场景
Paxos 算法& Zookeeper 使用协议
选举算法和流程
Zookeeper 有哪几种节点类型 持久节点/临时节点/顺序节点
Zookeeper 对节点的 watch 监听通知是永久的吗？不是,是一次性的,目的是为了给服务器减压
部署方式？集群中的机器角色都有哪些？集群最少要几台机器 Leader Follower Observer
集群如果有 3 台机器，挂掉一台集群还能工作吗？挂掉两台呢？
集群支持动态添加机器吗？