この記事では、関数アーキテクチャ、デプロイ、構成に関する問題など、Redis の高可用性センチネルに関する関連知識を提供します。皆様のお役に立てれば幸いです。
推奨学習: Redis ビデオ チュートリアル
Sentinel を紹介する前に、まず Redis の高可用性に関連するテクノロジーをマクロの観点から確認してみましょう。それらには、永続性、レプリケーション、センチネル、クラスターが含まれます。それらの主な機能と解決される問題は次のとおりです:
見張りについて話しましょう。
Redis Sentinel、Redis Sentinel は、Redis バージョン 2.8 で導入されました。 Sentinel の中核機能は、マスター ノードの自動フェイルオーバーです。 以下は Redis 公式ドキュメントの Sentinel 機能の説明です:
このうち、監視機能と自動フェイルオーバー機能により、Sentinel はマスター ノードの障害を適時に検出して転送を完了できますが、構成プロバイダーと通知機能はクライアントとの対話に反映する必要があります。
記事内での「クライアント」という言葉の使用方法について説明します。 前の記事では、API を介して Redis サーバーにアクセスする限り、redis サーバーも含めてクライアントと呼ばれます。 cli と Java クライアント。Jedis など。区別と説明を容易にするために、この記事のクライアントには redis-cli は含まれていませんが、redis-cli よりも複雑です。redis-cli は、redis によって提供される基盤となるインターフェイスを使用します。一方、クライアントは、Sentinel の構成プロバイダーと通知機能を最大限に活用するために、カプセル化されたこれらのインターフェイスと関数を使用します。
典型的なセンチネル アーキテクチャ図は次のとおりです:
これは、センチネル ノードとデータ ノード :
このパートでは、1 つのマスター ノード、2 つのスレーブ ノード、3 つのセンチネル ノードを含む単純なセンチネル システムをデプロイします。便宜上、これらすべてのノードは 1 台のマシン (LAN IP: 192.168.92.128) に展開され、ポート番号で区別され、ノードの構成は可能な限り簡素化されています。
Sentinel システムのマスター/スレーブ ノードは、通常のマスター/スレーブ ノードと同じように構成されており、追加の構成は必要ありません。以下にマスターノード (ポート=6379) と 2 つのスレーブノード (ポート=6380/6381) の設定ファイルを示しますが、構成は比較的単純なので詳細な説明は省略します。
#redis-6379.conf port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" #redis-6380.conf port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" slaveof 192.168.92.128 6379 #redis-6381.conf port 6381 daemonize yes logfile "6381.log" dbfilename "dump-6381.rdb" slaveof 192.168.92.128 6379
redis-server redis-6379.conf redis-server redis-6380.conf redis-server redis-6381.conf
ノード起動後、マスターノードに接続し、マスター/スレーブの状態が正常か確認してください。構成が完了したら、マスター ノードとスレーブ ノードを順番に起動します:
センチネル ノードは本質的に特別な Redis ノードです。
3 つのセンチネル ノードの構成はほぼ同じです。主な違いはポート番号 (26379/26380/26381) です。以下では、26379 ノードを例として構成と起動方法を紹介します。ノードの構成部分は可能な限り簡略化されており、詳細な構成は後で紹介します。
#sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" sentinel monitor mymaster 192.168.92.128 6379 2
哨兵节点的启动有两种方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。
redis-sentinel sentinel-26379.conf redis-server sentinel-26379.conf --sentinel
3. 总结
按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证
哨兵系统的搭建过程，有几点需要注意：
（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
（2）哨兵节点本质上是redis节点。
（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。
上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。
在介绍客户端的原理之前，先以Java客户端Jedis为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作（代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）。
public static void testSentinel() throws Exception {
String masterName = "mymaster";
Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.92.128:26379");
sentinels.add("192.168.92.128:26380");
sentinels.add("192.168.92.128:26381");
JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
Jedis jedis = pool.getResource();
jedis.set("key1", "value1");
pool.close();
}在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在JedisSentinelPool的构造器中，进行了相关的工作；主要包括以下两点：
（1）遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点+masterName获得主节点的信息；该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现，该命令示例如下：
一旦获得主节点信息，停止遍历（因此一般来说遍历到第一个哨兵节点，循环就停止了）。
（2）增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用redis提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的+switch-master频道，当收到消息时，重新初始化连接池。
通过客户端原理的介绍，可以加深对哨兵功能的理解：
（1）配置提供者：客户端可以通过哨兵节点+masterName获取主节点信息，在这里哨兵起到的作用就是配置提供者。
需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求(如set/get)会直接发向主节点；如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。
举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：
sentinel monitor mymaster 192.168.92.128 6379 2 改为 sentinel monitor mymaster 127.0.0.1 6379 2
（2）通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为127.0.0.1:6379，客户端会向127.0.0.1:6379建立redis连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。
前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。
Sentinel ノードは特別なモードで実行される Redis ノードとして、通常の Redis ノードとは異なるコマンドをサポートします。運用と保守では、これらのコマンドを使用して Sentinel システムのクエリや変更を行うことができますが、より重要なのは、Sentinel システムが障害検出やフェイルオーバーなどのさまざまな機能を実装するために、Sentinel ノード間の通信と切り離せないことです。通信は非常に複雑です。そのほとんどは、センチネル ノードによってサポートされるコマンドを通じて実現されます。以下にセンチネルノードがサポートする主なコマンドを紹介します。
(1) 基本クエリ: これらのコマンドを通じて、Sentinel システムのトポロジ、ノード情報、構成情報などをクエリできます。
(2) マスターノードの監視の追加/削除
センチネル監視mymaster2 192.168.92.128 16379 2: この機能は、センチネル ノードをデプロイする際の設定ファイル内のセンチネル モニター機能とまったく同じであるため、詳細な説明は省略します。
sentinel Remove mymaster2: 監視をキャンセルします。現在のセンチネル ノードによるマスター ノード mymaster2
(3) 強制フェイルオーバー
センチネル フェイルオーバー mymaster: このコマンドは、mymaster# でフェイルオーバーを強制的に実行できます。 ##, 現在のマスターノードが正常に稼働している場合でも、たとえば、現在のマスターノードが配置されているマシンが廃棄されそうになっている場合、failover コマンドを使用して事前にフェイルオーバーを実行できます。 2. 基本原則
(1) スケジュールされたタスク: 各センチネル ノードは 3 つのスケジュールされたタスクを維持します。スケジュールされたタスクの機能は、マスタースレーブノードにinfoコマンドを送信して最新のマスタースレーブ構造を取得、パブリッシュ＆サブスクライブ機能により他のセンチネルノードの情報を取得、pingを送信してハートビート検出を実行します。他のノードにコマンドを送信して、それらがオフラインかどうかを判断します。
(2) 主観的オフライン: ハートビート検出のスケジュールされたタスクにおいて、他のノードが一定時間応答しない場合、センチネル ノードはそれらを主観的にオフラインにします。名前が示すように、主観的オフラインとはセンチネル ノードが「主観的に」オフラインを判断することを意味し、主観的オフラインに相当するのは客観的オフラインです。
(3) オフラインの目的: センチネル ノードがマスター ノードから主観的にログオフした後、センチネル is-master-down-by-addr コマンドを通じて他のセンチネル ノードにマスター ノードのステータスを問い合わせます。マスターノード上でオフラインになったセンチネルの数が一定の値に達すると、マスターノードは客観的にオフラインになります。
目標オフラインはマスター ノードにのみ存在する概念であることに注意してください。スレーブ ノードとセンチネル ノードに障害が発生した場合、センチネルによって主観的にオフラインになった後は、その後の目標オフラインは存在しません。 . ラインとフェイルオーバー操作。(4) リーダー センチネル ノードの選出: マスター ノードが客観的にオフラインであると判断されると、各センチネル ノードはリーダー センチネル ノードを選出するためにネゴシエートし、リーダー ノードはフェイルオーバー操作を実行します。
マスター ノードを監視しているすべてのセンチネルがリーダーとして選出される可能性があります。選出に使用されるアルゴリズムは Raft アルゴリズムです。Raft アルゴリズムの基本的な考え方は、早い者勝ちです。選挙の 1 ラウンド、センチネル A リーダーになる申請書を B に送信します。B が他のセンチネルに同意していない場合は、A がリーダーになることに同意します。選挙の具体的なプロセスについてはここでは詳しく説明しませんが、一般的に言えば、センチネルの選出プロセスは非常に速く、オフラインで最初に目標を達成した人が通常リーダーになります。
(5) フェイルオーバー: 選出されたリーダー センチネルはフェイルオーバー操作を開始します。これは大きく 3 つのステップに分けることができます:
新しいスレーブ ノードを選択します。 マスター ノード: 選択の原則は次のとおりです。最初に異常なスレーブ ノードをフィルタリングして除外します。次に、最高の優先順位 (slave-priority で指定) を持つスレーブ ノードを選択します。優先順位を区別できない場合は、レプリケーション オフセットが最大のスレーブ ノードを選択します。それでも区別できない場合は、最小の runid を持つスレーブ ノード。(1) センチネル モニター {masterName} {masterIp} {masterPort} {quorum}
センチネル モニターはセンチネルのコア構成です。前回のセンチネル ノードのデプロイ時に説明しました。そのうち、masterName はマスター ノード名を指定し、masterIp と masterPort はマスター ノードのアドレスを指定します。クォーラムはマスター ノードのオフラインの目標を決定するセンチネル 数量しきい値: マスター ノードがオフラインであると決定するセンチネルの数がクォーラムに達すると、マスター ノードは客観的にオフラインになります。推奨値は、センチネルの数の半分に 1 を加えた値です。
(2) センチネル ダウンアフター ミリ秒 {マスター名} {時間}
センチネル ダウンアフター ミリ秒は主観的なオフラインの判断に関連しています。センチネルは ping コマンドを使用して実行します。他のノードのハートビート検出。ダウンアフターミリ秒で設定された時間が経過しても他のノードが応答しない場合、Sentinel は主観的にそれらのノードをオフラインにします。この構成は、マスター ノード、スレーブ ノード、センチネル ノードの主観的なオフラインの決定に有効です。
ダウンアフターミリ秒のデフォルト値は 30000、つまり 30 秒です。さまざまなネットワーク環境やアプリケーション要件に応じて調整できます。値が大きいほど、主観的なオフラインの判断が緩くなり、利点が得られます。は判断ミスである可能性は低いですが、障害発見やフェイルオーバーに時間がかかり、クライアントの待ち時間も長くなってしまうデメリットがあります。たとえば、アプリケーションに高可用性要件がある場合は、障害が発生したときにできるだけ早く転送を完了するために値を適切に下げることができます。また、ネットワーク環境が比較的劣悪な場合は、頻繁な誤判断を避けるためにしきい値を適切に増やすことができます。
(3) SentinelParallel-syncs {masterName} {number}
sentinelParallel-syncs は、フェイルオーバー後のスレーブ ノードのレプリケーションに関連しています。これは、レプリケーションが開始されるたびに、次のように指定します。新しいマスター ノード レプリケーション操作のスレーブ ノードの数。たとえば、マスター ノードの切り替えが完了した後、3 つのスレーブ ノードが新しいマスター ノードへのレプリケーションを開始したいとします。Parallel-syncs=1 の場合、スレーブ ノードは 1 つずつレプリケーションを開始します。Parallel-syncs=3 の場合、次に 3 つのスレーブ ノード ノードは一緒に複製を開始します。
Parallel-syncs の値が大きいほど、スレーブ ノードがレプリケーションを完了するまでの時間が速くなりますが、マスター ノードのネットワーク負荷とハードディスク負荷への負荷が大きくなります。それに応じて設定する必要があります。実際の状況に。たとえば、マスター ノードの負荷が低く、スレーブ ノードのサービス可用性要件が高い場合は、Parallel-syncs 値を適切に増やすことができます。並列同期のデフォルト値は 1 です。
(4) Sentinel fadeover-timeout {masterName} {time}
sentinel fadeover-timeout はフェイルオーバーのタイムアウトの判定に関係しますが、このパラメータはフェイルオーバーのタイムアウトの判定には使用されません。フェイルオーバー フェーズ全体、ただしそのサブステージのいくつかでタイムアウトが発生します。たとえば、マスター ノードがスレーブ ノードを昇格させる時間がタイムアウトを超えた場合、またはスレーブ ノードが新しいマスターへのレプリケーション操作を開始する時間を超えた場合などです。ノード (データのコピー時間を除く) がタイムアウトを超えると、フェイルオーバー タイムアウトが発生します。
failover-timeout のデフォルト値は 180000、つまり 180 秒です。タイムアウトすると、次回は元の値の 2 倍になります。
(5) 上記パラメータ以外にも、セキュリティ検証に関するパラメータなど、ここでは紹介しませんがいくつかのパラメータがあります。
(1) センチネル ノードの数は複数である必要がありますが、一方ではセンチネル ノードの冗長性を高めてセンチネル自体の負荷が高くなるのを防ぎます。 -可用性のボトルネック、一方でセンチネルノードの数が減少する オフラインでの誤った判断。さらに、これらの異なるセンチネル ノードは異なる物理マシンに展開する必要があります。
(2) センチネル ノードの数は、センチネルが投票を通じて「決定」(リーダー選出に関する決定、オフラインでの目標に関する決定など) を行えるようにするために、奇数である必要があります。
(3) 各センチネル ノードの構成は、ハードウェア、パラメータなどを含め、一貫している必要があります。また、正確で一貫した時刻を保証するために、すべてのノードが ntp または同様のサービスを使用する必要があります。
(4) Sentinel の構成プロバイダーと通知クライアント機能には、前述の Jedis などのクライアント サポートを実装する必要があります。開発者が使用するライブラリが対応するサポートを提供していない場合、開発者は自分で実装する必要がある場合があります。
(5) Sentinel システムのノードが Docker (またはポート マッピングを実行する可能性のあるその他のソフトウェア) にデプロイされている場合、ポート マッピングによって Sentinel システムが失敗する可能性があるという事実に特別な注意を払う必要があります。 Sentinel の動作は他のノードとの通信に基づいており、Docker のポート マッピングにより Sentinel が他のノードに接続できなくなる可能性があるため、正常に動作します。たとえば、センチネルによる相互の検出は、センチネルが外部に宣言した IP とポートに依存します。センチネル A がポート マッピングを使用して Docker にデプロイされている場合、他のセンチネルは、A によって宣言されたポートを使用して A に接続できません。
この記事では、まず Sentinel の役割 (監視、フェイルオーバー、構成プロバイダー、通知) を紹介し、次に Sentinel システムの展開方法とクライアント メソッドを介した Sentinel システムへのアクセスについて説明します。次に、センチネル実装の基本原則を簡単に説明し、最後にセンチネルの実践に関するいくつかの提案を示します。
マスター/スレーブ レプリケーションに基づいて、Sentinel はマスター ノードの自動フェイルオーバーを導入し、Redis の高可用性をさらに向上させますが、Sentinel の欠点も明らかです: Sentinel はスレーブ ノードを自動的にフェイルオーバーできません。読み書き分離シナリオでは、スレーブ ノードに障害が発生すると読み取りサービスが利用できなくなるため、スレーブ ノードで追加の監視と切り替え操作を実行する必要があります。
さらに、Sentinel は、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題をまだ解決していません。これらの問題を解決するには、クラスターの使用が必要です。これについては、後で紹介します。後の記事です。ご注目ください。
推奨学習: 「Redis ビデオ チュートリアル 」、「2022 年の最新 Redis 面接の質問と回答 」
以上がRedis Advanced Learning 高可用性 Sentinel (概要共有)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。