Redis--歩哨の実現原理

5658 ワード
Redis
歩哨実現原理
1つの哨兵プロセスが開始されると、プロファイルの内容が読み込まれ、次の構成で監視するプライマリ・データベースが見つかります.
sentinel monitor master-name ip redis-port quorum
  • master-name:プライマリ・データベース名(大文字と小文字、数字、. - _からなる)は、障害復旧後に現在監視されているプライマリ・データベースのアドレスとポートが変化することを考慮して、哨兵は名前から現在のシステムのプライマリ・データベースのアドレスとポート番号を取得するコマンドを提供した.
  • ip:プライマリ・データベースを表すアドレス
  • redis-port:ポート番号
  • quorum:障害復旧操作を実行する前に少なくともいくつかの哨兵ノードが
    • に同意する必要があることを示します.
    1つの歩哨ノードは同時に複数のRedis主従システムを監視することができ、複数のsentinel monitor構成を提供するだけでよい.
    sentinel monitor mymaster 127.0.0.1 6379 2
sentinel monitor othermaster 192.168.1.3 6380 4

    同時に複数の歩哨ノードも同じRedis主従システムを同時に監視することができ、それによって網状構造を形成することができる.
    哨兵が起動すると、監視するメインデータベースと2つの接続が確立され、この2つの接続の確立方式は通常のRedisクライアントと変わらない.
  • のうちの1つは、プライマリデータを購読するために使用される_sentinel_:helloチャンネルに接続され、他の同じようにデータを監視する哨兵ノード情報を取得する.
  • また、歩哨は定期的にメインパンツにINFOなどのコマンドを送信してメインデータベース自体の情報を取得する必要がある(クライアントの接続が購読モードに入ると他の操作を実行できないため、別の接続を使用する):メインパンツとの接続が確立された後、歩哨は次の3つの操作を定期的に実行する.
  • 10秒ごとに歩哨はメインデータベースとデータベースからINFOコマンド
    • を送信する.
  • 哨兵は2秒ごとにメインデータベースとデータベースの_sentinel_:helloチャンネルから自分の情報
    • を送信する.
  • 1 1秒ごとに歩哨はメインデータベースを考え、データベースと他の歩哨ノードからPINGコマンド
    • を送信する.

    この3つの操作は哨兵のライフサイクル全体を貫いている.
    まず、新しいノードの自動検出を実現するために、現在のデータベースに関する情報( ID、 )を取得できるようにINFOコマンドが送信される.哨兵は、INFOコマンドを使用して、プライマリ・データベースをコピーしたすべてのスレーブ・データベース情報を取得します.
    起動後、歩哨はメインデータベースにINFOコマンドを送信し、結果を解析してデータベースリストから ， を知る.その後、哨兵は10秒ごとに既知のすべてのホストにINFOコマンドを送信して情報更新を取得し、応答操作を行います.たとえば、次のようにします.
  • は、新しいデータベースからの接続を確立し、監視リスト
    • が
  • プライマリスレーブデータベースの役割変化(フェイルオーバ操作による)に対する情報更新等
    • .
    次に、哨兵は、同じデータベースを監視している哨兵と自分の情報を共有するために、データベースの_sentinel_:helloチャンネルから情報を送信する.
    送信されるメッセージの内容は次のとおりです.
  • 哨兵の住所
  • 哨兵のポート
  • 哨兵の運行ID
  • 哨兵の配置バージョン
  • プライマリ・データベース名
  • プライマリ・データベースのアドレス
  • プライマリ・データベース・ポート
  • プライマリ・データベースの構成バージョン
    • メッセージには、哨兵の基本情報と、その監視するプライマリ・データベースの情報が含まれます.他の哨兵がメッセージを受け取ると、メッセージを送った哨兵が新しく発見された哨兵かどうかを判断します.
  • もしそうであれば、発見された哨兵リストに追加し、その接続を作成します(データベースとは異なり、哨兵間にはPINGコマンドを送信するための接続しか作成されません.チャンネルを購読するために別の接続は必要ありません.哨兵はデータベースのチャンネルを購読するだけで、他の哨兵を自動的に発見することができます).
  • そうでない場合、歩哨は情報中のプライマリ・データベースの構成バージョンを判断し、そのバージョンが現在記録されているプライマリ・データベースのバージョンよりも高い場合、プライマリ・データのデータを更新します.

    • データベースや他の哨兵ノードから自動的に発見された後、哨兵がしなければならないのは、これらのデータベースとノードがサービスを停止しているかどうかをタイミング的に監視することです.これらのノードに一定時間毎にPINGコマンドを送信することにより実現される.
    時間間隔は、down-after-millisecondsオプションに関連しています.
  • 値が1秒未満:哨兵はdown-after-milliseconds指定の時間ごとにPINGコマンド
    • を送信する.
  • 値が1秒より大きい:無視し、1秒ごとにPINGコマンド
    • を送信する.
    //  1    PING  
sentinel down-after-milliseconds mymaster 60000

//  600      PING  
sentinel down-after-milliseconds mymaster 600

    down-after-millisecondsが指定した時間を超えた後も、PINGのデータベースまたはノードに返信されていない場合、哨兵は （subjectively down）と判断します.
    主観的なラインオフは、現在の哨兵プロセスから見ると、このノードはすでに下限になっていると述べた.ノードがプライマリ・データベースである場合、哨兵はさらに障害復旧が必要かどうかを判断します.哨兵はSENTINEL is-master-down-by-addrコマンドを送信し、他の哨兵ノードにもプライマリ・データベースが主観的にオフラインであると考えているかどうかを尋ね、ゼロの哨兵ノードを選択してプライマリ・スレーブ・システムに障害復旧を開始します.この指定数は、前のquorumパラメータです.
    sentinel monitor mymaster 127.0.0.1 6379 2

    この構成は、現在のノードを含む少なくとも2つのCentinelノードがプライマリ・データベースがダウンラインしていると判断した場合にのみ、現在の哨兵ノードがデータベース と判断することを示す.次の選挙リーダーシップのステップを行う.
    現在、哨兵ノードはメインデータベースの客観的なオフラインを発見し、故障回復が必要であるが、故障回復はリーダーの哨兵が完成する必要があり、同じ時間に1つの哨兵ノードだけが故障回復を実行することを保証することができる.選挙の先頭哨兵の過程はRaft を使用し、具体的な過程は以下の通りである.
  • 主データベースが客観的にラインオフしている哨兵ノードAが各哨兵ノードに命令を送っていることを発見し、相手に自分をリーダーの哨兵に選ぶように要求した.
  • 目標歩哨ノードが他の人を選んだことがない場合、同じようにAを先頭歩哨に設定します.
  • Aが過半数を超えてquorumパラメータ値を超える哨兵ノードが同じ選択で自分をリーダー哨兵と呼ぶことを発見した場合、Aはリーダー哨兵と呼ぶことに成功する.
  • 複数の哨兵ノードが同時に先頭哨兵に立候補すると、ノードが当選する可能性はありません.このとき、各立候補ノードは、選挙が成功するまでランダムな時間に立候補要求を再開し、次の選挙を行うのを待つ.

    • リーダーシップを選択すると、リーダーシップはプライマリ・データベースの障害復旧を開始します.
  • 先頭哨兵は、サービスを停止したプライマリ・データベースのデータベースから新しいプライマリ・データベースとして1つを選択し、次のように選択します.
  • すべてのオンラインのスレーブ・データベースで、最も優先度の高いスレーブ・データベースを選択します.優先度はslave-priorityで設定できます.
  • 最も優先度の高いスレーブ・データベースが複数ある場合、レプリケーションのコマンド・オフセットの量が大きい(すなわち、レプリケーションが完全である)ほど優先されます.
  • 上記の条件が同じであれば、実行IDの小さいスレーブ・データベースを選択します.

  • データベースから1つを選択すると、リーダーシップ哨兵はSLAVEOF NO ONE命令をデータベースからプライマリ・データベースに昇格させる.リーダーシップは、SLAVEOF命令を他のデータベースから送信し、新しいプライマリ・データベースのスレーブ・データベースと呼ぶ.
  • の最後のステップは、内部のレコードを更新し、サービスを停止した古いプライマリ・データベースを新しいプライマリ・データベースのスレーブ・データベースに更新し、サービスがリカバリされると自動的にデータベースとしてサービスを継続させる.

    • 歩哨の配置
    哨兵は独立したプロセスで主従システムを監視し、監視の効果の良し悪しは哨兵の視点に代表性があるかどうかにかかっている.主従システムに配置された哨兵が少ないと、哨兵のシステム全体に対する判断の信頼性が低下する.極端な場合、1人の哨兵しかいない場合、哨兵自体が単一の故障を起こす可能性があります.全体的に、比較的安定した哨兵配置案は、哨兵の視点をノードごとの視点とできるだけ一致させることである.
  • は、プライマリ・データベースまたはデータベースにかかわらず、ノードごとに哨兵を配置する.
  • は、哨兵ごとに対応するノードのネットワーク環境を同じまたは近いものにする.

    • このような配置案は、哨兵の視点がより高い代表性と信頼性を保証することができる.1つの例を挙げると、ネットワークパーティションの後、哨兵があるパーティションが主要なパーティションであると判断した場合、すなわち、ノードごとに観察されることを意味し、そのパーティションはいずれも主なパーティションである.
    同時にquorumの値はN / 2 + 1に設定され、これにより、ほとんどの哨兵ノードが同意した後にのみ故障回復が行われる.
    システム内のノードが多い場合、各歩哨がすべてのノードと接続を確立することを考慮すると、各ノードに1つの歩哨を割り当てると、特にクライアントのスライス時に複数の歩哨ノードを使用して複数のプライマリ・データベースを監視すると、Redisが接続多重化をサポートしないため、大量の冗長接続が発生する.同時にredisノードの負荷が高い場合、ある程度、哨兵に対する回復と、同機哨兵と他のノードとの通信に影響を与える.そのため、哨兵を配置するには、実際の生産環境の状況に応じて選択する必要がある.
    ネット知識総括(session&&Cookie&&3回握手&&リクエストヘッド)
    [C++リファレンス]プライベートメンバー変数の理解