|
この記事は、Miss Sister's Dogが執筆したWeChat公式アカウント「Miss Sister's Flavor」から転載されたものです。転載の許可については、「Miss Sister's Flavor」公式アカウントまでお問い合わせください。 個人的に、このコンポーネントは本当に嫌いです。コードが悪夢のようで。Nettyを使って簡単にネットワーク機能を実装できるはずなのに、NIOコードをわざわざ抽出しなければならず、非常に分かりにくくなっています。 さらに、Zookeeperのスケールアップとスケールダウンの問題により、私のチームにいくつかの問題が発生し、大量のデータが失われました。不適切なものを使用すると悪い印象を与えてしまいますが、幸いなことに、Zookeeperは古いので、今ではほとんど使用していません。 クライアントの使用法については、xjjdog によるこの記事を参照してください。 ZKクライアントキュレーターの使い方の詳細な説明 1. ZooKeeper とは何ですか?
ZooKeeperは広く利用されている分散コーディネーションシステムです。元々はHadoopのサブプロジェクトでしたが、現在はApache Software Foundationのトップレベルプロジェクトとなっています。Spring CloudやDubboといった一般的なマイクロサービスフレームワークは、ZooKeeperをレジストリセンターとして利用できます。 レジストリ センターとして機能するほか、ネーミング サービス、分散調整/通知、選出、分散ロック、分散キュー、負荷分散、構成サービスなど、他の多くのユース ケースがあります。 ZooKeeper は分散システムであると主張しているため、CAP 定理から切り離すことはできません。 2. CAP定理とは何ですか? CAP定理は、分散システムにおいて、一貫性、可用性、分断耐性のすべてを同時に実現することはできないと述べています。以下では、これら3つの概念について説明します。
分散システムでは、プロデューサー（P）が不可欠であるため、通常はコントリビューター（C）とコンセンサス（A）のどちらかを選択します。しかし、ZooKeeperは、コントリビューター（C）を重視した、強力な一貫性を備えた分散システムです。 したがって、ZooKeeper は特に強力な一貫性を備えているため、データの一貫性が求められるシナリオで使用できるという点を覚えておく必要があります。 同時に、ZooKeeper はすべてのサービスリクエストの可用性を保証できないことを認識しておく必要があります。極端な環境では、ZooKeeper が一部のリクエストを破棄する可能性があり、その結果を取得するにはコンシューマープログラムが再度リクエストを行う必要がある場合があります。 公式のアーキテクチャ図からわかるように、ZooKeeper クラスター内の異なるマシンに接続する異なるクライアントは同じデータを参照します。これが強力な一貫性の源です。 3. ZooKeeperのユースケース 3.1 登録および設定センター マシンリストなどのサービスノードに関する情報は、Spring CloudやDubboのような小規模なデータセットに典型的に含まれていますが、非常に高い一貫性が求められ、データは頻繁に変更されます。そのため、ZooKeeperはこのようなシナリオに非常に適したアプリケーションです。 このような情報を ZooKeeper に公開することで、アプリケーション ノードはデータが変更されるたびに一貫したデータ ビューを取得できます。 3.2 分散調整/通知 ZooKeeperには、Watcher登録と非同期通知メカニズムが搭載されており、異なるサービスノード間、さらには異なるシステム間でも連携が可能です。これは従来のメッセージキューのPub/Subメカニズムに非常に似ていますが、ZooKeeperのリアルタイム性と強力なデータ一貫性により、データ配信の信頼性が非常に高まります。 3.3 選挙 いわゆる選挙とは、多数のサービスノードの中から最終的な意思決定権を持つリーダーを選出するプロセスです。サービスクラスターでは、このリーダーは一般的にマスターと呼ばれます。例えば、サービスは外部へのインターフェースを公開する必要がある一方で、高可用性も確保する必要があります。現在サービスを提供しているノードに障害が発生した場合、選挙機能によってバックアップから代替ノードが選択され、サービス提供が継続されます。残りのマシンは、選出されたマシンのバックアップと呼ばれます。 3.4 分散ロック 分散ロックは、分散環境における共有リソースを調整するために設計されたロックです。例えば、2つのノードでスケジュールされたサービスがあり、実行中にビジネスロジックの計算を行うのは1つのノードのみとする場合などです。この場合、タスクは共有リソースになります。タスクを取得する際には、相互排他制御を使用して干渉を防ぎ、一貫性を確保できます。 3.5 分散キュー ZooKeeper は分散キューを実装することもできます。例えば、複数のタスクを一括で実行し、先に処理したタスクを先に処理してから、後に処理するといったことが可能です。この場合、タスク情報は ZooKeeper に保存されます。 これはメッセージ キューのキュー概念に似ていますが、厳密な順序を持つ小さなタスク バッチに適しています。 4. 類似コンポーネント ZooKeeperはZABプロトコルに基づいて構築されており、これはPaxosプロトコルに多少似ています。これらのプロトコルは複雑すぎるため、後にRaftプロトコルに基づくEtcdとConsulが開発されました。ZooKeeperはJavaで開発されていますが、後者2つはGolangで開発されています。 EtcdとConsulは、新進気鋭のツールとして、機能面とパフォーマンス面でZooKeeperよりも優れています。どちらもCPシステムであり、使い方にほとんど違いはありません。 Javaエコシステムでは、ZooKeeperがより広く使用されています。周辺インフラストラクチャや製品エコシステムの問題を考慮すると、ZooKeeperはJavaエンタープライズアプリケーションにおいて依然として重要な役割を果たしています。 もしEndを再び使うことがあったとしても、それは趣味ではなく、必ず仕事で使うでしょう。これは私がEndを使いこなせていないことの証明でもあります。本を買って少し読んだことはありますが、技術的な質問をコメントで残さないでください。 著者について：「Little Sister's Flavor」（xjjdog）は、プログラマーが落とし穴に陥らないよう支援することに特化したWeChatの公開アカウントです。インフラとLinuxに焦点を当てています。10年間のアーキテクチャ経験を持ち、毎日数十億件ものリクエストを処理しながら、皆さんと共に高並列処理の世界を探求し、独自の視点を提供しています。私の個人WeChat IDはxjjdog0です。今後の議論のために、お気軽に友達に追加してください。 |
