ZooKeeper を一言でまとめると、「ZooKeeper は現在利用可能な分散コンポーネントの中で最も広く利用されていると言っても過言ではありません。その機能と責任は単一でありながら、極めて重要です。」

[[208846]]

ZooKeeper とは何ですか? (技術記事)

1) ZooKeeper は、分散システムにおける一貫性を処理するためのフレームワークとして Yahoo! によって開発されました。

2) 背景：ZooKeeper は当初、Hadoop 開発の副産物として生まれました。分散システムにおける一貫性管理は困難であったため、他の分散システムは車輪の再発明をする必要がなくなり、ZooKeeper は後続の分散システムで広く採用されました。その結果、ZooKeeper は様々な分散システムの基盤コンポーネントとなり、その重要性が際立っています。（例として、ソケットネットワークプログラミングの優れたラッパーであり、通信コンポーネントフレームワークである Netty を考えてみましょう。Netty についてよく知らない方は、この記事をブックマークして 5 分ほどかけて学習してください。簡単に言うと、Netty は通信コンポーネントとして使用される JAR ファイルです。）

3) 特定のアプリケーション シナリオ: よく知られている Hadoop、Kafka、Dubbo はすべて ZooKeeper 上に構築されています。

4) 利点: 分散環境におけるデータの最終的な一貫性を保証します。これは ZooKeeper が解決できる問題です。

5) 上で一貫性について何度も言及しましたが、一貫性とは実際何なのかをここで説明しましょう。

いわゆる一貫性は、本質的に「見る」ことにかかっています。誰がそれを見ることができるのか？見ることができるのか？いつ見ることができるのか？例えば、Taobaoの出品者がバックエンドで大規模なプロモーション用の商品を出品し、サーバーA経由でメインデータベースに送信したとします。送信直後にユーザーがアプリケーションサーバーB経由でデータベースにその商品を照会すると、出品者は出品情報を更新したにもかかわらず、購入者は商品を見ることができないという状況が発生します。メインデータベースのデータがセカンダリデータベースに同期されるまでの一定期間が経過すると、購入者はようやく商品を見ることができるようになります。（本物の技術記事）

売り手が正常に更新した直後に買い手が売り手の更新を確認できる場合、それは強力な一貫性と呼ばれます。

販売者が正常に更新した後、購入者が更新されたコンテンツを表示できない場合、それは弱い一貫性と呼ばれます。

販売者がアプリを正常に更新し、一定期間後に購入者がその更新を確認できる場合、これを結果整合性と呼びます。

6) 一貫性の問題を解決するための一般的な方法は他にもあります。

1. クエリ再試行による補償。分散アプリケーションにおける不確実な状況では、まずクエリインターフェースを使用して現在の状態を確認します。現在の状態に矛盾がある場合は、補償インターフェースを使用して再試行し、ステータスを進めるか、ロールバックインターフェースを使用してビジネスロジックをロールバックします。典型的なシナリオは、銀行とAlipayのやり取りです。Alipayは銀行に送金リクエストを送信します。応答がない場合、銀行のクエリインターフェースを介して取引ステータスを確認できます。受信者がリクエストを受信して​​いない場合は、補償メカニズムを使用してリクエストをプッシュします。

2. スケジュールされたタスクのプッシュ通知。上記の状況では、1つのプッシュ通知では不十分な場合があり、2つまたは3つのプッシュ通知が必要になる場合があります。驚くことではありませんが、Alipayでは初期注文の失敗率が非常に高く、スケジュールされたタスクのプッシュ通知を継続的に送信することで成功率が大幅に向上します。

3. TCC (Try-Confirm-Cancel) は実際には 2 フェーズのプロトコルであり、第 2 フェーズでは操作をコミットするか元に戻すことができます。

7) ZooKeeperは具体的に何ができるのでしょうか？前述の通り、Hadoop、Kafka、DubboはすべてZooKeeper上に構築されています。ここではDubboを例に、ZooKeeperについて具体的に説明します。（本物の技術記事）

業界でよく知られている分散型 SOA フレームワークである Dubbo の主なサービス登録および検出機能は、ZooKeeper によって提供されます。

サービスフレームワークにとって、レジストリセンターはまさに中核です。一時的な停止ではサービス全体が停止することはありませんが、完全な障害は重大なリスクをもたらします。レジストリセンターが単一のマシンである典型的なシナリオでは、実装は簡単です。すべてのマシンがレジストリセンターにサービスを登録し、すべての呼び出し元が永続的な接続を維持します。サービスへの変更は、これらの永続的な接続を介して呼び出し元に通知されます。しかし、サービスクラスターが拡大するにつれて、これははるかに複雑になります。単一のマシンでは維持できる接続数が限られており、障害が発生しやすくなります。

Dubboは、安定したサービス指向フレームワークとして、レジストリセンターとしてZooKeeperを選択し、推奨しています。その基盤となる実装は、一般的に使用されるZooKeeperクライアントであるzkclientとcuratorをZooKeeperClientにカプセル化しています。

1. サービス プロバイダーはサービスを開始すると、ZooKeeper にノードを登録します。

2. サービスコンシューマーは、親ノードの起動や停止などの変更をサブスクライブします。これらの変更は、ノードの作成と削除を通じて検出できます。また、セッションが切断された際に一時ノードが自動的に削除されることで、呼び出し側がオフラインになるなどの異常な状況も検出できます。

3. サービス コンシューマーも、ノードを作成して、サブスクライブしたサービスを ZooKeeper に配置します。

4. これにより、誰がサービスを提供し、誰がどのサービスに加入しているかといったマッピング関係が得られます。この関係に基づいて監視することで、システム全体の状態を容易に把握できます。

ZooKeeper の基本データ モデル (優れた技術記事):

つまり、Linux ファイル システムに似たノード モデルです。

そのノードには次のような興味深く重要な特性があります。

1. 複数のマシンが同時に同じノードを作成しようとした場合、競合に成功するのは1台だけです。この特性を利用して、分散ロックを作成できます。

2. エフェメラルノードのライフサイクルはセッションと同じです。セッションが終了すると、エフェメラルノードも削除されます。この機能は、ハートビート、動的監視、負荷分散などのアクションでよく使用されます。

3. シーケンシャルノードは、ノード名がグローバルに一意であることを保証します。この特性は、分散環境においてグローバルに自動増分するIDを生成するために利用できます。

ZooKeeper が提供する基本的なサービスを使用することで、ZooKeeper の機能について正確かつ直感的に理解できるようになります。

ZooKeeper は基本的なサービスを提供します:

1. ノードを作成する

2. ノードを削除

3. ノードを更新

4. ノード情報を取得する

5. アクセス制御

6. イベントリスナー

本質的には、ノードの追加、削除、クエリ、変更、そしてアクセス制御とイベントリスニングに関するものです。しかし、これらのプリミティブを組み合わせて様々なシナリオで使用することで、多様な用途を実現できます。

1. データのパブリッシュ/サブスクライブ。これは、上記のDubboの使用例に示されているように、レジストリセンターを指します。主に、ノード管理によるパブリッシュと、イベントリスニングによるサブスクリプションを実現します。

2. 負荷分散。上記の Kafka の使用法を参照してください。

3. ネーミング サービス。ZooKeeper のノード構造はネーミング サービスをネイティブにサポートしています。つまり、情報を一元的に保存し、ツリー構造で管理することで、簡単に統一された検索が可能になります。

4. 分散コーディネーション通知。コーディネーション通知は実際にはパブリッシュ・サブスクライブに似ていますが、サードパーティのZooKeeperの導入により、多くの種類のコーディネーション通知を効果的に分離します。

5. クラスタ管理とマスター選出。上記の2番目の機能により、クラスタマシンの稼働状態を容易に判断できるため、クラスタ管理が簡素化されます。また、上記の1番目の機能により、マスター競合が可能になります。

6. 分散ロックは、本質的にはポイントインタイム特性の応用です。

7. 分散キュー。これは実際には3番目の特性の応用です。

8. 分散同時待機。マルチスレッドにおける結合問題と同様に、メインタスクの実行は他のすべてのサブタスクの完了に依存します。結合は単一マシンのマルチスレッド環境では使用できますが、分散環境ではどのように実装できるでしょうか？ZooKeeperを使用すると、メインタスクノードを作成できます。メインタスクノードの下にあるサブタスクの実行が完了すると、メインタスクノードの下に新しいサブタスクノードが追加されます。ノード数が十分になると、メインタスクは実行開始の準備が整ったとみなされます。

すべてのプリミティブが ZooKeeper の基盤であり、その他の使用方法の概要は、さまざまなシナリオにおけるプリミティブの単なる分類であることがわかります。