Redis クラスターと拡張の詳細な図による説明

この記事では、Redis に関する関連知識を提供します。主にクラスタリングと拡張に関連する問題が整理されています。高可用性を実現する通常の方法は、データベースの複数のコピーをコピーして、別のサーバーにデプロイすることです。 , そのうちの 1 つが障害を起こしても、サービスの提供を継続できます。高可用性を実現するには、マスター/スレーブ モード、センチネル モード、クラスター モードの 3 つの展開モードがあります。一緒に見てみましょう。みんなの役に立つように。

推奨学習: Redis ビデオ チュートリアル

Redis の高可用性

1. 高可用性が必要な理由

• 単一障害点によりクラスター全体が使用できなくなることを防止します
• 一般的なプラクティス高可用性を実現するには、データベースの複数のコピーをコピーし、それらを異なるサーバーにデプロイします。そのうちの 1 つがハングアップしても、サービスを提供し続けることができます。
• Redis には、高可用性を実現するための 3 つのデプロイメント モードがあります。 マスター スレーブ モード、センチネル モード、クラスター モード

2. マスター スレーブ モード

• マスター ノードは読み取りと書き込み操作
• を担当します スレーブノードは、読み取り操作のみを担当します
• データスレーブ ノードの情報はマスター ノード から取得され、実装原則は マスター/スレーブ レプリケーション メカニズム
• マスター/スレーブ レプリケーションには フル レプリケーションと増分レプリケーションが含まれます2 種類
• ##スレーブがマスターに初めて接続を開始するとき、または最初とみなされるとき 各接続でフル レプリケーションが使用されます
  ##スレーブがマスターと完全に同期した後、マスター上のデータが再度更新されると、増分レプリケーションがトリガーされます
• 
  #3. センチネル モード

マスター/スレーブ モードでは、障害によりマスター ノードがサービスを提供できなくなると、スレーブ ノードからマスター ノードに手動で昇格する必要があります。同時に, アプリケーション側にマスター ノード アドレスを更新するように通知する必要があります. 明らかに, ほとんどのビジネス シナリオではこの障害処理方法を受け入れることができません. Redis は、2.8 以降、この問題を解決するために Redis Sentinel (Sentinel) アーキテクチャを正式に提供しています。

Sentinel モード 1 つ以上の Sentinel インスタンスで構成される Sentinel システムであり、すべての Redis マスター ノードとスレーブ ノード

を監視し、監視対象の

マスター ノードがオフラインになったときにオフライン マスターを自動的に削除できます。サーバー配下のスレーブ ノードが新しいマスター ノードにアップグレードされます
• ただし、センチネル プロセスが Redis ノードを監視している場合、問題 (単一点) が発生する可能性があるため、複数のセンチネルがRedis ノードが監視され、各センチネルも監視されます簡単に言うと、センチネル モードには 3 つの機能があります

• 1.发送命令，等待Redis服务器(包括主服务器和从服务器)返回监控其运行状态
  2.哨兵监测到主节点宕机会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点修改配置文件，让它们切换主机
  3.哨兵之间还会相互监控，从而达到高可用

  
  フォールト切り替えプロセスは次のとおりです。

• 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线
  当后面的哨兵也检测到主服务器不可用并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作
  切换成功后通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线
  这样对于客户端而言，一切都是透明的

Sentinel 動作モード

• 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个PING命令
  如果实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线
  如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态
  当有足够数量的Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线
  一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有Master，Slave发送INFO命令
  当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次
  若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除；若Master重新向Sentinel的PING命令返回有效回复，Master 的主观下线状态就会被移除

4.クラスター クラスター モード

• Sentinel モードはマスターに基づいています-slaveモードは、読み書き分離を実現し、自動切り替えも可能でシステムの可用性が高いですが、各ノードに格納されるデータが同一で​​あるためメモリを無駄に消費し、オンラインでの拡張が容易ではないため、Clusterクラスタが登場しました。

Cluster クラスター

は、Redis

の分散ストレージを実装し、データをシャード化します。つまり、

各 Redis ノードに異なるコンテンツを保存します
• 、to
オンライン拡張の問題を解決します
• 、また、レプリケーションとフェイルオーバー機能も提供しますRedis Cluster クラスターは Gossip プロトコルを介して通信します,ノード間で情報を継続的に交換します。交換される情報には、ノードの障害、新しいノードの参加、マスター/スレーブ ノードの変更情報、スロット情報などが含まれます。 一般的に使用されるゴシップ メッセージは、ping、pong、meet、fail## です。
#

ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息
meet消息：通知新节点加入，消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换
pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信；pong消息内部封装了自身状态数据，节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新
fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态

ハッシュ スロット スロット アルゴリズム

既然是分布式存储，Cluster集群使用的分布式算法是一致性Hash嘛？并不是，而是Hash Slot插槽算法
插槽算法把整个数据库被分为16384个slot(槽)，每个进入Redis的键值对根据key进行散列，分配到这16384插槽中的一个
使用的哈希映射也比较简单，用CRC16算法计算出一个16位的值，再对16384取模，数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽
集群中的每个节点负责一部分的hash槽，比如当前集群有A、B、C个节点，每个节点上的哈希槽数 =16384/3，那么就有：
	节点A负责0~5460号哈希槽
	节点B负责5461~10922号哈希槽
	节点C负责10923~16383号哈希槽Redis Cluster集群中，需要确保16384个槽对应的node都正常工作，如果某个node出现故障，它负责的slot也会失效，整个集群将不能工作
为了保证高可用，Cluster集群引入了主从复制，一个主节点对应一个或者多个从节点，当其它主节点ping一个主节点A时，如果半数以上的主节点与 A通信超时，那么认为主节点A宕机，如果主节点宕机时，就会启用从节点Redis的每一个节点上都有两个玩意，一个是插槽slot(0~16383)，另外一个是cluster，可以理解为一个集群管理的插件，当我们存取的key到达时，Redis会根据Hash Slot插槽算法取到编号在0~16383之间的哈希槽，通过这个值去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

5. 高可用性実現後のフェイルオーバーの問題

• 主観的オフライン
: ノードは、他のノードが利用できない、つまりオフラインであると考えています。この状態は最終的な障害判定ではありません。これは 1 つのノードの意見のみを表すことができます。誤った判断が存在する可能性があります。

• Objective offline: ノードを真にオフラインであるとマークします。クラスター内の複数のノードは、そのノードが利用できないと見なすため、合意に達します。スロットを保持しているマスター ノードに障害が発生した場合、フェールオーバーを実行する必要があります。ノード
  
• 障害復旧: 障害が発見された後、オフライン ノードがマスター ノードの場合は、そのスレーブ ノードから代替ノードを選択する必要があります。クラスターの高可用性を確保するために使用されます
  
#Redis 分散ロックによって引き起こされる一連の問題とその解決策
• ##1.Redisson
  分散ロックには問題がある可能性があります有効期限が切れるとロックが解放され、ビジネスが完了しません

この問題を解決するには、ロックの有効期限を長く設定できますか?それは明らかに良くありません。ビジネスの実行時間は不確実です。

Redisson は、ロックを取得するスレッドに対して時限デーモン スレッドを開くことで、この問題を解決します。ロックが存在するかどうかを時々チェックします。ロックの有効期限切れと早期解放を防ぐための有効期限

2.Redlock アルゴリズム

• スレッド 1 は Redis マスター ノードのロックを取得しましたが、ロックされたキーはまだスレーブ ノードに同期されていません。このとき、マスター ノードに障害が発生し、スレーブ ノードがマスター ノードにアップグレードされ、スレッド 2 は同じキーのロックを取得できますが、スレッド 1 もロックを取得しており、ロックのセキュリティは失われます。
  
• #Redlockこの問題を解決するには、複数の Redis マスターをデプロイして、同時にダウンしないようにします。これらのマスター ノードは 完全に動作します。相互に独立しています, 相互間にデータ同期はありません実装手順は次のとおりです
  

MySQL と Redis が二重書き込みの一貫性を確保する方法

1. 遅延を同時に二重削除する

データベースを更新した後、しばらくスリープを遅らせてからキャッシュを削除します
• この解決策は問題ありません。スリープ期間に限り、ダーティ データが存在する可能性があり、一般のビジネスで受け入れられます。
• しかし、キャッシュの削除が 2 回目に失敗した場合はどうすればよいでしょうか?キャッシュとデータベース内のデータは依然として不整合である可能性があります。
• キーに自然な有効期限を設定し、自動的に期限切れになるようにしてはどうでしょうか?有効期限内に企業が受け入れたデータに矛盾がある場合はどうすればよいですか?他にもより良い解決策があります
• 
  

2. キャッシュの削除再試行メカニズム

遅延した二重削除により、キャッシュ削除の 2 番目のステップが失敗する可能性があります。その結果、データの不整合の問題が発生します。
• 削除に失敗した場合は、数回削除してキャッシュの削除が確実に成功するようにしてください。これにより、
• 削除キャッシュの再試行メカニズムを導入できます
  
#3. biglog の読み取りとキャッシュの非同期削除

キャッシュ メカニズムの削除を再試行すると、多くのビジネス コード侵入が発生するため、biglog の読み取りと非同期削除を導入しました。キャッシュ

• 
  
推奨される学習:

Redis ビデオ チュートリアル

以上がRedis クラスターと拡張の詳細な図による説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。