如何仅用2台物理机架配置高可用冗余Apache Zookeeper？

咱们先直接否定你提到的「每个机架装独立单机ZK对接同一组Solr节点」的方案——这绝对不可行。Solr的集群状态（分片分配、节点健康、配置同步等）完全依赖ZooKeeper的一致性存储，如果同时连接两个完全独立的单机ZK，会导致Solr集群的状态在两个ZK中出现分歧，轻则节点失联、查询异常，重则数据冲突、集群彻底混乱，完全违背了高可用的初衷。

下面给你几个适合双机架场景的可行方案，按优先级和实用性排序：

方案1：3节点ZK集群（2+1跨机架分配） #

这是最平衡、性价比最高的方案，完全符合ZK的quorum（过半投票）要求：

• 具体部署：在机架1放2个ZK节点，机架2放1个节点。
• 可用性表现：
  • 如果机架2故障，机架1的2个节点刚好满足3节点集群的过半要求（需要≥2个节点在线），ZK集群能正常对外提供服务，Solr集群的所有操作（查询、分片调整、配置更新）都不受影响。
  • 如果机架1故障，只剩机架2的1个节点，无法达到过半quorum，ZK会停止服务。不过此时已运行的Solr节点通常还能继续提供查询服务（可以通过调整Solr配置强化这一点），只是无法进行集群管理类操作，直到ZK恢复。
• 适用场景：适合机架1故障概率较低的环境，既能实现核心的机架冗余，又不用投入太多资源。

方案2：5节点ZK集群（3+2跨机架分配） #

如果你的业务对稳定性要求更高，能接受更多资源投入，可以考虑这个方案：

• 具体部署：在机架1放3个ZK节点，机架2放2个节点。
• 可用性表现：
  • 如果机架2故障，机架1的3个节点满足5节点集群的过半要求（需要≥3个节点在线），ZK和Solr集群完全正常。
  • 如果机架1故障，只剩机架2的2个节点，无法满足过半要求，ZK停止服务，Solr进入只读降级状态。
• 优势：相比3节点集群，能容忍更多单个节点故障（最多2个节点离线，只要不是集中在机架1超过2个），整体稳定性更强。

方案3：逻辑机架划分（针对机架内有多台服务器的情况） #

如果每个物理机架里有多台独立服务器，可以给同一机架内的服务器标记不同的「逻辑机架」（通过ZK配置里的server.x=host:port:port;rack=rackX字段实现），模拟多机架环境：

• 比如机架1有2台服务器，机架2有2台服务器，再找一台虚拟机或备用服务器凑成3节点，分配为：逻辑机架A（机架1服务器1）、逻辑机架B（机架1服务器2）、逻辑机架C（机架2服务器1）。
• 这个方案能提升服务器级的冗余（比如机架1里某台服务器故障，剩下2个节点仍能正常运行），但还是无法解决整个物理机架故障的问题，适合服务器故障概率高于机架故障的场景。

额外优化：搭配Observer节点提升读性能 #

不管用上面哪种集群方案，都可以在另一机架部署Observer节点（Observer不参与投票，只同步数据）：

• 比如3节点集群（2在机架1，1在机架2），在机架2再加1个Observer。它不会改变quorum规则，但能帮助提升读请求的吞吐量，同时在部分节点故障时，加快数据同步速度。
• 注意：Observer不能解决机架级故障导致的quorum不足问题，只是辅助优化。

最后补充一点：可以调整Solr的配置，让ZK集群失效时，已上线的Solr节点仍能继续提供查询服务，尽量降低业务影响。

内容的提问来源于stack exchange，提问作者Adam