ZooKeeperの代替手段？ （クラスター調整サービス）
ZooKeeper は、データセンター向けの可用性の高い調整サービスです。これは、Hadoopプロジェクトで始まりました。ロック、フェイルオーバー、リーダー選出、グループメンバーシップ、その他の調整の問題を実装できます。 ZooKeeperに代わるものはありますか？ （もちろんフリーソフトウェア）
Zookeeper/ Curator 、 Eureka 、 etcd 、およびconsulを詳細に調べました。 Zookeeper/CuratorとEurekaは、Javaの世界にいる場合、多くの点で最も洗練されており、統合が最も簡単です。 Etcd は非常にクールで非常に柔軟性がありますが、実際には単なるHAキーストアであるため、多くのコードを記述してサービスを発見するシステムに変える必要があります。
Consul は（私にとって）両方の世界で最高です。これは serf の上に記述された、意見の一致したサービス発見システムであり、クラスターコンセンサスにraftを使用し、通信にゴシップを使用します。よく文書化されたREST apiを使用して検出/登録エンドポイントを公開し、DNS SRVレコードを使用してサービスを検出し、構成でサービスを登録することもできます（つまり、データベースまたはアプリケーションを登録できます） tクライアントを統合するか、サービス検出をアプリから切り離したままにする場合）
consulに関するブログ投稿 を作成しました。ここで、詳細を確認し、「試してみる」デモを確認できます。
etcdとdockerを使用したサービス検出 についても説明しました。カスタムコードがどのように見えるかについて詳しく知りたい場合。
最後に一つだけ！ etcdおよびconsulはgoで記述されているため、zoookeeperのようなJavaソリューションよりも保守がはるかに簡単です。必要なのは、consul/etcdバイナリだけです。依存関係、リンクライブラリ、jvmはありません。
etcd（github.com/coreos/etcd) と呼ばれる、ZooKeeperの非常に有望な代替手段があります。これはCoreOSチームによって作成されました。 Doozerdとは異なり、etcdは積極的に開発されています。
発見されたばかりの Accord （C）および OpenReplica/ConCoord （Python）興味深いソリューション
[編集] VagrantとPackerで有名なHashicorpのクルーは、 Serf と呼ばれる「サービスの発見とオーケストレーションのための分散型ソリューション」を調理しています。
[編集2]ハシコープが再び攻撃を開始！ Serfの上に構築された Consul をリリースしました。ピッチ：「複数のデータセンターにまたがる数千のノードとサービスにスケーラブルな、完全に分散された可用性の高いサービス検出と構成のソリューション」。
はい、 Doozerd（https://github.com/ha/doozerd) もあります。これをよく見てください。Herokuが開発したニースの単一バイナリ分散調整サービスです。 Java/python/Ruby/nodeのbindings/librariesを使用します。始めるのはとても簡単で、遊ぶのも簡単です。
OpenReplica 私の研究グループのデータセンター向けの高可用性FOSS調整サービスです。ロック、フェイルオーバー、リーダー選出、グループメンバーシップ、その他の調整サービスの実装に使用できます。 ZooKeeperとは、2つの重要な点で異なります。
オブジェクト指向APIを使用します。これにより、調整サービスの作成がはるかに簡単になります。 OpenReplicaの同期コードは、教科書の対応するコードとまったく同じです。 ZooKeeperやChubbyのように、ファイルとアップコールベースのAPIを習得する必要はありません。
これにより、レプリカセットに対する動的なメンバーシップの更新が可能になります。静的な構成ファイルは必要ありません。システムはDNS（権限のある、OpenReplicaのスレーブ、またはAmazon Route 53）に統合されています。
システムを積極的にサポートしています。ご質問がございましたら、お気軽にご連絡ください。
Zookeeper、etcd、Doozerのこの比較を見つけました： http://devo.ps/blog/zookeeper-vs-doozer-vs-etcd/
Serf（serfdom.io）も簡単なので、ニースのソリューションです！ただし、SERFはすべてのクラスターノードにカスタムイベントを送信できるクラスターマネージャーにすぎないことを考慮する必要があります。それはいいことですが、独自のシェルスクリプト（別名イベント）を作成する必要があります。この例を参照してください： " https://www.digitalocean.com/community/articles/how-to-set-up-a-serf-cluster-on-several-ubuntu-vps "
利点は、非常にシンプルなクラスターマネージャーを取得し、これをお気に入りの構成、展開、または継続的統合ツールと組み合わせることができることです。
GithubにはNoahという名前のプロジェクトがありますが、これは「Apache ZooKeeperにほぼ基づいている」と言われています https://github.com/lusis/Noah with REST =サポートが重要な機能であること（ZKには組み込みではなくcontrib/optionとしてこれがあります）。
さまざまなエンジニアリングのトレードオフを最適化するさまざまなツールがあります。
- ZooKeeper読み取りのためにわずかにスケーリングします。多くのオブザーバーによる書き込みが遅くなる可能性があります。実績があり、かなりのコミュニティがあります。
- Accord書き込みを多用する用途には興味深いようですが、典型的なユースケースにはすでにドメイン固有のソリューション（つまり、ロギング、テレメトリー）があります。
他のものはやや興味深いですが、一般的に証明されていません。実稼働での使用を意図している場合、これを間違えないでください。
私はこの投稿がかなり古いことを知っていますが、可能性のあるすべての選択肢を探している人は、実稼働環境で使用するのに十分成熟したJGroupsライブラリを提案したいと思います。私は、主に分散調整およびクラスター間でのメッセージ共有のために、私のプロジェクトの1つでこれを正常に使用しました。スタックをカスタマイズして必要なものを取得できる柔軟なアーキテクチャに加えて、AWSサポートもサポートしています。 ご覧ください
Corosync もZooKeeperのようです。