首发CSDN：徐同学呀，原创不易，转载请注明源链接。我是徐同学，用心输出高质量文章，希望对你有所帮助。

一、前言

zk集群的动态迁移与扩缩容需要做到两个不：

1. 不停机，ZooKeeper 集群在运维过程中能正常对外提供服务。
2. 不丢失，ZooKeeper 集群在运维过程中数据正确同步，不丢失。

要想做到以上两个不，需要对ZooKeeper的Leader选举和运行机制有一定了解。Leader选举是保证数据一致性的关键所在，过半数保证集群正常对外提供服务。

在集群迁移和扩缩容的过程中会发生数据的迁移恢复和同步，请参考另一篇《ZooKeeper运维——数据备份与恢复》。

二、zk集群动态迁移

从源集群不停机迁移到目的集群，保证数据一致性，保证集群正常对外提供服务。

假设源集群和目的集群都是三个服务节点，源集群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.4、server.5、server.6，正常配置如下：

server.4 = 127.0.0.1:2691:3791
server.5 = 127.0.0.1:2692:3792
server.6 = 127.0.0.1:2693:3793

1、利用Observer机制

为了能从源集群动态把数据同步到目的集群，利用Observer机制，将server.4、server.5、server.6暂时分别作为源集群的Observer启动，配置分别如下：

## 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
server.5 = 127.0.0.1:2692:3792
server.6 = 127.0.0.1:2693:3793

## 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状态。

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

源集群Leader为server.1，现在将server.7和server.8去掉。

1、修改剩余节点配置

修改剩余节点配置，如下：

server.1 = 127.0.0.1:2688:3788
server.2 = 127.0.0.1:2689:3789
server.3 = 127.0.0.1:2690:3790

2、修改客户端zk地址

将客户端zk地址去掉缩减的节点。

3、依次重启剩余节点

server.1是Leader，所以最后重启，剩下server.2和server.3依次重启。

剩余节点重启完毕后，缩容就可以结束了。被缩减的节点停止下架即可。

需要注意，不要先停止需要缩减的节点，否则会导致剩余节点在重启时正常节点你不过半而无法对外提供服务。

五、要点总结

在集群迁移和扩缩容的过程中，需要注意Leader最后重启，避免多余的Leader选举。注意过半数机制，不要导致源集群正常运行的节点没有过半数而无法对外提供服务。

扩容的话，还是建议以Observer 的方式，比较简单，提升的性能比较显著，灵活性也更大。

如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。

如果想了解更多优质文章，和我更密切的学习交流，请关注如下同名公众号【徐同学呀】，期待你的加入。

注：《ZooKeeper-分布式过程协同技术详解》和 《从Paxos到Zookeeper分布式一致性原理与实践》pdf版本由于版权问题无法在CSDN上传，有需要这两本PDF的请关注公众号：徐同学呀，回复zkpdf获取。