Redis センチネル メカニズムの原理の紹介 (画像とテキスト)

この記事の内容は、誰もがセンチネル機構の原理とその実装方法を理解できるように、Redis のセンチネル機構を紹介することです。一定の参考値があるので、困っている友達は参考にしていただければ幸いです。

概要

Redis レプリケーションには欠点があり、ホスト マスターがダウンした場合は、解決する必要があります。誰もいないスレーブを使用するなど、手動で切り替えます。実際には、マスター/スレーブ レプリケーションは実装されていません。高可用性はバックアップ マシンに重点を置き、クラスター内のシステムの冗長性を使用します。システム内のマシンが損傷した場合、他のバックアップ マシンがすぐにそれを引き継いでサービスを開始できます。 。

マスター/スレーブ レプリケーションの問題

マスター ノードがダウンすると、書き込みサービスが利用できなくなります。使用する場合は、手動で切り替えてマスターノードを再選択し、手動で主従関係を設定する必要があります。

それでは、どうやって解決すればいいのでしょうか?各マシンの状態を監視し、タイムリーに調整できる監視プログラムがあれば、手動操作が自動操作に変わります。 Sentinelの登場はこの問題を解決するものです。

#センチネル メカニズムの原理と実装

#Redis Sentinel Redis Sentinel は、複数の Sentinel ノードと Redis データ ノードを含む分散アーキテクチャです。各 Sentinel ノードは、データ ノードと他の Sentinel ノードを監視します。ノードが到達不能であることが判明すると、ノードをオフラインとしてマークします。識別されたマスター ノードがマスター ノードである場合、他の Sentinel ノードとも「ネゴシエート」します。ほとんどの Sentinel ノードがマスター ノードに到達できないと判断した場合、自動フェイルオーバーを完了するために Sentinel ノードを選択し、同時に、Sentinel ノードに通知します。この変更は Redis アプリケーション側でリアルタイムに行われます。プロセス全体は完全に自動であり、手動介入を必要としないため、このソリューションは Redis の高可用性の問題を効果的に解決します。

#図に示すように:

#基本的なフェイルオーバー プロセス

#1) マスターノードに障害が発生すると、2 つのスレーブノードがマスターノードとの接続を失い、マスター/スレーブレプリケーションが失敗します。

2) 各 Sentinel ノードは、定期的な監視を通じてマスター ノードに障害が発生したことを検出します。

3) 複数の Sentinel各ノードはプライマリ ノードの障害に同意し、フェイルオーバーを担当するリーダーとしてノードの 1 つを選択します。

#4) Sentinel リーダー ノードがフェイルオーバーを実行しました。プロセス全体は基本的に手動調整と同じですが、自動的に完了します。

5) フェイルオーバー後、Redis Sentinel 構造全体が新しいマスター ノードを再選択しました。

#インスタンス

Docker を使用して次の Redis コンテナーを作成します

redis-sentinel1    172.10.0.9    22530 -> 22530    sentinel
redis-sentinel2    172.10.0.10    22531 -> 6379    sentinel
redis-sentinel3    172.10.0.11    22532 -> 6379    sentinel
redis-master2    172.10.0.5    6383  -> 6379    Master
redis-slave2    172.10.0.6    6384  -> 6379    Slave
redis-slave3    172.10.0.7    6385  -> 6379    Slave

Configuration

Sentinel のコア構成

sentinel monitor mymaster 127.0.0.1 7000 2

監視対象のマスター ノードの名前、IP、およびポート最後の 2 は、見つかった Sentinel の数を意味します。たとえば、構成が 2 の場合、少なくとも 2 つの Sentinel ノードがマスター ノードに到達不能であると認識していることを意味するため、この到達不能の判断は客観的です。設定が小さいほど、オフライン レベルに到達するための条件は緩くなり、その逆も同様です。通常は、Sentinel ノードの半分に 1 を加えた値に設定することをお勧めします。

sentinel down-after-millseconds mymaster 30000

タイムアウト(単位:ミリ秒)です。たとえば、マシンに ping を実行し、時間が経っても ping ができない場合、それは問題があるとみなされます。

sentinel parallel-syncs mymaster 1

当 Sentinel 节点集合对主节点故障判定达成一致时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs 就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数，指出 Sentinel 属于并发还是串行。1代表每次只能复制一个，可以减轻 Master 的压力。

sentinel auth-pass <master-name> <password></password></master-name>

如果 Sentinel 监控的主节点配置了密码，sentinel auth-pass 配置通过添加主节点的密码，防止 Sentinel 节点对主节点无法监控。

sentinel failover-timeout mymaster 180000

表示故障转移的时间。

技巧

1）Sentinel 节点不应该部署在一台物理“机器”上。

这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。

2）部署至少三个且奇数个的 Sentinel 节点。

3个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。

【相关文章】

Redis主从复制的原理介绍（图文）

以上就是本篇文章的全部内容，希望能对大家的学习有所帮助。更多精彩内容大家可以关注php中文网相关教程栏目！！！

以上がRedis センチネル メカニズムの原理の紹介 (画像とテキスト)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。