做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
zk集群在多机房部署上有两种方案：
- 第一种：可以采用机房内独立zk集群部署，机房内服务的路由策略以本机房服务发现为主，中间存在数据同步。
- 第二种：双机房zk集群部署，这样可以实现跨机房服务调用。
服务发现之后的路由策略上选择比较多，比如local first，本地优先。
多活架构要求下，同城双活意义不大，zk这样完全可以同城三机房部署一个集群，不过如果为了未来实现异地多活，就另说了，比如可用性要求很高的金融场景可以采用。
在多机房zk集群部署时，常常遇到的问题是因异地网络延迟高，出现网络抖动，这些都会影响zk集群稳定性，比如投票时间过长，造成整体可用性降低。
对于跨机房zk集群提供服务发现能力，很多人最先想到的就是脑裂问题，如果zk集群部署在两个机房，是不是很容易出现脑裂呢？
其实很难，同城多机房问题也不大，zk有半数以上限制，出现脑裂时间极短，连不上主，少数节点机房节点会不再接受请求。所以同城多机房部署是推荐的一种做法。
操作流程如下：
在A机房服务注册数据时，同步到B机房服务注册，在A机房故障时，迁移服务到B机房，这样请求就都路由到正常的B机房了，交易处理过程就内聚到B机房了。
对于访问请求根据设备信息等同步到一个机房处理，这种方式存在的隐患是会出现热点机房。
需要再声明下，zk部署推荐三机房。
Zookeeper 集群如何高可用部署？
其他的同步中间件比如Redis，Mysql可以采用主从同步，这种方式都是单向的，最好方式还是可以采用双向多通道的方案，本次就不深入了。
