分布式协调服务-zookeeper

分布式协调服务-zookeeper

最近新型冠状病毒引发的肺炎疫情席卷全国，虽然不像非典时期致死率那么高，其传染性却有过之而无不及；这个时候大家隔离自己在家办公减少外出就算是给国家做贡献了。实体行业尤其是中小企业影响甚大，最近弟弟所在的影楼已经开始变相劝退了。。。我所在的单位属于传统软件行业，公司指示所有员工尽量减少外出，在家远程办公，每天健康报备，外出报备。作为软件行业来说，最近的电商，小视频甚是火热，现在软件开发也进入了微服务时代，采用分布式部署，所带来的就是应用程序的服务解耦，再也不是体大若鹏牵一发而动全身甚至导致系统出了问题不敢动的时代。而分布式部署也会带来新的问题，分布式事务，服务注册与发现，分布式id等等问题。
最近在学习分布式开发的相关课程，其所囊括的知识实在是相当多，至今也只是有了一个大概的轮廓，不能说是完全掌握。而对于微服务时代最主要的一个部分就是服务的注册与发现，这样各服务才能协调工作完成系统所需的功能。下面来介绍一下服务注册与发现的核心组件：zookeeper。
zookeeper实际上可以理解为一个map，在map的基础上为其增加了诸多功能，网络访问，leader选举。它的数据结构是类unix文件系统树结构，每个节点都不重复，且能够存储数据，所以zookeeper也可以用来当作配置中心。当下很多流行的中间件均采用zookeeper作为注册中心及leader选举组件，如：hadoop，dubbo，kafka等等，其本身就是hadoop下的一个子项目。

Zookeeper功能：

配置管理

分布式服务程序很多时候需要做一些配置性的东西，我们不可能把一些数据库连接属性，线程信息等数据都写在程序里，那样当我们需要改的时候每次都需要修改程序代码，这非常不方便。所以这个时候我们就会采用外置配置，在分布式服务中则采用配置中心来管理我们的配置信息。zookeeper的持久节点就可以用来存储配置信息，同时zookeeper的ZAB协议能够帮我们保持配置的一致性。

名字服务

用的不多，不做太多介绍，敬请谅解！

分布式锁

在分布式服务应用当中或者说在多节点部署的应用系统中，我们通常需要访问同一资源，这个时候我们需要分布式锁来帮我们协调访问。Zookeeper作为分布式锁使用的是临时顺序节点，这样也避免了惊群效应。

集群管理

在zookeeper中，进行服务注册，实际上就是在zookeeper中创建了一个znode节点，该节点存储了该服务的IP、端口、调用方式(协议、序列化方式)等。该节点承担着最重要的职责，它由服务提供者(发布服务时)创建，以供服务消费者获取节点中的信息，从而定位到服务提供者真正网络拓扑位置以及得知如何调用。大体过程如下：

1. 服务提供者启动时，会将其服务名称，ip地址注册到配置中心。
2. 服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。
3. 当服务提供者的某台服务器宕机或下线时，相应的ip会从服务提供者IP列表中移除。同时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。
4. 当某个服务的所有服务器都下线了，那么这个服务也就下线了。
5. 同样，当服务提供者的某台服务器上线时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。
6. 服务提供方可以根据服务消费者的数量来作为服务下线的依据。

Zookeeper节点类型

1. PERSISTENT 持久化节点: 所谓持久节点，是指在节点创建后，就一直存在，直到 有删除操作来主动清除这个节点。否则不会因为创建该节点的客户端会话失效而消失。

2. PERSISTENT_SEQUENTIAL 持久顺序节点：这类节点的基本特性和上面的节点类 型是一致的。额外的特性是，在 ZK 中，每个父节点会为他的第一级子节点维护一份时序， 会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属 性，那么在创建节点过程中，ZK 会自动为给定节点名加上一个数字后缀，作为新的节点名。 这个数字后缀的范围是整型的最大值。 在创建节点的时候只需要传入节点 “/test_”，这样 之后，zookeeper 自动会给”test_”后面补充数字。

3. EPHEMERAL 临时节点：和持久节点不同的是，临时节点的生命周期和客户端会 话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提 到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。 这里还要注意一件事，就是当你客户端会话失效后，所产生的节点也不是一下子就消失 了，也要过一段时间，大概是 10 秒以内，可以试一下，本机操作生成节点，在服务器端用 命令来查看当前的节点数目，你会发现客户端已经 stop，但是产生的节点还在。

4. EPHEMERAL_SEQUENTIAL 临时自动编号节点：此节点是属于临时节点，不过带 有顺序，客户端会话结束节点就消失。

ZAB协议

Zab协议 的全称是 Zookeeper Atomic Broadcast （Zookeeper原子广播）。
Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。

1. Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。

Paxos算法目前的应用实践有谷歌的kubernetes中etcd中，etcd同样可以作为注册服务中心使用。zab协议可以算是paxos的简化实现版本。

2. 在Zookeeper中主要依赖Zab协议来实现数据一致性，基于该协议，zk实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性。

Leader选举

1. 服务器状态: 服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。

   LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
　　FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
　　LEADING：领导者状态。表明当前服务器角色是Leader。
　　OBSERVING：观察者状态。表明当前服务器角色是Observer。

2. 投票数据结构
   　　每个投票中包含了两个最基本的信息，所推举服务器的SID和ZXID，投票（Vote）在Zookeeper中包含字段如下

   id：被推举的Leader的SID。

　　zxid：被推举的Leader事务ID。

　　electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作。

　　peerEpoch：被推举的Leader的epoch。

　　state：当前服务器的状态。
```　　

简述选举过程

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

1. 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。 
2. 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。 
3. 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。 
4. 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。 
5. 服务器5启动，后面的逻辑同服务器4成为小弟。

流程如图

现在很多公司作为欸服务用的都是顶级封装框架SpringCloud，它为我们封装了服务治理相关的一应组件，其中注册中心Eureka等同于zookeeper，当然我们一样可以用Zookeeper来替换SpringCloud中的注册中心。但是如果我们使用SpringCloud来构建微服务那还是使用框架内封装的组件比较好，毕竟它不仅仅为我们提供了服务注册与发现，还提供了负载均衡，服务容错，网关服务。理解zookeeper对我们理解分布式应用开发至关重要。