Zookeeper之设计原理

Zookeeper之设计原理

Apache ZooKeeper 是一个高可靠的分布式协调中间件。它是Google Chubby 的一个开源实现

Google Chubby 是谷歌的一个用来解决分布式一致性问题的组件，同时，也是粗粒度的分布式锁服务

一、分布式一致性问题

什么是分布式一致性问题呢？简单来说，就是在一个分布式系统中，有多个节点，每个节点都会提出一个请求，但是在所有节点中只能确定一个请求被通过。而这个通过是需要所有节点达成一致的结果，所以所谓的一致性就是在提出的所有请求中能够选出最终一个确定请求，并且这个请求选出来以后，所有的节点都要知道。 所以这时候就有人提出了各种协议，比如大名鼎鼎的Paxos

二、分布式锁锁服务

由于Chubby提供了一个粗粒度的分布式锁服务，但是Chubby 没有开源，所以雅虎公司基于Chubby的思想，开发了一个类似的分布式协调组件Zookeeper，后来捐赠给了Apache 。

所以，大家一定要了解，zookeeper并不是作为注册中心而设计的，他是作为分布式锁的一种设计。而注册中新知识他能够实现的功能而已。

三、Zookeeper设计猜想

在分布式架构中，任何的节点都不能以单点的方式存在，因此我们需要解决单点的问题，常见的单点问题的方式就是集群

集群需要满足哪些功能？

• 集群需要有主节点和从节点（也就是集群要有的角色）
• 集群要能做到数据同步，当主节点出现故障后，从节点能够顶替主节点继续工作，但是继续工作的前提是 数据必须要和主节点保持一致。
• 主节点挂了后，从节点如何代替称为主节点？是人工干预？还是自动选举

1、防止单点故障

• Leader 角色

  是整个zookeeper集群的核心，主要的的工作任务有两项

  • 事务请求的唯一调度和处理着，保证集群事务处理的顺序性
  • 集群内部各服务器的调度者

• Follower角色

  • 处理客户端非事务请求、转发事务请求给leader服务器
  • 参与事务请求Proposal的投票（需要半数以上服务器通过才能通知leader commit 数据；Leader发起的提案，需要Follower投票）
  • 参与Leader选举的投票

2、数据同步

根据上面的结果得出，要满足一个高性能的集群，最直观的想法是，每个节点都收到请求，并且每个节点的数据都必须保持一致。要实现各个节点的数据一致性，就势必要有一个leader及诶单负责协调和数据同步操作。因为如果这个的一个集群没有leader节点，每个节点都可以接受所有请求，那么这个集群的数据同步的复杂性是非常大的。

所以需要把事务型和非事务型数据的分开处理：

• 就是leader 节点可以处理事物和非事物型数据。
• 而Follower节点只能处理非事务型数据

Leader节点如何和其它节点保证数据一致性？并且要求是强一致性。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有2PC协议和3PC协议

• 关于2PC提交

  Two Phase Commitment Protocol，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理ACID特性，就需要引入一个“协调者”(TM)来统一协调所有分布式节点的执行逻辑，这些被调度的分布式节点称为AP。TM负责调度AP的行为，并最终决定这些AP是否要把事务真正进行提交；因为整个事务是分为两个阶段提交，所以叫2PC

  

  • 阶段一：提交事务请求（投票）

    “投票阶段”，即各参与者投票表明是否需要继续执行接下去的事务提交操作。

    • 事务询问

      协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应

    • 执行事务

      各个参与者节点执行事务操作，并将Undo 和Redo 信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面100%成功提交事务

    • 各个参与者向协调者反馈事务询问的响应

      如果各个参与者成功执行了事务操作，那么就反馈给参与者yes的响应，表示事务可以执行；如果参与者没有成功执行，就反馈给协调者no的响应，表示事务不可以执行，上面这个阶段有类似协调者组织各个参与者对一次事务操作的投票表态过程，因此2PC协议的第一个阶段称为 “投票阶段”，

  • 阶段二：执行事务提交

    这个阶段，协调者会根据参与者的反馈情况来决定最终是否进行事务提交操作，正常情况下包含两种可能

    • 执行事务
    • 中断事务

• Observer角色

  Observer 是 Zookeeper 3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色当了观察者的角色。

  观察Zookeeper 集群中的最新状态变化并将这些状态变化同步到 Observer 服务器上。Observer 的工作原理与 Follower 角色基本一致，而它的Follower 角色唯一的不同在于 Observer 不参与任何形式的投票，①包括事务请求Proposal 的投票 和 ②leader 选举的投票。简单来说，Observer 服务器只提供事务请求服务，通常在于不影响集群事务处理能力的前提下提升集群非事务处理的能力

3、leader选举

当Leader 挂了，需要从其他Follower 节点中选择一个新的节点进行处理，这个时候就需要涉及到Leader 选举

​ 通常Zookeeper 是由2n+1台server组成，每个server 都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。对于2n+1台server，只要有n+1台（大多数）server可用，整个系统保持可用。之所以要满足这样一个等式，是因为一个节点要称为集群的leader，需要有超过及全数过半的节点支持，整个设计到leader选举算法。同时也设计到事务请求的提交投票。

四、Zookeeper的安装部署

Linux安装jdk教程：https://blog.csdn.net/pdsu161530247/article/details/81582980

Zookeeper下载地址：http://www.apache.org/dyn/closer.cgi/zookeeper

Zookeeper安装教程：https://blog.csdn.net/qq_39938758/article/details/105589863

1、zk的可视化客户端

ZooViewer-master.zip

2、简单脚本操作

1. 启动ZK服务: bin/zkServer.sh start
2. 查看ZK服务状态: bin/zkServer.sh status
3. 停止ZK服务: bin/zkServer.sh stop
4. 重启ZK服务: bin/zkServer.sh restart
5. 连接服务器 zkCli.sh -timeout 0 -r -server ip:port