ZooKeeperまたは分散ロックサービスを記述する

免責事項先月、ZooKeeperで整理し、名前から考えられるように、ロックサービスについてではなく、実際にそれについての投稿を体系化したいと思いました。 行こう！



マルチスレッドプログラミングから分散システムのプログラミングに移行すると、多くの標準的な手法が機能しなくなります。 これらの手法の1つは同期化されます。スコープが1つのプロセスに制限されているため、分散システムの異なるノードで動作するだけでなく、同じマシン上の異なるアプリケーションインスタンス間でも動作しません。 ロックには別のメカニズムが必要であることがわかります。



分散ロックサービスを要求するのは合理的です。

1. ネットワークの点滅状態での作業能力（分散システムの最初のルールは、ネットワークが分散システムについて誰も話さないことに対して信頼できないことです ）
2. 単一障害点がない

ZooKeeperは、このようなサービスの作成を支援します。



ウィキペディアによると、 ZooKeeperは分散構成および同期サービスであり 、あなたのことは知りませんが、この定義からはあまりわかりません。 私の経験を振り返ると、 ZooKeeperの代替定義を提供できます。これは、次のプロパティを持つ分散キー/値ストレージです。

• キースペースはツリーを形成します（ファイルシステムに類似した階層）
• 値は、リーフだけでなく、階層の任意のノードに含めることができます（ファイルが同時にディレクトリでもあるかのように）、階層ノードはznodeと呼ばれます
• クライアントとサーバー間に双方向通信があるため、クライアントは特定の値または階層の一部の変更としてサブスクライブできます。
• 作成したクライアントがクラスターに接続している間に存在する一時的なキー/値のペアを作成することが可能です
• すべてのデータがメモリに収まる必要があります
• クリティカルでない数のクラスターノードの耐死性

なじみのないシステムに慣れるには、まず提供するAPIから始める必要があります。

サポートされている操作

存在する	znodeの存在を確認し、そのメタデータを返します
作成する	znodeを作成します
削除する	znodeを削除します
getData	znodeに関連付けられたデータを取得します
setData	新しいデータをznodeに関連付けます
getChildren	指定されたznodeの子を取得します
同期する	接続しているクラスターノードとウィザードの同期を待機しています。

これらの操作は、次のグループに分類できます。

コールバック	キャス
存在する	削除する
getData	setData
getChildren		作成する
		同期する

コールバック -コールバックを示すことができる読み取り専用操作。コールバックは、要求されたエンティティが変更されたときに機能します。 コールバックは1回しか機能しません。値を常に監視する必要がある場合は、イベントハンドラーに常に再サインインする必要があります 。



CAS-書き込み要求。 ZooKeeperの競合アクセスの問題は、compare-and-swapによって解決されました。バージョンは各znodeに保存されます。変更する場合、znodeがすでに変更されているかどうかを示す必要があります。バージョンが一致しないため、クライアントは対応する例外を受け取ります。 このグループの操作では、変更するオブジェクトのバージョンを指定する必要があります。



create-新しいznode（キー/値のペア）を作成し、キーを返します。 引数として示されている場合、キーが返されるのは奇妙に思えますが、実際には、ZooKeeperにキーのプレフィックスを付けて、znodeがシーケンシャルであると言うことができ、その後、アライメントされた数値がプレフィックスに追加され、結果がキーとして使用されます 同じ接頭辞を持つ順次znodeを作成することにより、キーが（辞書グラフィックの意味で）増加するシーケンスを形成することが保証されます 。



シリアルznodeに加えて、 一時znodeを作成できます。これは、作成したクライアントが切断されるとすぐに削除されます （ZooKeeperのクラスターとクライアント間の接続は長時間開いたままになることを思い出します）。 エフェメラルznodeには子を含めることはできません。



Znodeは、一時的でもシーケンシャルでもかまいません。



sync-クライアントが接続されているクラスターノードをマスターと同期します。 同期は迅速かつ自動的に行われるため、永久に呼び出さないでください。 いつ電話をかけるかについては、以下で説明します。



連続する一時的なznodeとそれらの削除のサブスクリプションに基づいて、分散ロックシステムを簡単に作成できます。

分散ロックシステム

実際、すべてが私たちの前に発明されました-私たちは、レシピセクションの ZooKeeperウェブサイトに行き、そこでブロックアルゴリズムを探します：

1. 「_locknode_ / guid-lock-」をプレフィックスとして使用して一時的なシリアルznodeを作成します。ここで、_locknode_はロックしているリソースの名前、guidは新しく生成されたガイドです
2. イベントにサブスクライブせずに、子のリスト_locknode_を取得します
3. 最初のステップで作成されたznodeのキーに最小の数値接尾辞がある場合：アルゴリズムを終了します-リソースを取得しました
4. そうでない場合、子ノードのリストをサフィックスでソートし、ステップ1で作成したものの前にリストにあるznodeのコールバックで呼び出しが存在します。
5. falseになった場合はステップ2に進み、そうでない場合はイベントを待ってステップ2に進みます

マテリアルの同化を確認するには、自分で理解してみてください。降順または昇順で、ステップ4でリストをソートする必要があります。

ZooKeeperの操作中に操作が落ちた場合は、操作が成功したかどうかを確認できないため 、このチェックをアプリケーションレベルで行う必要があります。 これには、GUIDが必要です。それを知って、子に尋ねると、新しいノードを作成したかどうかを簡単に判断でき、操作を繰り返す価値があります。



ちなみに、私はそうは言いませんでしたが、シーケンシャルzノードのサフィックスを計算するために、一意のプレフィックスシーケンスではなく、zノードが作成される一意の親シーケンスを使用していることを既に推測したと思います。

WTF

理論的には終了できますが、実践が示しているように、最も興味深いものが始まります-wtf 'ki。 wtfとは、システムに関する私の直感的なアイデアとその実際の動作との間の矛盾を意味します。

WTF＃1-コードを裏返しにする

すべてのAPIメソッドは、チェック済み例外をスローし、それを処理するように強制できます。 分散システムの最初のルールはネットワークが信頼できないということなので、これは馴染みのない、しかし正しいです。 飛ぶ可能性のある例外の1つは、接続の切断（ネットワークの点滅）です。 接続が失われたクラスターノード（CONNECTIONLOSS）と混同しないでください。この場合、クライアントは保存されたセッションとコールバック（別の接続または待機）で復元し、この場合、クラスターからの接続とすべてのコールバックの損失（SESSIONEXPIRED）を強制的に閉じますコンテキストを復元するタスクはプログラマーにあります。 しかし、私たちはトピックから離れました...



ウインクを処理する方法？ 実際、 クラスターとの接続を開くとき、他の人のように一度だけではなく、繰り返し呼び出され、失われた接続と復元された接続に関するイベントを配信するコールバックを示します 。 接続が失われたときに判明します。計算を一時停止し、目的のイベントが到着したら続行する必要があります。



これは何かを思い出させますか？ 一方で-イベント、他方では-私の意見では、継続とモナドのどこかで、プログラムの流れで「遊ぶ」必要性。



一般に、プログラムのステップは次の形式で設計しました。

public interface Task { Task continueWith(Task continuation); //     void run(Executor context, Object arg); //   void error(Executor context, Exception error); //  ,    -   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エグゼキューターはどこですか

 public interface Executor { void execute(Task task, Object arg, Timer timeout); // timeout     / TimeoutException  error ,   real-time }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要なコンビネータを追加すると、次のプログラムをビルドできます。どこかでステップのべき等性を使用し、どこかで明示的にゴミをクリーンアップします：

• 四角は便利な操作であり、矢印は実行スレッドおよび/またはエラーストリームです。
• rhombus-指定されたエラーを無視し、最後の有用な操作を繰り返すコンビネーター
• ハニカムは、通常の実行フローの場合は操作Aを実行し、特定のエラーの場合は操作Bを実行するコンビネータです
• 丸められた平行六面体-成功した実行スレッドを起動するコンビネーター。エラーはすぐにさらにスキップします

Executorを実装するときに、ラッパー関数をZooKeeperクラスに追加して、すべてのイベントのハンドラーであり、Watcher（呼び出すイベントハンドラー）自体を決定します。 実装内に、3つのBlockingQueueとそれらを読み取る3つのスレッドを配置しました。その結果、イベントが到着するとeventQueueに追加されるため、ZooKeeper内のすべてのWatcherは1つのスレッドで動作し、 、したがって、1つのイベントを処理すると、他のすべてのイベントがブロックされ、ZooKeeper自体がブロックされる場合があります 。 taskQueueの2番目のターンでは、引数とともにTask'iが追加されます。 これらのキュー（eventQueueおよびtaskQueue）は、それぞれフロー、eventThreadおよびtaskThreadに割り当てられ、これらのスレッドはキューを読み取り、各着信オブジェクトをJobにラップして、実際にタスクコードまたはハンドラーを実行する独自のスレッドを持つjobQueueに入れますメッセージ。 接続に失敗した場合、taskThreadスレッドは中断され、ネットワークが上昇した場合、再開されます。 1つのスレッドでシャッフルとハンドラーのコードを実行すると、ロックを心配する必要がなくなり、ビジネスロジックが容易になります。

WTF＃2-メインサーバー

ZooKeeperでは、サーバー（クラスター）がメインであり、クライアントには実質的に権利がないと言えます。 時々これは絶対になります、例えば... ZooKeeper構成にはセッションタイムアウトなどのパラメーターがあり、クラスターとクライアント間の接続がどれだけ消えるかを決定します。最大値を超えると、このクライアントのセッションが閉じられ、このクライアントのすべての一時znodeが削除されます; 接続が復元されると、クライアントはSESSIONEXPIREDイベントを受け取ります。 そのため、接続が失われ（CONNECTIONLOSS）、セッションタイムアウトを超えると、愚かに待機して何もしませんが、アイデアによれば、セッションがデッドであると推測し、SESSIONEXPIREDをハンドラーにスローできます。



この動作のため、開発者はある時点で髪を引き裂きます。たとえば、ZooKeeperサーバーを上げて接続しようとしましたが、設定に誤りがあり、間違ったアドレスまたはポートをノックすると、上記の動作に従います。 、MySQLなどの場合のように、クライアントがCONNECTED状態になり、エラーメッセージが表示されなくなるまで待つだけです。



興味深いことに、このシナリオを使用すると、本番環境でZooKeeperをシームレスに更新できます。

• ZooKeeperをオフにする-すべてのクライアントがCONNECTIONLOSS状態に入る
• ZooKeeperの更新
• ZooKeeperをオンにすると、サーバーとの接続は復元されましたが、サーバーに対して切断の時間が停止したため、サーバーはSESSIONEXPIREDを送信しません

ちなみに、この動作のために、エグゼキュータタイマーに渡すのは、あまり長く接続できない場合にタスクの実行をキャンセルするからです。

WTF＃3-Intオーバーフロー

上記のアルゴリズムに従ってロックを実装し、このビジネスを高負荷の生産で開始したとします。たとえば、1日あたり10 MMのロックを取得するとします。 約1年後、あなたは地獄にいることに気づく-ロックは動作しなくなります。 実際には、1年後にzversionカウンターのcversionがオーバーフローし、連続するznode名の単調に増加するシーケンスの原則に違反することになります。これがロックの実装の基礎となります。



どうする 定期的に_locknode_を削除/再作成する必要があります-関連付けられたカウンターがリセットされ、単調なシーケンスの原則に再度違反しますが、実際には、 znodeは子がない場合にのみ削除でき 、今では_versionnode_ cversionがリセットされる理由を推測します子がなく、ロックアルゴリズムに影響しません。

WTF＃4-クォーラム書き込みが読み取りではない

ZooKeeperが書き込み要求に対してOKを返した場合、これはデータがクォーラム （クラスター内のほとんどのマシン、3台のマシンの場合、クォーラムは2で構成されている）に書き込まれたことを意味しますが 、ユーザーの読み取り時には、接続先のマシンからデータを受け取ります。 つまり、ユーザーが古いデータを受け取ったときに状況が発生する可能性があります。



ZooKeeper以外の方法で顧客が通信しない場合、ZooKeeperのすべての操作は厳密に順序付けられ 、待機する方法を除いてイベントが発生したことを確認する方法がないため、これは問題ではありません。 なぜこれがすべて順調であるのかを自分で推測してください。 実際、クライアントは、誰も彼に変更を加えなかったとしても、データが更新されたことを知っている場合があります-彼が自分で変更を加えた場合、ZooKeeperは書き込みの一貫性の読み取りをサポートしているため、これは問題ではありません。



それでも、あるクライアントがZooKeeper通信チャネルを介してデータの一部の変更を発見した場合、強制同期が彼を助けます-これがsyncコマンドの目的です。

性能

ほとんどの分散キー/値ストレージは、分散を使用して大量のデータを格納します。 すでに書いたように、ZooKeeperがそれ自体に保存するデータはRAMのサイズを超えてはなりません。なぜそれが分散されるのか尋ねられます-信頼性を確保するために使用されます。 記録のためにクォーラムを取得する必要があることを思い出して、3台のマシンのクラスターを使用すると、1台のマシンと比較してパフォーマンスが15％低下することは驚くことではありません。



ZooKeeperのもう1つの機能は、永続性を提供することです。ディスクへの書き込みにかかる時間が要求処理中に含まれるため、永続性も必要です。



そして、パフォーマンスへの最後の打撃は、要求の厳密な順序によるものです-すべての書き込み要求が1つのクラスターマシンを通過するようにします。



私はローカルのラップトップでテストしました、はい、それは非常に似ています：

デヴォプスボラット

Big Data Analyticは、文で「ベンチマーク」という単語を使用しているdevopsの90％が同じ文で「laptop」という単語も使用していることを示しています。

しかし、ZooKeeperが高速ディスクと少量のデータを備えた単一ノード構成で最高のパフォーマンスを発揮することは明らかであるため、SSDとi7を搭載したX220はこれに最適です。 主に書き込み要求をテストしました。



パフォーマンスの上限は、集中的な記録中に1秒あたり約1万回の操作でした。書き込みに1ミリ秒かかります。したがって、1つのクライアントから見ると、サーバーは1秒あたり1万回の操作より速く実行できません。



これはどういう意味ですか？ ディスクに休まない状態（10％のレベルでのssdの使用、忠実度のために、ramfsを介してメモリにデータを配置しようとしました-パフォーマンスが少し向上しました）、CPUに遭遇します。 合計で、ZooKeeperはサイトの作成者が示した数の2倍しか遅いことがわかりません。これは、すべてを取得する方法を知っていることを考えると悪くありません。

まとめ

ここで書いたすべてのことにもかかわらず、ZooKeeperは見た目ほど悪くはありません。 私はその簡潔さ（7チームのみ）が好きです。プログラマAPIをプッシュして、分散システムの開発における適切なアプローチに導く方法が好きです。つまり、 すべての操作がシステムを一貫した状態のままにする必要があるため、いつでもすべてが落ちる可能性があります 。 しかし、これらは私の印象であり、ZooKeeeperが作成されたタスクを解決するという事実ほど重要ではありません：クラスター設定の保存、クラスターステータス（接続されたノードの数、ノードステータス）の監視、ノード同期（ブロック、バリア）および分散システムノードの通信（a-la jabber）。



繰り返しになりますが、ZooKeeperで開発する際に留意すべき点をリストします。

• メインサーバー
• クライアントは、データがディスクに到達したときにのみレコードに関する通知を受け取ります
• クォーラムの書き込み+書き込みの一貫性の読み取り
• 厳密な順序
• いつでもすべてが落ちる可能性があるため、変更のたびにシステムは一貫した状態にある必要があります
• 通信が失われた場合、最後の書き込み操作の状態が不明な状態になります
• 明示的なエラー処理（私にとって、最善の戦略はCPSを使用することです）

分散ロックについて

上記のブロッキングアルゴリズムに戻ると、それは機能せず、より正確には、クリティカルセクション内のアクションがブロッキングに使用される同じZooKeeperクラスターでのみ発生するまでスムーズに機能します。 なぜそう -自分で推測してみてください。 そして次の記事では、分散ロックをより正直にし、クリティカルセクション内の操作のクラスをCASをサポートするキー/値ストレージに拡張する方法を説明します。

ZooKeeperの情報へのリンク

zookeeper.apache.org

outerthought.org/blog/435-ot.html

highscalability.com/zookeeper-reliable-scalable-distributed-coordination-system

research.yahoo.com/node/3280