异地多活要求下，ZK集群应该怎么搞

做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。

zk集群在多机房部署上有两种方案：

服务发现之后的路由策略上选择比较多，比如local first，本地优先。

多活架构要求下，同城双活意义不大，zk这样完全可以同城三机房部署一个集群，不过如果为了未来实现异地多活，就另说了，比如可用性要求很高的金融场景可以采用。

在多机房zk集群部署时，常常遇到的问题是因异地网络延迟高，出现网络抖动，这些都会影响zk集群稳定性，比如投票时间过长，造成整体可用性降低。

对于跨机房zk集群提供服务发现能力，很多人最先想到的就是脑裂问题，如果zk集群部署在两个机房，是不是很容易出现脑裂呢？

其实很难，同城多机房问题也不大，zk有半数以上限制，出现脑裂时间极短，连不上主，少数节点机房节点会不再接受请求。所以同城多机房部署是推荐的一种做法。

操作流程如下：

在A机房服务注册数据时，同步到B机房服务注册，在A机房故障时，迁移服务到B机房，这样请求就都路由到正常的B机房了，交易处理过程就内聚到B机房了。

对于访问请求根据设备信息等同步到一个机房处理，这种方式存在的隐患是会出现热点机房。

需要再声明下，zk部署推荐三机房。

其他的同步中间件比如Redis，Mysql可以采用主从同步，这种方式都是单向的，最好方式还是可以采用双向多通道的方案，本次就不深入了。