转自 极客时间 Redis 亚风 原文视频：https://u.geekbang.org/lesson/535?article=681062
Redisの同期
Redis のマスターとスレーブのデータ同期、最初のマスターとスレーブの同期は完全同期です
replicaof master主机 端口 #当前这个机器做Master的备份
マスターは、スレーブが初めてデータを同期しているかどうかをどのように判断しますか:
レプリケーション ld: Replid 略して、データ セットのマークです。ID が一貫している場合は、それが同じデータ セットであることを意味します。各マスターには固有のレプリカがあり、スレーブはマスター ノードのレプリカを継承します。
Offset: オフセット。repl_baklog に記録されるデータが増加するにつれて徐々に増加します。スレーブは同期を完了すると、現在の同期オフセットも記録します。
スレーブのオフセットがマスターのオフセットより小さい場合、スレーブ データがマスターより遅れているため、更新する必要があることを意味します。
したがって、スレーブがデータ同期を実行するときは、マスターがどのデータを同期する必要があるかを判断できるように、そのレプリケーション ID とオフセットをマスターに宣言する必要があります。
再起動後にスレーブが同期されると、増分同期が実行されます。
repl_baklogには上限があり、いっぱいになると古いデータから上書きされます。スレーブが長時間切断され、データが上書きされた場合、増分同期は達成できず、完全同期を再度実行することしかできません。スレーブとマスターの間には常にわずかなギャップがあり、上のスレーブ ノードがマスター ノードに追いつくことができず、1 ターン以上経過すると、後続のデータが書き換えられてしまいます。
可以从以下⼏个⽅⾯来优化Redis主从集群
完全同期中のディスク IO を回避するには、マスターで repl-diskless-sync yes を構成してディスクレス レプリケーションを有効にし (これはネットワーク帯域幅に依存しますが、これを理解するのは現実的ではありません)。
単一の Redis ノードでのメモリ使用量は大きすぎないようにし、RDB による過剰なディスク IO を減らし、
repl_baklog のサイズを適切に増やし、スレーブのダウンが見つかった場合はできるだけ早く障害回復を実装し、完全同期を避ける必要があります。できるだけ
マスター上のスレーブ ノードの数。スレーブが多すぎる場合は、マスター-スレーブ-スレーブ チェーン構造を使用してマスターへの負担を軽減できます。
番兵
slave节点宕机恢复后可以找master节点同步数据，那master节点宕机怎么办？
Redis は、マスター/スレーブ クラスターの自動障害回復を実現する Sentinel メカニズムを提供します。Sentinel の構造と機能は次のとおりです。
• 監視: Sentinel はマスターとスレーブが期待どおりに動作しているかどうかを常にチェックします。
• 自動障害回復: マスターに障害が発生した場合、Sentinel はスレーブをマスターに昇格します。障害が発生したインスタンスが復元されると
、新しいマスターが引き継ぎます
。注意: Sentinel は、Redis クライアントのサービス検出ソースとして機能します。クラスターでフェイルオーバーが発生すると、
最新の情報が Redis クライアントにプッシュされます。Sentinel
は、ハートビート メカニズムに基づいてサービスのステータスを確認し、1 秒ごとにクラスターの各インスタンスに ping コマンドを送信します。
オンラインおよびオフラインの検出と選択
• 主観的オフライン: 指定された時間内にインスタンスが応答しないことをセンチネル ノードが検出した場合、そのインスタンスは主観的にオフラインであるとみなされます。
• 客観的オフライン: 指定された数 (クォーラム) を超えるセンチネルがインスタンスが主観的にオフラインであるとみなした場合、インスタンスは客観的にオフラインになります。クォーラム値は、Sentinel インスタンスの数の半分を超えることが望ましいです。マスター障害が発見されると、センチネルはスレーブ内の新しいマスターを選択する必要があります。選択基準は次のとおりです:
1) まず、スレーブ ノードがマスター ノードから切断されている時間を決定します。指定された値を超えた場合、 (down-after -milliseconds * 10) はスレーブ ノードを除外します
2) 次に、スレーブ ノードのスレーブ優先度の値を決定します。優先度が小さいほど優先度が高くなります。0 の場合、そのスレーブ ノードは選挙に参加しません。
3) スレーブ優先度が同じ場合、スレーブを決定します ノードのオフセット値 大きいほどデータが新しく、優先度が高くなります
4) 最後にスレーブの実行 ID サイズを決定します値が小さいほど、
優先度が高くなります。スレーブの 1 つが新しいマスターとして選択された場合 (たとえば、slave1 )、フェイルオーバーの手順は次のとおりです:
1) Sentinel は、slaveof no one コマンドを代替の smile1 に送信します。ノードを使用して、このノードをマスターにします。
2) Sentinel は、slaveof ip port コマンドを他のすべてのスレーブに送信し、これらのスレーブが新しいマスターのスレーブ ノードになり、新しいマスターからのデータの同期を開始できるようにします。
3) Sentinel は障害のあるノードをスレーブとしてマークします (構成を変更します)。障害のあるノードが回復すると、そのノードは自動的に新しいマスターのスレーブ ノードになります。
sping 针对主从的应用
spring.redis.sentinel.master=mymaster
spring.redis.sentinel.node=ip:port,ip:port
Sentinel に接続するときは、この Bean を指定する必要があります。
ここでの ReadFrom は、Redis の読み取り戦略を構成するためのものです。次の選択肢を含む列挙です:
MASTER: マスター ノードから読み取ります
。 MASTER_PREFERRED: 最初にマスター ノードから読み取ります。マスターは使用できません。リードレプリカのみ
REPLICA: スレーブ (レプリカ) ノードから読み取り
REPLICA_PREFERRED: 最初にスレーブ (レプリカ) ノードから読み取り、すべてのスレーブが使用できない場合にのみマスターを読み取ります
Redis シャードクラスター
マスター/スレーブとセントリーは、高可用性と高同時読み取りの問題を解決できます。
• 大量のデータストレージの問題
• 高い同時書き込みの問題
上記の問題は、分割クラスタを使用することで解決できます。分割クラスタの特徴は
次のとおりです。クラスタ内に複数のマスターがあり、各マスターは異なるデータを保存します
• 各マスターは複数のスレーブ ノードを持つことができます
。マスターは ping を通じて互いの健全性ステータスを監視します
。クライアント リクエストはクラスタ内の任意のノードにアクセスでき、最終的には正しいノードに転送されます。
Redis は、各マスター ノードを 0 から 16383 までの合計 16384 個のスロット (ハッシュ スロット) にマップします。クラスター情報を確認すると、データ キーがノードではなくスロットにバインドされていることがわかります
。Redis はキーの有効な部分に基づいてスロット値を計算します。状況は 2 つあります:
キーに {} が含まれている場合と、{} に少なくとも 1 文字が含まれています。{} 内の部分は有効な部分です
。キーには次の文字が含まれていません。 {}。キー全体に {} は含まれません。キーはすべて有効な部分です
。例: キーが num の場合、num に基づいて計算されます。{a}num の場合、a に基づいて計算されます。 。計算方法は、CRC16 アルゴリズムを使用してハッシュ値を取得し、16384 の余りを取得します。結果がスロット値です。
クラスター フェイルオーバー コマンドを使用すると、クラスター内のマスターを手動でシャットダウンし、クラスター フェイルオーバー コマンドを実行するスレーブ ノードに切り替えることで、目に見えないデータ移行を実現できます。手動フェイルオーバーは 3 つの異なるモードをサポートします:
• デフォルト: 以下の図に示すデフォルトのプロセス。次
の 2 つのコマンドは一般的に使用されません:
• 強制: オフセットの一貫性チェックは省略されます (現在のノードが一貫しているかどうかに関係ありません)。マスターとは距離があります)
• takeover: データの一貫性、マスターのステータス、他のマスターの意見を無視して、ステップ 5 を直接実行します。
