ZooKeeper 的替代品？ （集群协调服务）[关闭]

Posted 2023-02-16

【中文标题】ZooKeeper 的替代品？ （集群协调服务）[关闭]

【英文标题】：ZooKeeper alternatives? (cluster coordination service) [closed]

【发布时间】：2011-08-28 05:19:45

【问题描述】：

ZooKeeper 是面向数据中心的高可用性协调服务。它起源于 Hadoop 项目。可以在它之上实现锁定、故障转移、领导者选举、组成员资格和其他协调问题。 ZooKeeper 有什么替代品吗？ （当然是免费软件）

【参考方案1】：

我广泛研究了 Zookeeper/Curator、Eureka、etcd 和 consul。如果您在 Java 世界中，Zookeeper/Curator 和 Eureka 在许多方面都是最完善和最容易集成的。 Etcd 非常酷且非常灵活，但它实际上只是一个 HA 密钥存储，因此您必须编写大量代码才能将其变成一个固执己见的服务发现系统。

Consul（对我来说）是两全其美的。它是一个基于serf 编写的固执己见的服务发现系统，使用 raft 进行集群共识和 gossip 进行通信。它使用记录良好的 REST api 公开发现/注册端点，还允许您使用 DNS SRV 记录发现服务，并使用配置注册服务（即，您可以注册无法与客户端集成的数据库或应用程序，或者如果你只是想让你的服务发现与你的应用程序分离）

我写了一个blog post about consul，您可以在其中了解更多信息并浏览我的“试用”演示

如果您想了解更多关于自定义代码的外观，我还讨论了service discovery with etcd & docker。

最后一件事！ etcd 和 consul 是用 go 编写的，因此维护它们比 zookeeper 之类的 java 解决方案要容易得多。您只需要 consul / etcd 二进制文件。没有依赖项，没有链接库，没有 jvm。

【参考方案2】：

有一个非常有前途的 ZooKeeper 替代方案，名为 etcd (github.com/coreos/etcd)，由 CoreOS 团队编写。与 Doozerd 不同，etcd 正在积极开发中。

【参考方案3】：

刚刚发现 Accord (C) 和 OpenReplica/ConCoord (Python) 可能是有趣的解决方案

[编辑] 以 Vagrant 和 Packer 闻名的 Hashicorp 团队正在打造名为 Serf 的“用于服务发现和编排的去中心化解决方案”。

[EDIT2] Hashicorp 再次出击！他们刚刚发布了Consul，建立在 Serf 之上。宣传语：“一种服务发现和配置解决方案，完全分布式，高度可用，可扩展到跨多个数据中心的数千个节点和服务”。

【讨论】：

Accord 是一个用于写入密集型负载的新兴项目。它使用 CoroSync，它也被 Qpid 使用，并且可以与 Linux HA 一起使用。

Accord 似乎已死：“无法访问此站点/找不到 www.osrg.net 的服务器 IP 地址。”

【参考方案4】：

是的，还有Doozerd (https://github.com/ha/doozerd)。好好看看，它是 Heroku 开发的一个不错的单一二进制分布式协调服务。使用 java/python/ruby/node 的绑定/库。很容易上手和玩耍。

【讨论】：

Doozerd 不错，但没有维护，也没有生产记录。

【参考方案5】：

看看Serf。有一个与 Zookeeper here 的比较。

【参考方案6】：

我的研究小组的OpenReplica 是一个高可用的数据中心 FOSS 协调服务。它可用于实现锁定、故障转移、领导者选举、组成员资格和其他协调服务。它在两个关键方面与 ZooKeeper 不同：

它使用面向对象的 API。这使得编写协调服务变得更加容易。 OpenReplica 的同步代码看起来与它的教科书对应物一模一样；无需像 ZooKeeper 和 Chubby 那样掌握文件和基于 upcall 的 API。

它启用对副本集的动态成员资格更新。不需要静态配置文件。该系统已集成到 DNS（权威、OpenReplica 的从属设备或 Amazon Route 53）中。

我们积极支持该系统，如果您有其他问题，请随时告诉我们。

【讨论】：

1) ZooKeeper 是面向对象的，参见zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html 2) ? ZK 基本上是一个用于存储基础设施元数据的 femto 文件系统，它还支持存在检测（临时节点）和观察者。

我已经提取了 git repo，似乎最后一次提交是从 5 月开始的。希望你还在闲逛:)

嗨 Barry：ZooKeeper 不是面向对象的。主要的抽象（znodes、paths、watches）都支持小对象的维护，API 是文件系统的。如果你仔细观察 OpenReplica，你会发现 ZK 的文件系统 API 和 OpenReplica 的 OO API 有很大的不同。 wizzard0：我们还活着！新版本定于 4 月初发布。

【参考方案7】：

在 github 上有一个名为 Noah 的项目，看起来很有趣，它说它“松散地基于 Apache ZooKeeper”https://github.com/lusis/Noah，其中 REST 支持是一个关键特性（ZK 将此作为贡献/选项而不是内置）。

【讨论】：

Noah 对于不需要高可用性或作业安全性是可选的应用程序可能很有用。

【参考方案8】：

有不同的工具可以针对不同的工程权衡进行优化。

ZooKeeper

略微扩展以进行读取；与许多观察者一起写入可能会很慢。它已被证明并拥有相当大的社区。

Accord

似乎对写入密集型用途很感兴趣，但典型用例已经有特定领域的解决方案（即日志记录、遥测）。

其他的有些有趣，但通常未经证实。如果打算用于生产用途，请不要弄错。

【参考方案9】：

我发现了 Zookeeper、etcd 和 Doozer 的比较： http://devo.ps/blog/zookeeper-vs-doozer-vs-etcd/

Serf (serfdom.io) 也是一个不错的解决方案，因为它很简单！但是您必须考虑，SERF 只是一个集群管理器，它使您能够将自定义事件发送到所有集群节点。很好，但是您必须编写自己的 shell 脚本（也称为事件）。 看这个例子：“https://www.digitalocean.com/community/articles/how-to-set-up-a-serf-cluster-on-several-ubuntu-vps”

优点是，您将获得一个非常简单的集群管理器，并且您可以将它与您最喜欢的配置、部署或持续集成工具相结合。

【参考方案10】：

看来Corosync 也像 ZooKeeper。

【参考方案11】：

我知道这篇文章已经很老了，但是有人正在寻找所有可能的替代方案，我还想推荐 JGroups 库，它足够成熟，可以在生产环境中使用。我在我的一个项目中成功地使用了它，主要用于分布式协调和集群之间的消息共享。除了其灵活的架构外，它还支持 AWS 支持，您可以在其中自定义其堆栈以获得所需的内容。建议你have a look at it