分布式专题-分布式协调服务01-初步认识Zookeeper

前言

分布式协调服务，我们主要讲四个方面

• 初步认识Zookeeper
• 了解Zookeeper的核心原理
• Zookeeper实践及与原理分析
• Zookeeper实践之配合注册中心完成RPC手写

本节我们就讲第一个部分 初步认识Zookeeper

从架构的发展说起

以电商架构为例，早期我们是单一的应用架构，随着互联网的快速发展和体量的不断增长，后端的架构通过垂直伸缩的方式很难达到我们期望的性能要求，同时投入产出比也非常大，同时普通 PC 的性能也越来越高，所以通过水平伸缩的方式来提升性能成为了主流。


在分布式架构下，当服务越来越多，规模越来越大时，对应的机器数量也越来越大，单靠人工来管理和维护服务及地址的配置地址信息会越来越困难，单点故障的问题也开始凸显出来，一旦服务路由或者负载均衡服务器宕机，依赖他的所有服务均将失效。

痛点：

• 协议地址的维护
• 负载均衡机制
• 服务动态上下线感知
• 临时节点下不能存在子节点

此时，需要一个能够动态注册和获取服务信息的地方。来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心，服务提供者在启动时，将其提供的服务名称、服务器地址注册到服务配置中心，服务消费者通过服务配置中心来获得需要调用的服务的机器列表。通过相应的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并通知相应的服务消费者，否则服务消费者就有可能因为调用到已经失效服务而发生错误，在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求道服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更（机器上线或者下线）。这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大大减轻了服务配置中心的压力

上图所示，当用户服务访问订单服务时，加入中间件，用来处理负载，转发，动态管理。

什么是Zookeeper？

zookeeper 是一个开源的分布式协调服务，由雅虎公司创建，是 google chubby 的开源实现。zookeeper 的设计目标是将哪些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集（由若干条指令组成的，完成一定功能的一个过程），并且以一些列简单一用的接口提供给用户使用

zookeeper用来做什么呢？
上图所示，orderService下暴露多个订单服务下接口地址。这样就能实现基于zookeeper的注册中心。

CAP问题
做zookeeper集群，leader-follower，完成高可用机制。

2pc（最终一致性来实现）

zookeeper节点问题

zookeeper 安装部署

环境部署

（2n-1台linux机器或者虚拟机:由于zookeeper的paxos算法要求半数以上存活则为可用，所以必须准备单数个服务器搭建环境）

有条件的同学，至少自备服务器三台。否则可以自行搭建至少三台服务器：

然后需要安装jdk，我使用的是jdk1.8

我使用的是Windows的操作系统，通过VMware虚拟机本地搭建了三台Linux（镜像使用的是Centos6.7）服务器，图上所示是通过xshell远程连接到了本地三台机器，虚拟机窗口就可以最小化了，然后就在xshell上操作就可以了~

Tips：
以上是我们安装zookeeper的前置条件，如果有不懂得的地方，可以留言给我，我会单独开一个小节专门讲如何搭建服务器，配置ip，挂载、配置本地yum源，如何通过xshell访问远程、文件上传，安装jdk、tomcat等常用软件等常规操作~

zookeeper安装&测试

zookeeper 有两种运行模式：集群模式和单机模式。

下载zookeeper安装包的官方地址

• 下载完成，通过 tar -zxvf 解压
• 修改配置文件
  zookeeper默认读取conf/zoo.cfg

• 启动
  如果没有配置环境变量，就在/bin/ 目录下启动zkServer.sh

sh zkServer.sh start

• 测试client

/bin/ 目录下启动zkCli.sh。连接远程

sh zkCli.sh

得到客户端操作窗口：

• 帮助
  遇事不决 先help ，看看都有哪些命令

• 命令测试

接下来我们做一些CRUD的操作，类似于Redis
首先创建一个节点

接下来，我们在此节点里再加一层节点

查看一下：

删除节点：
必须一层一层删除，由内向外删除

获得节点：

zookeeper节点特性

1. 同级节点唯一性

我们可以这样理解zookeeper的树形结构，类似于windows的目录结构，同一级下是不可能创建两个文件名相同、类型相同的文件

2. 临时节点和持久化节点

在客户端建立的会话周期中，创建的临时节点，会话结束以后会自动删除

我们刚才在zookeeper客户端命令窗口使用help的命令：

create [-s] [-e] path data acl

好的，我们现在就创建一个临时节点

我们断开client连接，测试一下，节点是否存在

稍等一下，zookeeper的心跳检测会有默认时间

证明以上结论成立
3. 有序节点的特性

create [-s] [-e] path data acl

好的，我们现在就创建一个有序节点

我们发现此节点在递增，我们查看一下

4. 临时节点下不能存在子节点

zookeeper集群搭建

1. 首先修改每个zoo.cfg配置文件
   
   我们在默认的配置文件上加上各个机器zookeeper的地址

## 默认的存放data的文件夹
dataDir= /tmp/zookeeper
## 默认端口号
clientPort=2181

## 集群配置
server.{id}={ip}:{port1}:{port2}

集群配置这里：

这里的配置我们说一下：
id：当前机器zookeeper的myid
ip：当前机器ip地址
port1：当前机器zookeeper与其他机器zookeeper通信的端口
port2：重新选举的端口

注意事项：端口我们可以自定义，但是不要与主机端口冲突

接下来，我们把每个机器的zookeeper的配置文件，都加上一样的上述内容
怎么配置id？
在配置文件里
dataDir= /tmp/zookeeper
我们找到/tmp目录，创建文件myid 内容就是上面提到的{id}

myid的内容就是1

然后把每个机器的myid都设置一遍，对应上配置文件的id即可

在每台 zookeeper 机器上，我们都需要在数据目录(dataDir)下创建一个 myid 文件，该文件只有一行内容，对应每台机器的 Server ID 数字；比如 server.1 的 myid 文件内容就是1。【必须确保每个服务器的 myid 文件中的数字不同，并且和自己所在机器的 zoo.cfg 中 server.id 的 id 值一致，id 的范围是 1~255】

2. 启动集群
   先关掉每台服务器的防火墙:

service iptables stop

首先在第一台机器启动，在zookeeper/bin目录下使用

tail -f zookeeper.out

就可以看日志了！发现报错

原因在于，集群模式是需要选举的，至少需要两台！

所以启动第二台服务器的zookeeper,看一下日志，没有报错了，第一台服务器也是没有报错！

3. 集群模式
我们现在启动第三台服务器的zookeeper

发现此zookeeper的模式为follower，原因很简单，我们之前已经成功启动了linux1和linux2 ，主节点一定在这两台之间，至于如何选举的，我们以后再说

linux1的模式为leader！

4. 节点数据同步测试

在这三台服务器的任意一台进入zookeeper的client命令行，我们创建一个新的节点，然后再另外一台zookeeper的client命令行查看，发现数据已经同步过来了！

• 在linux1 上创建 mytest节点
  
• 在linux2上查看节点
  

注册中心原理

服务发现-服务感知就是注册中心的原理，zookeeper怎么实现的呢？
现在有如下的场景：
比如订单服务orderService，此节点下可以对应每个独立的机器的ip地址
，然后现在有用户服务想要调用订单服务的接口，怎么办？

用户服务首先应该订阅zookeeper的orderservice
然后zookeeper会以事件通知的形式返回到用户服务，拿到相应的ip地址！

zookeeper客户端命令详解

zookeeper客户端命令详解

zookeeper常用命令

ACL命令用来控制节点访问权限：
常用ACL命令

Observer

只有监控作用，不涉及选举，所以就不影响性能开销

带 Observer 角色的集群

Observer：在不影响写性能的情况下扩展 zookeeper

本身 zookeeper 的集群性能已经很好了，但是如果超大量的客户端访问，就势必需要增加 zookeeper 集群的服务器数量，而随着服务器的增加，zookeeper 集群的写性能就会下降；zookeeper 中 znode 的变更需要半数及以上服务器投票通过，而随着机器的增加，由于网络消耗等原因必定会导致投票成本增加。也就导致性能下降的结果

事务请求

通常， 在 zookeeper 集群中，各个节点总共有三种角色，分别是：
leader，follower，observer

当客户端发送的是非事务请求，服务器无论是leader或是follower节点都可以处理，但是非事务请求一旦被follower接收，follower不能处理，只能交给leader来请求。

会话状态

客户端一旦连接不上超时，直接关闭

zookeeper应用场景

• 注册中心

• 配置中心
  

• 负载均衡

首先要知道机器的状态以及选举的master

比如我要做一个kafka集群，在zookeeper注册节点
kafka01
kafka02
kafka03
当我们每个节点启动以后，都往zookeeper注册，哪个节点先来，就选举为leader，当leader挂掉以后，zookeeper通过watcher来通知其他节点。然后zookeeper在剩余的kafka02和kafka03中再选举，这样就实现了负载均衡。

• 分布式锁

后记

zookeeper的常用命令

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