我想了解在跨数据中心运行Zookeeper时可用的现有方法吗？
我在做一些研究后发现的一种方法是让观察者。这种方法是在主数据中心只有一个有领导者和追随者的集合。并在备份数据中心拥有观察员。当主数据中心崩溃时，我们选择其他数据中心作为新的主数据中心，并手动将观察者转换为领导者/跟随者。
我想了解更好的方法来实现同样的目标。
由于
答案 0 :(得分：1)
首先，我想指出您的解决方案的弊端，希望我的解决方案能够解决该问题：
a）在主数据中心发生故障的情况下，恢复过程是手动的（我引用了您的话：“将观察者手动转换为领导者/跟随者”）
b）仅主数据中心接受写操作->万一失败，所有数据（观察者不写日志时）或仅最后一次更新（观察者写日志时）都会丢失
因为问题是关于数据中心 S 的，所以我认为我们有足够的（DC）可以达到我们的目标：解决a。和b。同时拥有可用的多数据中心分布式ZK。
因此，当具有偶数个数据中心（DC）时，可以仅使用一个附加的DC来获得整体中奇数个ZK节点。当有可以添加2个DC，而不是第3个。每个DC可以包含1个rwZK（读写ZK节点），或者为了更好地容忍故障，每个DC可以包含3个组织为hierarchical quorums的rwZK（两种情况都可以使ZK观察者受益）。在DC内部，所有ZK客户端应仅指向DC的ZK组，因此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，因此必须实施隧道或其他方法。
更新
另一种解决方案是仍然使用附加的第三个DC（或公司办公室），但仅保留rw-ZK（1、3或其他奇数），而其他2个DC仅具有观察者ZK。客户端仍应仅连接到DC的ZK服务器，但我们不再需要hierarchical quorums。这样做的好处是，写协议和领导者选举仅在具有rw-ZK的DC内部（我们称其为仲裁DC）。缺点是：
-仲裁器DC是单点故障
-写入请求仍必须从观察者DC传输到仲裁器DC