Zookeeper-workflow

Zookeeper-ワークフロー

ZooKeeperアンサンブルが開始されると、クライアントの接続を待機します。 クライアントは、ZooKeeperアンサンブルのノードの1つに接続します。 リーダーノードまたはフォロワーノードの場合があります。 クライアントが接続されると、ノードは特定のクライアントにセッションIDを割り当て、クライアントに確認応答を送信します。 クライアントが確認を受け取らない場合、ZooKeeperアンサンブル内の別のノードに接続しようとします。 ノードに接続すると、クライアントは定期的にノードにハートビートを送信して、接続が失われないようにします。

• クライアントが特定のznodeを読みたい場合、 znodeパスを持つノードに read request を送信し、ノードは自身のデータベースから取得することで要求されたznodeを返します。 このため、ZooKeeperアンサンブルでは読み取りが高速です。
• クライアントがZooKeeperアンサンブルにデータを保存する場合、znodeパスとデータをサーバーに送信します。 接続されたサーバーはリクエストをリーダーに転送し、リーダーはすべてのフォロワーに書き込みリクエストを再発行します。 過半数のノードのみが正常に応答した場合、書き込み要求は成功し、成功した戻りコードがクライアントに送信されます。 そうでない場合、書き込み要求は失敗します。 厳密な過半数のノードは Quorum と呼ばれます。

ZooKeeper Ensembleのノード

ZooKeeperアンサンブルに異なる数のノードを配置した場合の効果を分析してみましょう。

• *単一のノード*がある場合、そのノードに障害が発生すると、ZooKeeperアンサンブルは失敗します。 これは「単一障害点」の一因となり、実稼働環境では推奨されません。
• * 2つのノード*があり、1つのノードに障害が発生した場合、2つのうち1つが過半数ではないため、過半数もありません。
• * 3つのノード*があり、1つのノードで障害が発生した場合、過半数であるため、これが最小要件です。 実稼働環境では、ZooKeeperアンサンブルに少なくとも3つのノードが必要です。
• * 4つのノード*があり、2つのノードに障害が発生すると、再び障害が発生し、3つのノードを持つことに似ています。 追加のノードは目的を果たさないため、奇数、たとえば3、5、7のノードを追加することをお勧めします。

すべてのノードがデータベースに同じデータを書き込む必要があるため、書き込みプロセスはZooKeeperアンサンブルの読み取りプロセスよりもコストがかかることがわかっています。 したがって、バランスの取れた環境では、ノードの数を増やすよりも、ノードの数を少なくする（3、5、または7）方が適切です。

次の図は、ZooKeeperのワークフローを示しており、次の表はそのさまざまなコンポーネントを説明しています。

ZooKeeper Ensemble

Component	Description
Write	Write process is handled by the leader node. The leader forwards the write request to all the znodes and waits for answers from the znodes. If half of the znodes reply, then the write process is complete.
Read	Reads are performed internally by a specific connected znode, so there is no need to interact with the cluster.
Replicated Database	It is used to store data in zookeeper. Each znode has its own database and every znode has the same data at every time with the help of consistency.
Leader	Leader is the Znode that is responsible for processing write requests.
Follower	Followers receive write requests from the clients and forward them to the leader znode.
Request Processor	Present only in leader node. It governs write requests from the follower node.
Atomic broadcasts	Responsible for broadcasting the changes from the leader node to the follower nodes.