Redis のスタンドアロン、マスター/スレーブ、センチネル、クラスター モードをすぐに理解する

この記事では、Redis の 4 つのモード (スタンドアロン、マスター/スレーブ、センチネル、クラスター) について説明します。一定の参考値があるので、困っている友達が参考になれば幸いです。

#コードを減らして髪を増やす

入社して最初の週に騙されました

私は最近新しい会社に入社したばかりです。最初は、新しい会社に初めて来たときは、通常、会社の同僚と知り合いになり、グループ内のエンジニアリング ドキュメントを見て、いくつかのドキュメントを見つけるだろうと思っていました。自分で練習するためのデモ。

咳咳咳、まったく予想していませんでした、すべては私が思っていた通りです、私はまだ

若すぎます。

私が参加した日の午後、チームリーダーは私にいくつかの文書を投げつけ、これらのプロジェクトのキャッシュシステムの問題を調べて、redis をセンチネルモードにアップグレードするように求めました。

ミッションを受けたとき、私は内心混乱しました。

#第一に、どのような種類のサービスが Redis を使用しているのかわかりません。

2 番目に、redis の使用方法がわかりません。

3 番目に、redis がハングした場合、ユーザーに影響はありますか?

4 番目に、私は Redis をまったく使用したことがありません。

これまでやったことがありませんが、

怖くないです。結局のところ、 が と同じ作業を毎日行うと、何か問題が発生し、すぐに最適化されます。

ソーシャルリクルーティングとスクールリクルーティングはまだ違うようで、スクールリクルーティングでは導入研修や新人クラスが行われます。

こうした教育を通じて、まず会社の文化や価値観を理解し、次に仕事のプロセスを学び、会社の技術的な雰囲気を感じてください。

タスク

部門内のすべての Redis サービスを

Sentinel モードにアップグレードします。 [関連する推奨事項: Redis ビデオ チュートリアル ]

redis の複数のモード

これらはいずれも Sentinel モードへのアップグレードについて言及していますが、以前に使用されていたのはセントリーモードではありません。間違いなく他のモードがあります。

シングルマシン モード、マスター/スレーブ モード、センチネル モード、クラスター モード

シングルマシン モード

これは最も単純で、次のことが可能です。一目でわかります。

Redis をインストールして起動し、企業に電話するだけです。特定のインストール手順と起動手順については詳しく説明しません。オンラインで検索してください。

単一マシンは、高可用性が必ずしも保証されていない状況など、多くのシナリオでも使用されます。

ああ、咳、咳、実際、私たちのサービスは Redis スタンドアロン モードを使用しているので、センチネル モードに変更しましょう。

単一マシンの

利点と欠点 について話しましょう。

利点:

導入が簡単、コストはゼロ。
• 低コスト、予備ノードなし、その他の費用は不要です。
• 高性能で、単一マシン上でデータを同期する必要がなく、データは自然に一貫しています。

欠点:

信頼性の保証はあまり良くなく、単一ノードでダウンタイムが発生するリスクがあります。
• 単一マシンの高いパフォーマンスは CPU の処理能力によって制限され、redis はシングルスレッドです。

スタンドアロン モードの選択は、独自のビジネス シナリオに基づいて行う必要があります。高いパフォーマンスと信頼性が必要な場合、スタンドアロン モードは適していません。

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

マスター/スレーブ レプリケーションとは、1 つの Redis サーバーから他の Redis サーバーにデータをコピーすることを指します。

前者をマスター ノード (master)、後者をスレーブ ノード (スレーブ) と呼び、データの複製は一方向であり、マスター ノードからスレーブ ノードへのみ可能です。

# マスター/スレーブ モードの設定は非常に簡単で、スレーブ ノードでマスター ノードの IP アドレスとポート番号を設定するだけです。

slaveof <masterip> <masterport>
# 例如
# slaveof 192.168.1.214 6379</masterport></masterip>

マスター-スレーブノードのすべてのサービスを開始し、ログを確認して、マスター-スレーブノード間のサービス接続を確認します。

上記から問題を考えると簡単ですが、マスター/スレーブ レプリケーションではマスターとスレーブのデータが同じであるため、データの冗長性の問題が発生します。

プログラム設計では、高可用性と高パフォーマンスを実現するために冗長性が許可されています。システムを設計する際にはこの点を考慮し、会社のためにこのリソースを節約しないでください。

究極のユーザーエクスペリエンス

を追求する製品にとって、ダウンタイムは絶対に許されません。 マスター/スレーブ モデルは、多くのシステム設計で考慮されています。マスターは複数のスレーブ ノードにハングしています。マスター サービスがダウンすると、サービスを確保するために新しいマスター ノードが

選択されます

.高可用性。 マスター/スレーブ モードの利点:

マスター ノードが停止すると、
• スレーブ ノード

  を として使用できます。マスターノードのバックアップ。いつでも起動できます。

• プライマリ ノード

  の 読み取り機能を拡張して、プライマリ ノードの読み取り圧力を共有します。

高可用性の基礎: 上記の機能に加えて、マスター/スレーブ レプリケーションはセンチネル モードとクラスター モードの実装の基礎でもあります。 Redis の高可用性の基礎。

には、先ほど述べたデータ冗長性の問題など、対応する欠点もあります。

• マスター ノード がダウンすると、スレーブ ノード が マスター ノード に昇格します。同時に、アプリケーション側 の マスター ノード アドレス を変更する必要があり、すべて スレーブ ノード はコマンドが必要です。コピー 新しいマスター ノード、プロセス全体で 手動介入が必要です。
• マスター ノードの 書き込み機能は、単一マシンによって制限されます。
• マスター ノードの ストレージ容量は、単一マシンによって制限されます。

センチネル モード

先ほど述べたように、マスター/スレーブ モードでは、マスター ノードがダウンすると、スレーブ ノードがマスター ノードとして起動できます。マスターノードとしてサービスを提供し続けます。

しかし問題があります。マスター ノードの IP が変更されました。現時点では、アプリケーション サービスは依然として originalマスター ノードのアドレスを使用してアクセスします。これは...

したがって、Redis バージョン 2.8 が導入されたときに、センチネルの概念が登場しました。

Sentinel は、 レプリケーションに基づいて、自動化された障害復旧を実装します。

図に示すように、センチネル ノードはセンチネル ノードとデータ ノードの 2 つの部分で構成されます。

センチネル ノード:センチネル システムは 1 つ以上のセンチネル ノードで構成されますセンチネル ノードは、データを保存しない特別な Redis ノードです。

• データ ノード: マスター ノードとスレーブ ノードは両方ともデータ ノードです。
• Redis クラスターにアクセスされるすべてのデータはセンチネル クラスターを介して行われ、センチネルは Redis クラスター全体を監視します。

先ほど述べたマスター ノードがハングアップするなど、Redis クラスターに問題があることが判明すると、スレーブ ノードが起動します。ただし、マスター ノード アドレスが変更された場合、現時点ではアプリケーション サービスはそれを認識せず、センチネルはアプリケーション サービスと対話するため、アクセス アドレスを変更する必要はありません。

Sentinel はフェイルオーバーの問題を非常にうまく解決し、高可用性の点でより高いレベルに引き上げます。もちろん、Sentinel には他の機能もあります。

例:

マスターノード生存検出

、マスタースレーブ稼働状態検出、マスタースレーブ切り替え。 Sentinel for Redis の最小構成は、

1 つのマスターと 1 つのスレーブ

です。 センチネル モード監視の原理について話しましょう

各センチネルは、

すべての

メイン サーバー,# に 1 回の頻度でメッセージを送信します。 2 番目 ##サーバー および他の Sentinel インスタンス から PING コマンドを送信します。

PING コマンドに対する最後の有効な応答からの時間が、down-after-milliseconds で指定された値を超えた場合、このインスタンスには Sentinel によって # マークが付けられます。主観的なオフライン。

マスター サーバーが 主観的にオフライン

としてマークされている場合、このマスター サーバーを監視している

すべての Sentinel ノードは Once である必要がありますメインサーバーが実際に 主観的オフライン 状態になったかどうかを確認する 1 秒あたりの 頻度。 マスター サーバーが主観的にオフラインとしてマークされており、指定された 時間範囲内に 十分な数の Sentinel (少なくとも構成ファイルで指定された数) がある場合この判断に同意すると、メイン サーバーは

Objective offline

としてマークされます。 通常の状況では、各センチネルは、認識しているすべてのマスター サーバーとスレーブ サーバーに 10 秒ごとに INFO コマンドを送信します。 マスター サーバーが Sentinel によって 客観的にオフライン

としてマークされると、Sentinel がオフライン マスター サーバーのすべてのスレーブ サーバーに INFO コマンドを送信する頻度が 10 から変更されます。 1 秒に 1 回が 1 秒に 1 回に変更されました。

Sentinel は、

マスター ノード ステータスについて他の Sentinel と交渉します。マスター ノードが SDOWN` 状態にある場合、投票 により ## が自動的に選択されます。 # 新しいマスターノード。残りの

スレーブ ノード

が データ レプリケーション の 新しいプライマリ ノード を指すようにします。 メイン サーバーがオフラインになることに同意する十分なセンチネルがいない場合、メイン サーバーの 客観的オフライン ステータスは削除されます。 メイン サーバーが Sentinel の PING コマンドに対して有効な応答を返すと、メイン サーバーの 主観的オフライン ステータスは削除されます。

Sentinel モードの長所と短所利点:

Sentinel モードはマスター/スレーブ モードに基づいており、次のすべての利点があります。マスター/スレーブ、センチネルのすべてのモードが利用可能です。

マスターとスレーブを自動的に切り替えることができるため、システムの堅牢性と可用性が向上します。

Sentinel は、マスター サーバーとスレーブ サーバーが正常に動作しているかどうかを継続的にチェックします。監視対象の Redis サーバーで問題が発生すると、Sentinel は API スクリプトを通じて管理者または他のアプリケーションに通知を送信します。

欠点:
• • Redis较难支持在线扩容，对于集群，容量达到上限时在线扩容会变得很复杂。

  我的任务

  我部署的redis服务就如上图所示，三个哨兵节点，三个主从复制节点。

  使用java的jedis去访问我的redis服务，下面来一段简单的演示代码(并非工程里面的代码)：

  public static void testSentinel() throws Exception {
       //mastername从配置中获取或者环境变量，这里为了演示
           String masterName = "master";
           Set<String> sentinels = new HashSet<>();
       // sentinel的IP一般会从配置文件获取或者环境变量，这里为了演示
           sentinels.add("192.168.200,213:26379");
           sentinels.add("192.168.200.214:26380");
           sentinels.add("192.168.200.215:26381");
   
       //初始化过程做了很多工作
           JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); 
       //获取到redis的client
           Jedis jedis = pool.getResource();
       //写值到redis
           jedis.set("key1", "value1");
       //读取数据
       jedis.get("key1");
  }

  具体部署的配置文件这里太长了，需要的朋友可以公众号后台回复【redis配置】获取。

  听起来是入职第二天就部署了任务感觉很难的样子。

  其实现在看来是个so easy的任务，申请一个redis集群，自己配置下。在把工程里面使用到redis的地方改一下，之前使用的是一个两个单机节点。

  干完，收工。

  

  虽然领导的任务完成了，但并不意味着学习redis的路结束了。爱学习的龙叔，继续研究了下redis的集群模式。

  集群模式

  主从不能解决故障自动恢复问题，哨兵已经可以解决故障自动恢复了，那到底为啥还要集群模式呢？

  主从和哨兵都还有另外一些问题没有解决，单个节点的存储能力是有上限，访问能力是有上限的。

  Redis Cluster 集群模式具有 高可用、可扩展性、分布式、容错 等特性。

  Cluster 集群模式的原理

  通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能。

  之前的两种模式数据都是在一个节点上的，单个节点存储是存在上限的。集群模式就是把数据进行分片存储，当一个分片数据达到上限的时候，就分成多个分片。

  数据分片怎么分？

  集群的键空间被分割为16384个slots（即hash槽），通过hash的方式将数据分到不同的分片上的。

  HASH_SLOT = CRC16(key) & 16384 复制代码

  CRC16是一种循环校验算法，这里不是我们研究的重点，有兴趣可以看看。

  这里用了位运算得到取模结果，位运算的速度高于取模运算。

  

  有一个很重要的问题，为什么是分割为16384个槽？这个问题可能会被面试官随口一问
  

  数据分片之后怎么查，怎么写？

  

  读请求分配给slave节点，写请求分配给master，数据同步从master到slave节点。
  

  读写分离提高并发能力，增加高性能。

  如何做到水平扩展？

  

  master节点可以做扩充，数据迁移redis内部自动完成。

  当你新增一个master节点，需要做数据迁移，redis服务不需要下线。

  举个栗子：上面的有三个master节点，意味着redis的槽被分为三个段，假设三段分别是0~7000，7001~12000、12001~16383。

  现在因为业务需要新增了一个master节点，四个节点共同占有16384个槽。

  槽需要重新分配，数据也需要重新迁移，但是服务不需要下线。

  redis集群的重新分片由redis内部的管理软件redis-trib负责执行。redis提供了进行重新分片的所有命令，redis-trib通过向节点发送命令来进行重新分片。

  如何做故障转移？

  

  假如途中红色的节点故障了，此时master3下面的从节点会通过 选举 产生一个主节点。替换原来的故障节点。

  此过程和哨兵模式的故障转移是一样的。

  总结

  每种模式都有各自的优缺点，在实际使用场景中要根据业务特点去选择合适的模式。

  redis是一个非常常用的中间件，作为一个使用者来说，学习成本一点不高。

  如果作为一个很好的中间件去研究的话，还是有很多值得学习和借鉴的地方。比如redis的各种数据结构(动态字符串、跳跃表、集合、字典等)、高效的内存分配(jemalloc)、高效的IO模型等等。

  各ポイントを詳しく調査し、その後の高同時実行性と高可用性システムの設計に組み込むことができます。

  プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！

以上がRedis のスタンドアロン、マスター/スレーブ、センチネル、クラスター モードをすぐに理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。