zookeeper概要、协议、应用场景

1. zookeeper产生背景：

​ zookeeper是为了解决分布式系统一致性的问题产生的，其使用了ZAB协议(Zookeeper Atomic Broadcast zookeeper原理广播协议)

项目从单体到分布式转变之后，将会产生多个节点之间协同的问题。

1. 每天的定时任务由谁哪个节点来执行？
2. RPC调用时的服务发现?
3. 如何保证并发请求的幂等
4. …

这些问题可以统一归纳为多节点协调问题，如果靠节点自身进行协调这是非常不可靠的，性能上也不可取。必须由一个独立的服务做协调工作，它必须可靠，而且保证性能。

分布式系统中的进程通信有两种选择：直接通过⽹络进⾏信息交换， 或读写某些共享存储。

ZooKeeper使⽤共享存储模型来实现应⽤间的协作和 同步原语。对于共享存储本⾝，又需要在进程和存储间进⾏⽹络通信。我们强调⽹络通信的重要性，因为它是分布式系统中并发设计的基础。

ZAB协议原理

分布式系统一致性算法应用于系统软件实现集群保持每个节点数据的同步性。保持我们的集群中每个节点的数据的一致性问题。

常用分布式系统一致性算法：raf协议、zab协议、paxos协议。

zookeeper使用主备模型架构来保持集群中各个节点的数据一致性，使用一个单节点(leader节点)来接受处理客户端的事务请求，并通过zab协议将数据变更以事务proposal的形式广播给其他子节点（follower）

zookeeper有两种运行状态：1. 崩溃恢复 2. 消息广播

崩溃恢复：

​ 服务启动或者宕机重启会进行选举出新的leader同时leader和过半节点完成数据状态同步后会进行正常的消息广播模式。

1、选择保证数据一致

• ZAB协议需要确保事务leade处理成功,则在所有机器都应该被处理成功(这里处理成功是指提出事务和commit都完成)

• ZAB协议需要确保丢弃只在leader节点提出的事务

  这两种情况可以使用ZXID实现 只要选举出来的具有最高的ZXID编号的，可以保证选举出来的leader一定具有所有已经提交的提案。同时也省去了leader去提交和丢弃提案的步骤。

2、数据同步

选举完成的leader会将自己提交的提案中没有被其他follower节点同步的提案以消息的形式发送到其对应的队列中，follower消费消息进行数据同步 并进行ack确认接收commit提交。类似于正常的消息广播

消息广播模式：

leader节点将客户事务提交转换成一个Proposal并分发给集群所有fllower节点，超过半数的节点提供给leader正确反馈，leader节点会再次向所有Follower服务器分发commit消息将前一个proposal进行提交。类似于现代民主投票

数据（广播协议）之间同步采用: 2pc两阶段提交协议 同时使用FIFO顺序的TCP协议保证消息发送和接受的顺序性

2. zookeeper概要

ZooKeeper是用于分布式应用程序的协调服务。它公开了一组简单的API，分布式应用程序可以基于这些API用于同步，节点状态、配置等信息、服务注册等信息。其由JAVA编写，支持JAVA 和C两种语言的客户端。ZooKeeper顾名思意：动物园管理员

2.1设计模式来理解

ZK是一个基于观察者模式设计的分布式服务管理框架，

它负责存储和管理大家都关心的数据(集群下数据会保持一致性)，

然后接受观察者的注册(watch机制)，

一旦这些数据的状态发生变化，Zookeeper就将负责通知watch已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式

2.2 一句话

zookeeper=类似unix文件系统+通知机制+Znode节点

作用：服务注册+分布式系统的一致性通知协调

3. 数据结构 - znode 节点

zookeeper 中数据基本单元叫节点，节点之下可包含子节点，最后以树级方式呈现。每个节点拥有唯一的路径path。客户端基于PATH上传节点数据，zookeeper 收到后会实时通知对该路径进行监听的客户端。

（ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。）

4. 特点

1. Zookeeper：一个领导者（leader），多个跟随者（follower）组成的集群。
2. Leader负责进行投票的发起和决议，更新系统状态(写数据)
3. Follower用于接收客户请求并向客户端返回结果（读数据），在选举Leader过程中参与投票
4. 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
5. 全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的。
6. 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行。
7. 数据更新原子性，一次数据更新要么成功，要么失败。
8. 实时性，在一定时间范围内，client能读到最新数据。

5. 应用场景

提供的服务包括：统一命名服务dubbo注册中心、统一配置管理(zk实现的配置中心)、统一集群管理、服务器节点动态上下线、软负载均衡等。

5.1 统一命名服务（Name Service如Dubbo服务注册中心)

**命名服务是将一个名称映射到与该名称有关联的一些信息的服务。**电话目录是将人的名字映射到其电话号码的一个名称服务。同样，DNS 服务也是一个名称服务，它将一个域名映射到一个 IP 地址。在分布式系统中，您可能想跟踪哪些服务器或服务在运行，并通过名称查看其状态。ZooKeeper 暴露了一个简单的接口来完成此工作。也可以将名称服务扩展到组成员服务，这样就可以获得与正在查找其名称的实体有关联的组的信息。

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。

在Dubbo实现中：服务提供者在启动的时候，向ZK上的指定节点/dubbo/$serviceName/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。

1. 类似于域名与ip之间对应关系，ip不容易记住，而域名容易记住。
2. 通过名称来获取资源或服务的地址，提供者等信息。

一句话总结：path就是命名服务，客户端能够根据指定节点的名字来获取资源或者服务地址，然后进行下一步操作

5.2 统一配置管理（Configuration Management如淘宝开源配置管理框架Diamond）

在大型的分布式系统中，为了服务海量的请求，同一个应用常常需要多个实例。如果存在配置更新的需求，常常需要逐台更新，给运维增加了很大的负担同时带来一定的风险(配置会存在不一致的窗口期，或者个别节点忘记更新)。zookeeper可以用来做集中的配置管理，存储在zookeeper集群中的配置，如果发生变更会主动推送到连接配置中心的应用节点，实现一处更新处处更新的效果。

现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。

分布式环境下，配置文件管理和同步是一个常见问题。

1. 一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。
2. 对配置文件修改后，希望能够快速同步到各个节点上。

配置管理可交由ZooKeeper实现。

1. 可将配置信息写入ZooKeeper上的一个Znode。
2. 各个节点监听这个Znode。
3. 一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

5.3 统一集群管理

分布式环境中，实时掌握每个节点的状态是必要的。

1. 可根据节点实时状态做出一些调整。
2. 可交由ZooKeeper实现。
   1. 可将节点信息写入ZooKeeper上的一个Znode。
   2. 监听这个Znode可获取它的实时状态变化。
3. 典型应用
   1. HBase中Master状态监控与选举。

5.4 服务器动态上下线

利用zk临时节点实现监听服务器上下线。

5.5 软负载均衡

5.6 分布式消息同步和协调机制

5.7 总结

Zoopkeeper提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，

并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型，作为分布式系统的沟通调度桥梁