2024年Linux最新ZooKeeper运维——集群动态迁移与扩缩容（不停机+不丢失）

server.5的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792:observer

server.6 = 127.0.0.1:2693:3793

server.6的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792

server.6 = 127.0.0.1:2693:3793:observer

server.4、server.5、server.6分别启动，数据就可以从源集群同步到目的集群了，即使现在源集群有写操作，也可以实时同步。

• 如下是server.4作为源集群的Observer启动时的日志：

• server.4刚启动时，是一个LOOKING状态，就是在找Leader。

• 找到Leader以后，就变成了OBSERVING状态。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hXDEN6rq-1632664267904)(C:\我的坚果云\mymd\image\zk_observer1.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t7sErJxi-1632664267907)(C:\我的坚果云\mymd\image\zk_observer2.png)]

2、切换客户端zk地址

虽然server.4、server.5、server.6都是Observer，但是也可以对外提供服务。此时可以将连接目的集群的客户端，如qconf_agent、kafka中的zk地址修改为目的集群的。

3、修改目的集群配置

先将目的集群的配置observer相关的配置去掉，都修改为如下配置：

server.4 = 127.0.0.1:2691:3791

server.5 = 127.0.0.1:2692:3792

server.6 = 127.0.0.1:2693:3793

4、依次重启目的集群

目的集群的配置修改好了，还没有重启，此时依然是作为Observer在对外提供服务。

现在依次重启server.4、server.5，server.5成为目的集群的Leader，此时已经完全和源集群分离，立刻重启server.6，server.6作为Follower加入目的集群。

但是在目的集群重启Leader选举时，可能存在短暂的数据不一致，因为可能在server.5重启触发Leader选举时，server.6可能接收到写请求，依然转发给源Leader，所以server.6甚至是整个目的集群都尽快完成重启。

到这里基本就完成了集群的不停机动态迁移，观察一段时间目的集群的服务状态，如果正常，就可以把源集群停掉了。

这过程一旦出现问题，比如目的集群重启失败，立刻回滚第二步，然后查看目的集群的启动日志。

三、zk集群动态扩容

---

zk集群的扩容，对读请求来说是可以提升性能，但是对于写请求就未必是好事了，因为所有的写请求都需要Leader统一协调处理（两阶段提交），所以服务节点多了反而会降低写性能。

zk集群的扩容可以有两种形式，一种是扩容节点以Observer附庸在源集群上，另一种就是正常意义上扩容，给源集群加Follower节点。

依然用一台服务器搭建的伪集群演示。

1、Observer扩容

以Observer方式扩容，不参与源集群的投票和过半机制，依然可以一起加入到zk地址中对外提供服务，有如下几个优点：

• 提升源集群的读性能，对写性能影响很小。

• 可以将Observer部署在异地机房，读请求就近发送，降低延迟。

但是多多少少对写操作有一定影响，即Observer所在服务，处于无监管状态，无法确保数据都同步了，可能因为网络原因一些请求被丢弃等，需要对Observer进行监控。如果Observer部署在异地，写同步的延迟可能也会增加。

Observer扩容还有一个缺点，就是源集群的稳定性没有提高。

假设扩容的Observer服务为server.4，只需要在其zoo.cfg中如下配置即可：

server.4的zoo.cfg配置

peerType=observer

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.4 = 127.0.0.1:2691:3791:observer

2、Follower扩容

Follower扩容建议扩容服务节点数为偶数个，这样和源集群加起来就是奇数个。

在不停机，只有Leader重选时不能正常对外提供服务外，集群一直处于正常状态，照这个要求，试了多种场景，好像只有一种方式：新节点作为Follower加入源集群。

假设，源集群为3个服务节点，Leader为server.1，现在扩容为5个，扩容节点为server.7 和 server.8。源集群初始配置为：

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

（1）修改扩容节点配置

修改server.7 和 server.8的zoo.cfg为如下所示：

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.7 = 127.0.0.1:2697:3797

server.8 = 127.0.0.1:2698:3798

（2）启动扩容节点

server.7 和 server.8依次启动后，首先处于投票选举的状态（LOOKING），交换选票，收到源集群 Follower 和 Leader 的选票后，统计选票，如果某个节点拥有超半数的选票，且有Leader，则扩容节点设置自己的状态为Follower（FOLLOWING），并退出选举。这样扩容节点就和源集群建立了连接。

但是源集群保持独立，新节点故障与否不影响源集群过半机制判断。

（3）修改客户端zk地址

修改连接源集群的客户端的zk地址为加上server.7 和 server.8共5个ipport。

（4）修改源集群的配置

依次修改源集群的zoo.cfg，加上server.7 和 server.8。

（5）重启源集群

依次重启源集群，但是需要注意源集群的Leader最后重启，如server.1是Leader，就先重启server.2，再重启server.3，此时源集群处于不可用和扩容之后的新集群处于Leader选举的状态，此时会有短暂不能正常对外提供服务。

最后重启server.1。扩容完毕。

需要注意：扩容之后的集群的Leader变了，可能为扩容节点中的一个。

（6）人为脑裂

需要强调一下，如果扩容的节点数超过了源集群的节点个数，可能人为造成脑裂。

如3个扩容为7个，需要扩容4个节点，使用如上方式扩容时，就可能出现问题。扩容节点依次重启时，处于投票选举状态，交换选票，收到源集群 Follower 和 Leader 的选票后，统计选票，源集群有3个节点投给了某个节点，但是扩容之后的节点个数为7，3没有超过7的半数，所以扩容节点不会设置自己的状态为Follower（FOLLOWING），一直处于投票选举状态。

需要强调两点：

• 处于投票状态的服务节点接收到其他节点的选票时，会根据选票信息中发送者状态来区分统计，Follower 和 Leader 发送的一起统计，同处于投票状态（LOOKING）的节点一起统计。

• 统计选票时，如果是Follower 或 Leader 发来的选票，说明此时集群中已经有Leader了，但是还是先判断票数是否过半，然后再判断集群中是否有Leader。

当4个扩容节点都重启后，4个扩容节点交换选票，可以再选一个Leader出来，此时就存在两个Leader，互不干扰。源集群没有重启过还是认为自己是3个节点的，而扩容之后的集群，认为自己是7个节点，但是只有4个正常节点，挂一个就会死。

脑裂出现了，可能会出现数据不一致问题。

正常情况下，ZooKeeper不会因为网络分区出现脑裂问题。

四、zk集群动态缩容

---

因为扩容有两种方式，对应的缩容也有两种应对措施：

• 缩减掉Observer很简单，基本不会影响源集群。

• 缩减Follower，就稍微复杂些。

以源集群5个节点缩减为3个为例，源集群配置为：

server.1 = 127.0.0.1:2688:3788

server.2 = 127.0.0.1:2689:3789

server.3 = 127.0.0.1:2690:3790

server.7 = 127.0.0.1:2697:3797

server.8 = 127.0.0.1:2698:3798

为了做好运维面试路上的助攻手，特整理了上百道 【运维技术栈面试题集锦】 ，让你面试不慌心不跳，高薪offer怀里抱！

这次整理的面试题，小到shell、MySQL，大到K8s等云原生技术栈，不仅适合运维新人入行面试需要，还适用于想提升进阶跳槽加薪的运维朋友。

本份面试集锦涵盖了

• 174 道运维工程师面试题
• 128道k8s面试题
• 108道shell脚本面试题
• 200道Linux面试题
• 51道docker面试题
• 35道Jenkis面试题
• 78道MongoDB面试题
• 17道ansible面试题
• 60道dubbo面试题
• 53道kafka面试
• 18道mysql面试题
• 40道nginx面试题
• 77道redis面试题
• 28道zookeeper

总计 1000+ 道面试题， 内容 又全含金量又高

• 174道运维工程师面试题

1、什么是运维?

2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的?

3、现在给你三百台服务器，你怎么对他们进行管理?

4、简述raid0 raid1raid5二种工作模式的工作原理及特点

5、LVS、Nginx、HAproxy有什么区别?工作中你怎么选择?

6、Squid、Varinsh和Nginx有什么区别，工作中你怎么选择?

7、Tomcat和Resin有什么区别，工作中你怎么选择?

8、什么是中间件?什么是jdk?

9、讲述一下Tomcat8005、8009、8080三个端口的含义？

10、什么叫CDN?

11、什么叫网站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
站灰度发布?

12、简述DNS进行域名解析的过程?

13、RabbitMQ是什么东西?

14、讲一下Keepalived的工作原理?

15、讲述一下LVS三种模式的工作过程?

16、mysql的innodb如何定位锁问题，mysql如何减少主从复制延迟?

17、如何重置mysql root密码?

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！