Zookeeper 集群部署的那些事儿，消息队列 rabbitmq 面试
额。。。。， &*$% 淘气！
ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务。
ZooKeeper 本质上是一个分布式的小文件存储系统。提供类似于文件系统目录树方式的数据存储，并且可以对书中的节点进行有效管理。从而用来维护和监控存储的数据的状态变化，通过监控这些数据状态的变化，实现基于数据的集群管理。
ZooKeeper 运行模式有三种：单机模式、伪集群模式、集群模式
单机模式： ZooKeeper 只运行一台服务器上面，这种模式一般用于开发测试环境，用于节省机器数量，加上开发调试不需要特别好的稳定性
伪集群模式： 这是一种特殊的集群模式，即一台服务器上面部署多个 ZooKeeper 实例，当然这个时候就需要你这台服务器性能比较好。在这种情况下，我们需要通过不同的端口来启动 ZooKeeper 实例，以此来通过集群的方式对外提供服务。
这种模式下，我们只需要修改 zoo.cfg 下的同一个服务器不同端口连接地址即可
server.1=ip1:2888:3888
server.2=ip1:2889:3889
server.3=ip1:2890:3890
集群模式： Zookeeper 集群 运行在一组机器上，一般三台以上的机器就可以组成集群了，组成 ZooKeeper 集群的每一台机器都会在内存中维护当前服务的状态，机器之间也会互相保持通信。
只要集群中过半的服务存活，就能正常对外提供服务，如果说当我们的 leader 挂掉了，在选举过程中是无法提供服务的，直到 leader 选举完成！
这种模式下，我们只需要修改 zoo.cfg 下的不同服务器的连接地址即可
server.1=ip1:2888:3888
server.2=ip2:2888:3888
server.3=ip3:2888:3888
ZooKeeper 实现了高性能，高可靠性和有序的访问。高性能保证了 ZooKeeper 能应用在大型的分布式系统上，高可靠性保证它不会由于单一节点的故障而造成任何问题。有序的访问能保证客户端可以实现较为复杂的同步操作。
负载均衡
这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，来达到高可用。
命名服务
在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或者服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址、远程对象等这些我们可以统称为 Name，其中比较常见的就是一些分布式服务框架中的服务地址列表。通过调用 ZooKeeper 提供创建节点的 API，能够很容易创建一个全局唯一的 Path，这个 Path 可以作为一个名称。
阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务，维护全局的服务地址列表，点击这里查看 Dubbo 开源项目。
分布式协调
ZooKeeper 中特有的 Watcher 注册与异步通知机制，能够实现分布式环境下不同系统之间的通知与协调，实现对数据变更的及时处理，使用方法通常是不同系统都对 ZooKeeper 同一个 Znode 进行注册，监听 Znode 的变化。
如果其中一个系统更新了 Znode，那么另外系统也能够收到通知，并做出相应的处理。
集群管理
集群管理主要是包含其中两点：服务状态监听(退出和加入)、master 选举。
服务状态监听： 所有机器在父目录下创建临时目录节点，监听父目录节点的子节点变化消息，如果有机器挂掉，这个机器与 ZooKeeper 的连接断开，这个创建的临时目录节点就会被删除，其他机器收到消息，某个服务下的节点目录被删除，就知道这个某个节点宕机。
如果有新的机器或者服务加入，会在该父目录节点下创建一个临时子节点，所有服务就会收到通知，有新的目录产生。
master 选举： master 选举是 ZooKeeper 中最为经典的应用场景了，在分布式环境中，相同的业务应用分布在不同的机器上，有的业务逻辑，通常只需要其中一台服务完成，然后其他服务共享，这样可以大幅度减少重复劳动，提高服务性能，比如 HDFS 中 Active NameNode 的选举。
通常情况下，我们可以选择常见的关系型数据库中的主键特性来实现，在成为 Master 的机器都想数据库中插入一条相同主键 ID 的记录，数据库会帮我们进行主键冲突检查，也就是说，只有一台机器能够插入成功，那么我们就认为向数据库中插入数据的机器就是 Master
但是当我们的 Master 机器挂掉了，那么谁能够告诉我们 Master 挂掉了，关系型数据库是无法通知我们这个事情的，但是 ZooKeeper 可以做到。
ZooKeeper 能够保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，ZooKeeper 将会保证客户端无法创建一个已经存在的数据单元节点。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易的在分布式环境中进行 Master 选举了，成功创建该节点的客户端所在的机器就成为了 Master，同时企业没有成功创建该节点的客户端，都会在该节点上注册一个子节点变更的 Watcher，用于监控当前的 Master 机器是否存活，一旦发现当前的 Master 挂了，那么其他客户端将会重新进行 Master 选举，这样就实现了 Master 的动态选举。
一个 ZooKeeper 集群通常由一组机器组成，一般是 3 台以上就可以组成一个可用的 ZooKeeper 集群了。只要集群中存在超过一半的机器能够正常工作，那么 ZooKeeper 集群就能正常对外提供服务。
在这里，有一个误区，就是为了让 ZooKeeper 群能够正确的选举出 leader 我们必须要把 ZooKeeper 集群服务器的数量设置为奇数，其实任意台的 ZooKeeper 都可以正常选举出 Leader 和运行。
关于集群服务数量中，ZooKeeper 官方也给出了奇数的建议，而且基于 ZooKeeper 过半以上存活服务可用 的特性，如果 ZooKeeper 需要对外提供服务，那么至少要保证有过半存活的机器能够正常工作，如果我们想要搭建一台允许挂点一定数量(N)的集群机器，那我们至少要部署 2*N+1台服务器来搭建 ZooKeeper 集群。
容错率
从容错率来讲，我们要保证 过半以上存活的特性
如果我们允许挂掉 1 台服务，那我们至少要搭建(2*1+1)台服务器，也是就 3 台服务器（3 的半数为 1.5，默认向下取整为 1，半数以上那就是 2）
如果我们允许挂掉 2 台服务，那我们至少要搭建(2*1+1)台服务器，也是就 5 台服务器（5 的半数为 2.5，默认向下取整为 2，半数以上那就是 3）
同样我们部署六台机器，那么我们遵循过半以上存活服务可用的特性，同样也只能挂掉 2 台服务器，因为如果挂掉 3 台，无法遵循服务过半的特性
因此，我们可以从上面条件中看到，对于一个由 6 台服务器构成的 ZooKeeper 集群来说，和一个用 5 台服务器构成的 ZooKeeper 集群，在容灾能力上没有任何的显著优势，所以 ZooKeeper 集群 通常会设置成奇数台服务器即可
下载地址：https://zookeeper.apache.org/releases.html
ZooKeeper 安装首先需要安装 JDK，ZooKeeper 的安装步骤在上一篇文章中介绍过，大家感兴趣的可以看一下：https://muxiaonong.blog.csdn.net/article/details/120543298
当我们将 conf 下的 zoo_sample.cfg 文件复制并重命名为 zoo.cfg 文件后，通过 vim zoo.cfg命令对这个文件进行修改：
The number of milliseconds of each tick
tickTime=2000
The number of ticks that the initial
synchronization phase can take
initLimit=10
The number of ticks that can pass between
sending a request and getting an acknowledgement
syncLimit=5
the directory where the snapshot is stored.
do not use /tmp for storage, /tmp here is just
example sakes.
dataDir=/tmp/zookeeper
the port at which the clients will connect
clientPort=2181
the maximum number of client connections.
increase this if you need to handle more clients
#maxClientCnxns=60
Be sure to read the maintenance section of the
administrator guide before turning on autopurge.
http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
Purge task interval in hours
Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1
Metrics Providers
https://prometheus.io Metrics Exporter
#metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
#metricsProvider.httpPort=7000
#metricsProvider.exportJvmInfo=true
server.1=192.168.5.129:2888:3888
server.2=192.168.5.130:2888:3888
server.3=192.168.5.131:2888:3888
tickTime： 客户端与服务端或者服务端和服务端之间维持心跳的时间间隔，每隔 tickTime 时间就会发送一个心跳，通过心跳不仅能够用来监听机器的工作状态，还可以通过心跳来控制 follower 和 Leader 的通信时间，默认情况下 FL（Follower 和 Leader）的会话通常是心跳间隔的两倍，单位为毫秒。
initLimit： 集群中的 follower 服务器与 Leader 服务器之间的初始连接时能容忍的最多心跳数量
syncLimit： 急群众的 follower 服务器与 leader 服务器之间的请求和回答最多能容忍的心跳数量
dataDir： 目录地址，用来存放 myid 信息和一些版本、日志、服务器唯一 ID 等信息
clientPort： 监听客户端连接的端口
server.n=127.0.0.1:2888:3888
n：代表的是一个数字，表示这个服务器的标号
127.0.0.1：IP 服务器地址
2888：ZooKeeper 服务器之间的通信端口
3888：Leader 选举的端口
两个需要修改的点：
修改的是目录结构（dataDir），不要用它默认的
添加 server.1 集群服务器配置信息
官方参考文档：https://zookeeper.apache.org/doc/r3.5.8/zookeeperStarted.html
在这里我们需要创建一个 myid 的文件，我们需要在 dataDir指定的目录下，手动创建这个目录。
创建命令：mkdir -p /tmp/zookeeper
然后在 myid 文件里面添加对应的 server.1 中的 “1” 这个数字，如下所示
[root@VM-0-7-centos zookeeper]# more myid
1
后面的机器，依次在 dataDir指定的目录下(/tmp/zookeeper)，创建 myid 文件，写上相应配置的数字，比如我们在zoo.cfg后面写的是 server.1，那么当前 myid 的文件就写一个数字 1 就可以了
server.1=192.168.5.129:2888:3888
server.2=192.168.5.130:2888:3888
server.3=192.168.5.131:2888:3888
还未添加个人签名 2021.11.08 加入
还未添加个人简介
评论