Thorough Redisシリーズ（7）：センチネルメカニズムの詳細な紹介

Redisシリーズの記事：

記事のディレクトリ

で徹底的にRedisのシリーズ（6）を理解する：詳細からマスターコピーに言及したが、ホットスタンバイ、負荷分散、障害回復の役割からのデータのRedisのマスターコピー;しかし、レプリケーションの問題が存在するから、主は回復を自動化していませんでした。この記事で紹介する歩哨は、Redisマスタースレーブレプリケーションに基づいています。その主な機能は、マスターノードの障害回復の自動化の問題を解決し、システムの高可用性をさらに向上させることです。

1.歩哨とは

Sentinelを紹介する前に、Redisの高可用性に関連するテクノロジーをマクロの観点から確認しましょう。それらには、永続性、レプリケーション、センチネル、およびクラスターが含まれます。それらの主な機能と問題は次のとおりです。

永続性：永続性は最も単純な高可用性方式です（高可用性方式として分類されない場合もあります）。主な機能はデータのバックアップです。つまり、データがハードディスクに保存され、データが失われないようにします。プロセス終了。
レプリケーション：レプリケーションは高可用性Redisの基盤であり、Sentinelとクラスターはレプリケーションに基づいて高可用性を実現します。レプリケーションは主に、データのマルチマシンバックアップ、および読み取り操作の負荷分散と単純な障害回復を実現します。欠陥：障害回復を自動化できない、書き込み操作を負荷分散できない、ストレージ容量が1台のマシンによって制限されている。
Sentinel：レプリケーションに基づいて、Sentinelは自動障害回復を実現します。欠陥：書き込み操作は負荷分散できません。ストレージ容量は単一のマシンによって制限されます。
クラスタリング：クラスタリングを通じて、Redisは、書き込み操作が負荷分散できず、ストレージ容量が単一のマシンによって制限されるという問題を解決し、比較的完全な高可用性ソリューションを実現します。

歩哨について話しましょう：

Redis Sentinel、またはRedis Sentinelは、Redis2.8で導入されました。Sentinelのコア機能は、マスターノードの自動フェイルオーバーです。以下は、Redisの公式ドキュメントにあるセンチネル関数の説明です。

監視：歩哨は、マスターノードとスレーブノードが正常に動作しているかどうかを常にチェックします。
自動フェイルオーバー：マスターノードが正常に機能しない場合、センチネルは自動フェイルオーバー操作を開始します。失敗したマスターノードのスレーブノードの1つを新しいマスターノードにアップグレードし、他のスレーブノードに新しいマスターノードをコピーさせます。ノード。
構成プロバイダー：クライアントが初期化されると、センチネルに接続して現在のRedisサービスのメインノードアドレスを取得します。
通知：番兵はフェイルオーバーの結果をクライアントに送信できます。

その中で、監視機能と自動フェイルオーバー機能により、センチネルはマスターノードの障害を時間内に検出して転送を完了することができます。構成プロバイダーと通知機能は、クライアントとの対話に反映される必要があります。

この記事での「クライアント」という用語の使用法の説明は次のとおりです。前の記事では、APIを介してredisサーバーにアクセスする限り、redis-cli、JavaクライアントJedisなどを含むクライアントと呼ばれます。。;簡単に区別するためにこの記事のクライアントにはredis-cliは含まれていませんが、redis-cliよりも複雑であることを説明します。redis-cliはredisが提供する基盤となるインターフェイスを使用し、クライアントはこれらのインターフェイスと関数をカプセル化してセンチネルの構成プロバイダーと通知機能を十分に活用します。

典型的なセンチネルアーキテクチャ図は次のとおりです。

ここに画像の説明を挿入

これは、センチネルノードとデータノードの2つの部分で構成されています。

センチネルノード：センチネルシステムは、1つ以上のセンチネルノードで構成されます。これらのノードは、特別なredisノードであり、データを格納しません。
データノード：マスターノードとスレーブノードの両方がデータノードです。

二，部署

1つのマスターノード、2つのスレーブノード、3つの歩哨ノードを含む単純な歩哨システムを展開しましょう。便宜上：これらのノードはすべて、ポート番号で区別される単一のマシンにデプロイされます。ノードの構成は可能な限り単純です。

1.マスターノードとスレーブノードをデプロイします

歩哨システムのマスタースレーブノードは、通常のマスタースレーブノードと同じ構成であり、追加の構成は必要ありません。以下は、マスターノード（ポート= 6379）と2つのスレーブノード（ポート= 6380/6381）の構成ファイルです。構成は比較的単純であり、詳細は説明しません。

# redis_6379.config
port 6379
daemonize yes
logfile /var/log/redis_6379.log
dbfilename dump_6379.rdb

# redis-6380.config
port 6380
daemonize yes
logfile /var/log/redis_6380.log
dbfilename dump_6380.rdb
slaveof 127.0.0.1 6379

# redis-6381.config
port 6381
daemonize yes
logfile /var/log/redis_6381.log
dbfilename dump_6381.rdb
slaveof 127.0.0.1 6379

構成が完了したら、マスターノードとスレーブノードを順番に起動します。

service redis_6379 start
service redis_6380 start
service redis_6381 start

次の図に示すように、ノードが起動したら、マスターノードに接続して、マスタースレーブのステータスが正常かどうかを確認します。

ここに画像の説明を挿入

2.センチネルノードをデプロイします

センチネルノードは本質的に特別なRedisノードです。

3つのセンチネルノードの構成はほぼ同じですが、主な違いはポート番号（26379/26380/26381）にあります。

sentinel_26379.conf、sentinel_26380.conf、sentinel_26381.confをそれぞれ作成します

# sentinel_26379.conf
port 26379
daemonize yes
logfile /var/lib/sentinel_26379.log
sentinel monitor mymaster 127.0.0.1 6379 2

# sentinel_26380.conf
port 26380
daemonize yes
logfile /var/lib/sentinel_26380.log
sentinel monitor mymaster 127.0.0.1 6379 2

# sentinel_26381.conf
port 26381
daemonize yes
logfile /var/lib/sentinel_26381.log
sentinel monitor mymaster 127.0.0.1 6379 2

その中で、センチネルモニターmymaster 127.0.0.1 6379 2構成とは、センチネルノードがマスターノード127.0.0.1:6379をモニターし、マスターノードの名前がmymasterであり、最後の2つの意味が障害判定に関連していることを意味します。マスターノードの障害：少なくともマスターノードの障害を判別してフェイルオーバーを実行するには、2つのセンチネルノードの合意が必要です。

歩哨ノードを起動する方法は2つあり、2つの機能はまったく同じです。

redis-sentinel sentinel_26379.conf
redis-server sentinel_26379.conf --sentinel

上記の方法で構成して起動すると、歩哨システム全体が起動します。次の図に示すように、検証のためにredis-cliを介してセンチネルノードに接続できます。26379センチネルノードがすでにmymasterマスターノード（つまり127.0.0.1:6379）を監視しており、その2つのスレーブを見つけたことがわかります。ノードと他の3つのセンチネルノード。

ここに画像の説明を挿入

このとき、センチネルリンパ節の設定ファイルを確認すると、いくつかの変更点があります。例として26379を取り上げます。

ここに画像の説明を挿入

それらの中で、dirはデータとログが配置されているディレクトリのみを明示的に宣言します（センチネルのコンテキストのログのみ）。known-slaveとknown-sentinelは、センチネルがスレーブノードと他のセンチネルを検出したことを示します。パラメータと構成エポックエポック関連（構成エポックは0から始まるカウンターであり、リーダーセンチネル選出が実行されるたびに+1になります。リーダーセンチネル選出はフェイルオーバーフェーズの操作であり、これは後の主要部分で紹介されます）。

3.フェイルオーバーのデモンストレーション

歩哨の4つの機能のうち、構成プロバイダーと通知にはクライアントの協力が必要です。この記事では、クライアントが歩哨システムにアクセスするタイミングについて次の章で詳しく紹介します。このセクションでは、マスターノードに障害が発生した場合の歩哨の監視および自動フェイルオーバー機能について説明します。

1.まず、killコマンドを使用してマスターノードを強制終了します

ここに画像の説明を挿入

2、歩哨の状況を表示するための情報歩哨

この時点ですぐにinfoSentinelコマンドを使用してセンチネルノードを表示すると、センチネルはマスターノードに障害が発生して転送されたことを検出するため、マスターノードが切り替えられていないことがわかります。これにはしばらく時間がかかります。

しばらくして、センチネルノードでinfo Sentinelチェックを再度実行したところ、マスターノードが6381ノードに切り替えられていることがわかりました。

ここに画像の説明を挿入

しかし同時に、センチネルノードは新しいマスターノードにまだ2つのスレーブノードがあると考えていることがわかります。これは、センチネルが6380をマスターノードに切り替えているときに6379ノードをスレーブノードとして設定したためです。ただし、6379スレーブはノードが死亡しましたが、センチネルはスレーブノードを客観的にオフラインにしないため（意味は原則セクションで紹介します）、スレーブノードは常に存在すると考えられます。6379ノードが再起動すると、自動的に6380ノードのスレーブノードになります。以下で確認してください。

3.6379ノードを再起動します。6379ノードが6380ノードのスレーブノードになっていることがわかります。

ここに画像の説明を挿入

4.フェイルオーバーフェーズ中に、センチネルとマスターノードおよびスレーブノードの構成ファイルが書き換えられます

マスターノードとスレーブノードの場合、これは主にslaveof構成の変更です。新しいマスターノードにはslaveof構成がなく、そのスレーブノードは新しいマスターノードのslaveofです。

センチネルノードの場合、マスターノードとスレーブノードの情報の変更に加えて、エポックも変更されます。次の図では、エポックに関連するパラメーターがすべて+1であることがわかります。

ここに画像の説明を挿入

4.まとめ

歩哨システムを構築する過程で注意すべきいくつかのポイントがあります：

センチネルシステムのマスタースレーブノードは、通常のマスタースレーブノードと同じです。障害の検出と転送は、センチネルによって制御および完了されます。
センチネルノードは本質的にredisノードです。
各歩哨ノードは、監視マスターノードを構成するだけでよく、他の歩哨ノードとスレーブノードを自動的に検出できます。
センチネルノードの起動およびフェイルオーバーフェーズ中に、各ノードの構成ファイルが書き換えられます（config rewrite）。
この章の例では、センチネルは1つのマスターノードのみを監視します。実際、センチネルは複数のセンチネルモニターを構成することにより、複数のマスターノードを監視できます。

第三に、クライアントは歩哨システムにアクセスします

前のセクションでは、監視と自動フェイルオーバーという歩哨の2つの主要な機能について説明しました。このセクションでは、クライアントを組み合わせて、歩哨の他の2つの機能である構成プロバイダーと通知について説明しました。

1.コードのデモンストレーション

クライアントの原理を紹介する前に、JavaクライアントのJedisを例として取り上げて、その使用方法を示しましょう。次のコードは、構築したばかりの歩哨システムに接続し、さまざまな読み取りおよび書き込み操作を実行できます（コードは歩哨に接続して例外を処理するため、リソースのシャットダウンなどは考慮されません）。

public static void testSentinel() throws Exception {
    
    
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("127.0.0.1:26379");
         sentinels.add("127.0.0.1:26380");
         sentinels.add("127.0.0.1:26381");
 
         JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
}

2.クライアントの原則

Jedisクライアントは、歩哨に優れたサポートを提供します。上記のコードに示されているように、JedisにセンチネルノードコレクションとmasterNameを指定するだけで、JedisSentinelPoolオブジェクトを構築できます。その後、通常のredis接続プールのように使用できます。pool.getResource（）を介して接続を取得し、特定の実行を行います。コマンド。

プロセス全体で、コードはマスターノードに接続するためにマスターノードのアドレスを明示的に指定する必要はありません。コードにフェイルオーバーの兆候はなく、歩哨がフェイルオーバーを完了した後にマスターノードを自動的に切り替えることができます。。これができる理由は、関連する作業がJedisSentinelPoolのコンストラクターで実行されているためです。これには、主に次の2つのポイントが含まれます。

センチネルノードをトラバースしてマスターノード情報を取得します。センチネルノードをトラバースし、センチネルノードの1つ+ masterNameを介してマスターノードの情報を取得します。この関数は、のセンチネルget-master-addr-by-nameコマンドを呼び出すことによって実装されます。センチネルノード。このコマンドの例は次のとおりです。

ここに画像の説明を挿入

マスターノード情報が取得されると、トラバーサルが停止します（したがって、通常、最初のセンチネルノードがトラバースされるとサイクルが停止します）。

センチネルの監視を強化する：このようにして、フェイルオーバーが発生すると、クライアントはセンチネルの通知を受信して、マスターノードの切り替えを完了することができます。具体的な方法は次のとおりです。redisが提供するパブリッシュ/サブスクライブ機能を使用して、センチネルノードごとに個別のスレッドを開き、センチネルノードの+ switch-masterチャネルにサブスクライブし、メッセージを受信したときに接続プールを再初期化します。

3.まとめ

クライアントの原則を導入することで、センチネル機能の理解を深めることができます。

構成プロバイダー：クライアントは、センチネルノード+ masterNameを介してマスターノード情報を取得できます。センチネルの役割は、プロバイダーを構成することです。Sentinelは構成プロバイダーであり、プロキシではないことに注意してください。2つの違いは、構成プロバイダーの場合、クライアントがセンチネルを介してマスターノード情報を取得した後、マスターノードへの接続を直接確立し、後続の要求（set / getなど）が送信されることです。マスターノードに直接送信します。プロキシの場合、クライアントからのすべてのリクエストは歩哨に送信され、歩哨はマスターノードを介してリクエストを処理します。
通知：フェイルオーバーが完了すると、センチネルノードは新しいマスターノード情報をクライアントに送信し、クライアントが時間内にマスターノードを切り替えることができるようにします。

第四に、歩哨の実現原理

1.センチネルノードでサポートされるコマンド

センチネルノードは、特別なモードで実行されるredisノードとして、通常のredisノードとは異なるコマンドをサポートします。運用・保守においては、これらのコマンドでセンチネルシステムに問い合わせや変更を行うことができますが、さらに重要なのは、センチネルシステムに障害検出やフェイルオーバーなどのさまざまな機能を実装する必要があり、センチネルノード間の通信と切り離せないことです。センチネルノードでサポートされているコマンドを介して実現されます。センチネルリンパ節でサポートされる主なコマンドを以下に説明します。

基本的なクエリ：これらのコマンドを使用して、歩哨システムのトポロジ、ノード情報、構成情報などをクエリできます。

info sentinel：監視対象のすべてのマスターノードの基本情報を取得する
sentinel masters：監視対象のすべてのマスターノードの詳細情報を取得する
sentinel master mymaster：監視対象のマスターノードmymasterの詳細情報を取得します
sentinel slaves mymaster：監視対象のマスターノードmymasterのスレーブノードの詳細情報を取得します
sentinel sentinels mymaster：監視対象のマスターノードmymasterのセンチネルノードの詳細情報を取得します
sentinel get-master-addr-by-name mymaster：前回の記事で紹介した監視対象マスターノードmymasterのアドレス情報を取得する
sentinel is-master-down-by-addr：センチネルノードは、このコマンドを使用して、マスターノードがオフラインであるかどうかを問い合わせ、客観的にオフラインであるかどうかを判断できます。

マスターノードの監視を追加/削除します

sentinel monitor mymaster 127.0.0.1 6379 2：センチネルノードはマスターノード127.0.0.1:6379を監視し、マスターノードの名前はmymasterであり、最後の2つの意味はマスターノードの障害判断に関連しています。少なくとも2つのセンチネルノードが同意して、マスターノードに障害が発生し、転送の障害に進みます。
sentinel remove mymaster：現在のセンチネルノードによるマスターノードmymasterの監視をキャンセルします

強制フェイルオーバー

sentinel failover mymaster：このコマンドは、現在のマスターノードがそのまま実行されている場合でも、** mymasterへのフェイルオーバーを強制**できます。たとえば、現在のマスターノードが配置されているマシンが廃棄されようとしている場合、フェイルオーバーはフェイルオーバーを通じて事前に実行できます。コマンド。

2.基本原則

歩哨の原則に関して、重要なのは以下の概念を理解することです。

時限タスク：各センチネルノードは3つの時限タスクを維持します。タイミングタスクの機能は次のとおりです。infoコマンドをマスタースレーブノードに送信して最新のマスタースレーブ構造を取得し、パブリッシュおよびサブスクライブ機能を介して他のセンチネルノードの情報を取得します。pingコマンドを送信してハートビートを検出します。他のノードに移動して、オフラインにするかどうかを決定します。

時限タスク1：各歩哨ノードは情報コマンドをマスターノードとスレーブノードに送信して、10秒ごとに最もトポロジー的な構造図を取得します。歩哨が構成されている場合は、マスターノードの監視を構成するだけで済みます。マスターノード、スレーブノードを取得します。新しいスレーブノードが参加すると、情報をすぐに感知できます。

時限タスク2：各センチネルノードは、マスターノードに関するセンチネルノードの判断と現在のセンチネルノード情報を2秒ごとにredisデータノードの指定されたチャネルに送信します。また、各センチネルノードはチャネルにサブスクライブして、他のセンチネルノードの情報とマスターノードの判断は、実際にはメッセージの公開とサブスクライブを通じて行われます。

時限タスク3：1秒ごとに、各歩哨はpingコマンドをマスターノード、スレーブノード、およびその他の歩哨ノードに送信してハートビート検出を行います。これは、歩哨がノードが正常かどうかを判断するための重要な基礎でもあります。
主観的オフライン：ハートビート検出のタイミングタスクで、他のノードが特定の期間を超えて応答しない場合、センチネルノードは主観的にオフラインになります。名前が示すように、主観的オフラインとは、センチネルノードが「主観的に」オフラインで判断することを意味します。主観的オフラインの対応物は客観的オフラインです。
オフラインの目的：センチネルノードがマスターノードを主観的にオフラインにした後、センチネルis-master-down-by-addrコマンドを使用して、他のセンチネルノードにマスターノードのステータスを問い合わせます。センチネルの数がオフラインであると判断された場合特定のレベルの値に達すると、メインノードは客観的にオフラインになります。客観的オフラインはマスターノードに固有の概念であることに注意することが重要です。スレーブノードとセンチネルノードに障害が発生した場合、センチネルが主観的にオフラインになった後、その後の客観的オフライン操作とフェイルオーバー操作はありません。
リーダーセンチネルノードの選出：マスターノードが客観的にオフラインであると判断されると、各センチネルノードはリーダーセンチネルノードを選出するためにネゴシエートし、リーダーノードはそのノードに対してフェイルオーバー操作を実行します。マスターノードを監視しているすべての歩哨をリーダーとして選択できます。選挙で使用されるアルゴリズムはRaftアルゴリズムです。Raftアルゴリズムの基本的な考え方は先着順です。つまり、選挙のラウンドです。、歩哨AはリーダーになるためにBに送信しますBが他の歩哨に同意しなかった場合、彼はリーダーとしてAに同意します。選挙の具体的なプロセスについては、ここでは詳しく説明しません。一般的に、センチネルの選択プロセスは非常に高速であり、オフラインで最初に目標を達成した人がリーダーになります。
フェイルオーバー：選出されたリーダーの番兵がフェイルオーバー操作を開始します。これは大きく3つのステップに分けることができます。

ステップ1：スレーブノードから新しいマスターノードを選択する：選択の原則は、最初に異常なスレーブノードを除外することです。次に、最も高い優先度（slave-priorityで指定）のスレーブノードを選択します。優先度を区別できない場合は、オフセットが最大のスレーブノードをコピーします。それでも区別がつかない場合は、runidが最小のスレーブノードを選択します。

ステップ2：マスタースレーブステータスを更新します。選択したスレーブノードをslaveof no oneコマンドでマスターノードにし、他のノードをslaveofコマンドでスレーブノードにします。

手順3：オフラインマスターノード（つまり6379）を新しいマスターノードのスレーブノードとして設定します。6379がオンラインに戻ると、新しいマスターノードのスレーブノードになります。

上記の重要な概念を通して、基本的に歩哨の動作原理を理解することができます。より鮮明に説明するために、次の図は、フェイルオーバーを完了するためのノードの開始を含む、リーダーセンチネルノードのログを示しています。

ここに画像の説明を挿入

5、構成と実用的な提案

1.構成

歩哨に関連するいくつかの構成は次のとおりです。

sentinel monitor {masterName} {masterIp} {masterPort} {quorum}：センチネルモニターはセンチネルのコア構成であり、センチネルノードの展開については前回の記事で説明しました。その中で、masterNameはマスターノードの名前を指定し、masterIpとmasterPortはマスターノードのアドレスを指定します。クォーラムは、マスターノードの目的のオフラインを判断するためのセンチネル数のしきい値です。マスターノードがオフラインであると判断するセンチネルの数がクォーラムに達すると、マスターノードは目的のオフラインになります。推奨値は、歩哨の数の半分に1を加えたものです。
sentinel down-after-milliseconds {masterName} {time}：センチネルのダウンアフターミリ秒は、主観的なオフラインの判断に関連しています。センチネルは、pingコマンドを使用して、他のノードでハートビート検出を実行します。ダウンアフターミリ秒で設定された時間後に他のノードが応答しない場合、センチネルは主観的に応答します。オフライン。この構成は、マスターノード、スレーブノード、センチネルノードの主観的なオフライン判定に有効です。

ミリ秒後のダウンのデフォルト値は30000、つまり30秒です。これは、さまざまなネットワーク環境やアプリケーション要件に応じて調整できます。値が大きいほど、主観的なオフラインの判断が緩くなり、誤判断の可能性があるという利点があります。が少ない場合、欠点は、障害の検出とフェイルオーバーの時間が長くなり、クライアントの待機時間も長くなることです。たとえば、アプリケーションの可用性に対する要件が高い場合は、値を小さい値に調整して、障害が発生したときにできるだけ早く転送を完了することができます。ネットワーク環境が比較的悪い場合は、しきい値を適切に上げて回避できます。頻繁な誤判断。
sentinel parallel-syncs {masterName} {number}：sentinel parallel-syncsは、フェイルオーバー後のスレーブノードのレプリケーションに関連しています。これは、新しいマスターノードへのレプリケーション操作を毎回開始するスレーブノードの数を指定します。たとえば、マスターノードの切り替えが完了した後、新しいマスターノードへのレプリケーションを開始するスレーブノードが3つあるとします。parallel-syncs= 1の場合、スレーブノードは1つずつレプリケーションを開始します。parallel-syncs= 3の場合、次に3つのスレーブノードノードが一緒にコピーを開始します。

parallel-syncsの値が大きいほど、スレーブノードはレプリケーションを完了しますが、マスターノードのネットワーク負荷とハードディスク負荷へのプレッシャーは大きくなります。実際の状況に応じて設定する必要があります。たとえば、マスターノードの負荷が低く、スレーブノードのサービス可用性に対する要件が高い場合は、並列同期の値を適切に増やすことができます。parallel-syncsのデフォルト値は1です。
sentinel failover-timeout {masterName} {time}：センチネルフェイルオーバータイムアウトはフェイルオーバータイムアウトの判断に関連していますが、このパラメーターはフェイルオーバーフェーズ全体のタイムアウトではなく、いくつかのサブフェーズのタイムアウトを判断するために使用されます。たとえば、マスターノードがスレーブノードをプロモートする場合タイムアウトを超える、またはスレーブノード新しいマスターノードがレプリケーション操作を開始する時間（データレプリケーションの時間を含まない）がタイムアウトを超えると、フェイルオーバーが時間の経過とともにフェイルオーバーします。

フェイルオーバータイムアウトのデフォルト値は180000、つまり180秒です。タイムアウトすると、次回は値が2倍になります。

上記のパラメータに加えて、セキュリティ検証に関連するパラメータなど、ここでは紹介されていないパラメータがいくつかあります。

2.練習の提案

センチネルノードの数は複数にする必要があります。一方では、センチネルノードの冗長性を高めて、センチネル自体が高可用性のボトルネックになるのを防ぎます。他方では、オフラインの誤判断を減らします。さらに、これらの異なるセンチネルノードは異なる物理マシンに展開する必要があります。
センチネルノードの数は奇数にする必要があります。これは、センチネルが投票を通じて「決定」を行うのに便利です。リーダー選出の決定、オフラインでの目的の決定などです。
各センチネルノードの構成は、ハードウェア、パラメーターなどを含めて一貫している必要があります。さらに、すべてのノードはntpまたは同様のサービスを使用して、時間が正確で一貫していることを確認する必要があります。
センチネルの構成プロバイダーおよび通知クライアント機能では、前述のJedisなど、クライアントのサポートを実装する必要があります。開発者が使用するライブラリが対応するサポートを提供しない場合、開発者は自分で実装する必要があります。
センチネルシステムのノードがdocker（またはポートマッピングを実行する可能性のある他のソフトウェア）にデプロイされている場合、センチネルの作業は通信に基づいているため、センチネルシステムが正しく機能しない原因となる可能性があるポートマッピングに特別な注意を払う必要があります他のノードとの接続、およびdockerのポートマッピングにより、歩哨が他のノードに接続できない場合があります。たとえば、センチネルは宣言されたIPとポートに応じて、お互いを検出します。センチネルAがポートマップドッカーにデプロイされている場合、他のセンチネルはAによって宣言されたポートを使用してAに接続できません。

6、まとめ

この記事では、最初にセンチネルの役割（監視、フェイルオーバー、構成プロバイダー、通知）を紹介し、次にセンチネルシステムの展開方法と、クライアントを介してセンチネルシステムにアクセスする方法について説明し、次に、センチネルの基本原則について簡単に説明します。歩哨の実装;最後に歩哨の実践に関するいくつかの提案が与えられます。

マスタースレーブレプリケーションに基づいて、Sentinelはマスターノードの自動フェイルオーバーを導入します。これにより、Redisの高可用性がさらに向上しますが、Sentinelの欠点も明らかです。Sentinelは、読み取りと書き込みの分離でスレーブノードを自動的にフェイルオーバーできません。シナリオ、スレーブノードに障害が発生すると、読み取りサービスが使用できなくなり、スレーブノードで追加の監視および切り替え操作を実行する必要があります。

さらに、Sentinelは、書き込み操作を負荷分散できず、ストレージ容量が1台のマシンで制限されるという問題をまだ解決していません。これらの問題を解決するには、クラスターを使用する必要があります。これについては、後の記事で紹介します。