Redis データの量は日々増加しており、ますます多くの企業がそれを使用しています。キャッシュに使用されるだけでなく、この部分を保存する傾向もあります。必然的にクラスターやさまざまな企業の開発が促進されます。私も自分に適したクラスター ソリューションを収集しています。現在、業界では次のようなクラスター アーキテクチャが一般的に使用されています。そのほとんどは、シャーディング技術を使用して、クラスターの増加によって引き起こされる一連の問題を解決しています。単一インスタンスのメモリ。
この記事では、5 つのソリューションを簡単に紹介します。
公式クラスター ソリューション
##twemproxy プロキシ ソリューション
#Sentinel モード
codis
クライアント シャーディング
公式クラスタ ソリューション
redis バージョン 3.0 から redis-cluster クラスタがサポートされ、redis-cluster はセンターレス構造を採用し、各ノードがデータとクラスタ全体の状態を保存し、各ノードが他のノードと接続されます。 redis-cluster はサーバー側のシャーディング テクノロジです。
redis-cluster アーキテクチャ図
redis-cluster の機能:
各ノードは n-1 個のノードと通信します。クラスターバス。これらは、外部サービスのポート番号に 10000 を加えた特別なポート番号を使用します。したがって、このクラスター内の各ノードの情報を維持する必要があり、そうでないとクラスター全体が使用できなくなります。特別なバイナリ プロトコルが内部で使用され、伝送速度と帯域幅が最適化されます。
redis-cluster はすべての物理ノードを [0,16383] スロット (スロット) にマップし、クラスターはノード-スロット-値を維持する責任を負います。
クラスターはあらかじめ 16384 個のバケットに分割されており、redis クラスターにデータを挿入する必要がある場合、CRC16(KEY) mod 16384 の値に従ってキーをどのバケットに配置するかが決定されます。
クライアントは Redis ノードに直接接続されています。クラスター内のすべてのノードに接続する必要はなく、クラスター内の使用可能なノードに接続するだけです。
redis-trib.rb スクリプト (rub 言語) は、ノードの自動追加、スロットの計画、データの移行および一連の操作などを行うクラスター管理ツールです。
ノードの障害は、クラスター内のノードの半分以上が障害を検出した場合にのみ有効になります。
クラスター全体が全体とみなされます。クライアントは操作のために任意のノードに接続できます。クライアントが操作するキーがノードに割り当てられていない場合、redis は正しいキーを指すようにステアリング命令を返します。ノード。
クラスターのアクセシビリティを向上させるために、公式に推奨されるソリューションは、ノードをマスター/スレーブ構造、つまりマスター ノードと n 個のスレーブ ノードに構成することです。マスターノードに障害が発生した場合、redis クラスターは選択アルゴリズムに従ってマスターノードに昇格するスレーブノードの 1 つを選択し、クラスター全体が外部にサービスを提供し続けます。
twemproxy プロキシ ソリューション
twemproxy プロキシ アーキテクチャ図:
Redis プロキシ ミドルウェア twemproxy は、ミドルウェア テクノロジを使用するシャーディングの一種です。 Twemproxy はクライアントとサーバーの間にあり、クライアントからのリクエストを処理 (シャーディング) し、バックエンドの実際の Redis サーバーに転送します。つまり、クライアントは Redis サーバーに直接アクセスせず、twemproxy プロキシ ミドルウェアを通じて間接的にアクセスします。バックエンド サーバーへのクライアントの直接接続の数を減らし、サーバー クラスターの水平方向の拡張をサポートします。
twemproxy ミドルウェアの内部処理はステートレスであり、それ自体を簡単にクラスター化できるため、単一点のストレスや障害が回避されます。
twemproxy はくるみ割り人形としても知られ、Twitter システムの redis および memcached クラスターの軽量プロキシに由来しています。
Github ソース コード アドレス (https://github.com/twitter/twemproxy)
上記のアーキテクチャ図から、twemproxy が単一ポイントであることがわかります。これにより、簡単に問題が発生する可能性があります。したがって、twemproy の高可用性を実現するには、通常、keepalived を組み合わせます。このとき、通常は 1 台の twemproxy のみが動作し、もう 1 台はスタンバイ状態になっていますが、1 台が切断されると、VIP は自動的にドリフトし、スタンバイ マシンが作業を引き継ぎます。 keepalived の使用方法については、オンラインで情報を確認できます。
Sentinel モード
Sentinel Sentinel
Sentinel は Redis の高可用性ソリューションです。1 つ以上の Sentinel インスタンスで構成される Sentinel システムは、任意の数のマスター サーバーを監視できます。およびこれらのマスターサーバーの下にあるすべてのスレーブサーバーを監視し、監視対象のマスターサーバーがオフラインになると、オフラインのマスターサーバーの下にあるスレーブサーバーを新しいマスターサーバーに自動的にアップグレードします。
例:
サーバー 1 がオフラインになった後:
サーバー 2 を新しいマスターとしてアップグレードします。サーバー:
Sentinel の仕組み
各 Sentinel は、PING コマンドで 1 秒に 1 回、マスター、スレーブ、およびその他の既知の Sentinel インスタンスにメッセージを送信します。
インスタンスの PING コマンドに対する最後の有効な応答からの時間が、down-after-milliseconds オプションで指定された値を超えた場合、インスタンスは Sentinel によって主観的にオフラインとしてマークされます。
マスターが主観的オフラインとしてマークされている場合、マスターを監視しているすべてのセンチネルは、マスターが実際に主観的オフライン状態に入ったことを 1 秒に 1 回確認する必要があります。
十分な数のセンチネル (設定ファイルで指定された値以上) が、マスターが指定された時間範囲内で実際に主観的オフライン状態に入ったことを確認すると、マスターは客観的にマークされます。オフライン。
通常の状況では、各センチネルは、10 秒に 1 回、知っているすべてのマスターおよびスレーブに INFO コマンドを送信します。
マスターが Sentinel によって客観的にオフラインとしてマークされると、Sentinel がオフライン マスターのすべてのスレーブに INFO コマンドを送信する頻度が 10 秒に 1 回から 1 秒に 1 回に変更されます。
マスターがオフラインであることに同意する十分なセンチネルがいない場合、マスターの客観的なオフライン ステータスは削除されます。マスターが再度 Sentinel の PING コマンドに有効な値を返した場合、マスターの主観的なオフライン ステータスは削除されます。
codis
codis は、Wandoujia によってオープンソース化された分散 Redis ソリューションです。上位層アプリケーションの場合、codis プロキシへの接続とネイティブ Redis サーバーへの接続に明らかな違いはありません。上位層 アプリケーションはスタンドアロン Redis のように使用できます。codis の最下位層は、リクエストの転送、ノンストップのデータ移行などを処理します。その後のすべてのことは前のクライアントに対して透過的です。単純に考えることができます。背後にある接続は、無制限のメモリを備えた Redis サービスであること。
クライアント シャーディング
パーティショニングのロジックはクライアントに実装され、クライアントはどのノードをリクエストするかを選択します。このソリューションは一貫性のあるハッシュを参照することができ、このソリューションは通常、ユーザーがクライアントの動作を完全に制御できるシナリオに適しています。
要約: 最適なソリューションはなく、最も適切なソリューションがあるだけです。
Redis 関連の技術記事の詳細については、Redis チュートリアル 列にアクセスして学習してください。
以上がRedis クラスター ソリューションとは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
