我想知道在跨数据中心运行Zookeeper时可用的现有方法吗？
我在做一些研究后发现的一种方法是让观察者。这种方法是在主数据中心只有一个有领导者和追随者的集合。并在备份数据中心拥有观察员。当主数据中心崩溃时，我们选择其他数据中心作为新的主数据中心，并手动将观察者转换为领导者/跟随者。
我想提出更好的方法来实现同样的目标。
谢谢
首先，我想指出你的解决方案的缺点，希望我的解决方案能够解决：
a）如果主数据中心发生故障，恢复过程是手动的（我引用你：“手动将观察者转换为领导者/追随者”） b）只有主数据中心接受写入 - >如果失败，所有数据（当观察者不写日志时）或仅最后更新（当观察者写入日志时）丢失
因为问题是关于数据中心我会认为我们有足够的（DC）来实现我们的目标：解决问题。和b。具有可用的多数据中心分布式ZK。
因此，当具有偶数个数据中心（DC）时，可以仅使用额外的DC来获得整体中的奇数个ZK节点。当有例如可以添加2个DC而不是第3个DC;每个DC可以包含1个rwZK（读写ZK节点），或者为了更好地容忍故障，每个DC可以包含组织为hierarchical quorums的3个rwZK（两个案例都可以受益于ZK观察者）。在DC内部，所有ZK客户端应仅指向DC的ZK组，因此DC之间保持的流量仅用于例如DC。领导人选举，写道。通过这种设置，可以解决这两种问题。和b。但是由于写入/选举必须在数据中心之间达成一致，否则会失去写入/恢复性能：至少2个DC必须就每个DC有2个ZK节点协议的写入/选举达成一致（参见hierarchical quorums）。 DC内协议应该足够快，因此对整个写协议过程来说无关紧要;底线，大约只有DC之间的延迟才重要。这种方法的缺点是： - 第三个数据中心的额外成本：使用公司办公室（a guy did that）作为第三个数据中心可以减轻这一成本 - 由于DC间网络延迟和/或吞吐量而丢失会话：具有足够高的超时时间可以达到最大可能的写入吞吐量（取决于DC间平均网络速度），因此该解决方案仅在该最大值可接受时才有效。尽管如此，当每个DC使用1 rw-ZK时，我猜你的解决方案没有太大区别，因为从备用DC到主DC的写入也必须在DC之间传输;但是对于你的解决方案不会是DC之间的协议或领导选举相关的沟通，所以它更快。
其他考虑：
无论选择何种解决方案，都应确保DC间通信，并且为此ZK提供no solution，因此必须实施隧道或其他方法。
UPDATE
另一个解决方案是仍然使用额外的第3个DC（或公司办公室），但在哪里只保留rw-ZK（1,3或其他奇数），而其他2个DC只有观察者-ZK。客户端仍应仅连接到DC的ZK服务器，但我们不再需要hierarchical quorums。这里的好处是写协议和领导者选举只能在DC内部使用rw-ZK（让我们称之为仲裁DC）。缺点是： - 仲裁器DC是单点故障 - 写请求仍然必须从观察者DC传播到仲裁DC