zookeeper怎么扩容，增加server

1. zookeeper版本3.4.6

2. 现有ZK集群是五台，身份识别码分别为0,1,2,3,4

3. 三地机房
   （1）。机房1，现有集群在该机房，主机房，服务的主要流量在该机房。目前ZK的5台机器在该机房。
   （2）。机房2，热备机房，有全量服务但是机器数量较机房1少，分担少部分负载，在机房1不可用时，将会对外提供所有服务。
   （3）。机房3（延时较大，在100毫秒）。

4. 需要构建一个高可用ZK环境，服务主要部署在机房1，机房2有全量服务但是机器数量较机房1少。

5. 现在需要将机房1,2做成一个大的zk集群，但是由于zk对双机房，不能做到高可用，所有加了一个机房3.现在这三个机房的zk实例数为5 + 5 + 1 。

6. 现有ZK实例为5，但是我们需要扩容到11台，添加实例数比原有集群实例数大。

7. 在扩容过程中需要不影响使用现有ZK集群的服务不可以。全部停止，进行升级。

需要注意的问题

1. 添加的机器数大于现有集群ZK实例数。

2. 三地机房，其中机房1为主机房，资源最多，尽量让领导者落在该机房。机房1和机房2的延时在容忍范围内，领导也可以落在该机房，但是需要优先考虑机房1 。因为机房3延时较大，尽量不可以让机房3的实例担任领导角色。

3. 历史遗留问题，原有ZK集群的本身份识别码是从0开始的，这是个坑（稍后会说）。

具体步骤

修改身份识别码

为什么要先修改本身份识别码，这是之前我们给自己挖的一个大坑，这次一定要填上，并且为以后的ZK运维积累经验。因为，我们需要领导尽量落在机房1的机器上，鉴于ZK集群进行领导者中用到的快速选举算法，集群中的机器会优先匹配zxid最大的实例（这样可以保证在数据同步时，这个实例上的数据是最新的），如果所有实例中的zxid都一样，那么所有实例会选举出本身份识别码最大的实例为领导者。基于这样的条件，我们需要将机房1中的现有的5台的身份识别码进行提升，给机房3的ZK实例腾出本身份识别码的位置（以确保在zxid一样时，它肯定不会是领导者）。因为ZK中本身份识别码的范围必须是大于等于0（没错，你没看错，我们使用了0，即使官方样品配置中是从1开始，但是我们还是使用了0），所有我们需要先将myid = 0的实例进行本身份识别码变更。

1.修改myid = 1的机器的myid为100，依次对修改五个实例的zoo.cfg

修改完之后的配置类似如下：

1 2 3 4 五

server.1 = 192.168.1.101:2555:3555 server.2 = 192.168.1.102:2555:3555 server.3 = 192.168.1.103:2555:3555 server.4 = 192.168.1.104:2555:3555 server.100 = 192.168.1.100:2555:3555

 

2.记录现在集群中哪台机器为龙头，该机器最后重启。

3.依次重启身份识别码为1,2,3,4,100的实例（注意最后重启的领导者）

好的，这里我说另外一个坑，我们重启服务的时候最好是依从身份识别码从小到大依次重启，因为这个里面又涉及到饲养员另外一个设计.zookeeper是需要集群中所有集群两两建立连接，其中配置中的3555端口是用来进行选举时机器直接建立通讯的端口，为了避免重复创建TCP连接，如果对方身份识别码比自己大，则关闭连接，这样导致的结果就是大标识的服务器才会去连接小ID的服务器，避免连接浪费如果是最后重启身份识别码最小的实例，该实例将不能加入到集群中，因为不能和其他集群建立连接，这时你使用NC命令，会有如下的提示：这个ZooKeeper的实例是目前没有提供请求在饲养员的启动日志里面你会发现这样的日志：。拥有较小的服务器标识符，因此断开连接如果真的出现了这个问题，也没关系，但是需要先将报出该问题的实例起着，然后按照身份识别码从小到大依次重启ZK实例 可。是的，我们确实碰到了这个问题，因为我们稍后会将机房3的那个ZK实例的本身份识别码变为0，并最后加入到11台实例的集群中，最后一直报这个问题。

添加新机器进入集群

经过上面的步骤，现在来添加新机器进入集群。因为新集群ZK实例数量为11台，那么如果能做到HA，需要保证集群中存活机器至少为6台。鉴于这样的要求，我们并不能一次性将11台机器的配置修改为如下：

1 2 3 4 五 6 7 8 9 10 11

server.0 = 192.168.3.1:2555:355555 server.1 = 192.168.1.101:2555:3555 server.2 = 192.168.1.102:2555:3555 server.3 = 192.168.1.103:2555:3555 server.4 = 192.168.1.104:2555:3555 server.5 = 192.168.2.1:2555:3555 server.6 = 192.168.2.2:2555:3555 server.7 = 192.168.2.3:2555:3555 server.8 = 192.168.2.4:2555:3555 server.9 = 192.168.2.5:2555:3555 server.100 = 192.168.1.100:2555:3555

 

我们只能先将原有的5台ZK实例的集群先扩充到7台（为何不是8台？慢慢梳理一下就知道了），然后再扩充到11台这样的步骤。鉴于这样的思路，我们的步骤如下：

1.选出两台新的实例，加上之前的5台，将他们的配置文件修改为7台，依次重启原集群ZK实例，然后启动两台新加入的实例，注意最后重启领导。

1 2 3 4 五 6 7

server.1 = 192.168.1.101:2555:3555 server.2 = 192.168.1.102:2555:3555 server.3 = 192.168.1.103:2555:3555 server.4 = 192.168.1.104:2555:3555 server.5 = 192.168.2.1:2555:3555 server.6 = 192.168.2.2:2555:3555 server.100 = 192.168.1.100:2555:3555

问：为什么是7，不是8

不能是偶数个，这个为了防止在提供服务是，一半选择一个，一半选择结果B，此时无法得到正确结果。

2.将zoo.cfg中的集群机器数量设为为11台，已经存在的7台zk实例集群进行重启，然后重启另外四台新zk实例。这里你可能在启动本身份识别码= 0的ZK实例会出现上面描述的问题，没关系，按照上面说的步骤操作即可。

 

方案二：如果允许动物园管理员的服务短暂停止，则可以

 整体重启

所谓集群整体重启，就是先将整个集群停止，然后更新动物园管理员的配置，然后再次启动。如果在你的系统中，动物园管理员并非个个非常核心的组件，并且能够允许短暂的服务停止（通常是几秒钟的时间间隔），那么不妨选择这种方式在整体重启的过程中，所有该集群的客户端都无法连接上集群等到集群再次启动，这些客户端就能够自动连接上。 - 注意，整体启动前建立起的客户端会话，并不会因为此次整体重启而失效。也就是说，在整体重启期间花费的时间将不计入会话超时时间的计算中。

方案三：动态增加节点

柯林斯借鉴https://www.cnblogs.com/EasonJim/p/7478594.html

借鉴与：http：//siye1982.github.io/2015/06/16/zookeeper/