一般的な使用
Redisのは、いくつかの一般的な用途は次のとおりです。
-
Redisの単一のコピー
-
Redisの複数のコピー（マスターとスレーブ）
-
Redisのセンチネル（センチネル）
-
Redisのクラスタ
-
Redisの自己開発
使用してのさまざまな方法の利点と欠点
Redisの単一のコピー
Redisの単一コピー、単一ノード配備アーキテクチャを使用してのRedisは、データのバックアップノードのないリアルタイムの同期はありませんが、それほど厳しいキャッシュ純粋なビジネスシナリオのデータの信頼性のためにデータの永続性とバックアップ戦略を提供していません。
利点：
-
導入しやすいシンプルな構造。
-
費用対効果：なしスペアノード（単一インスタンスまたはスーパーバイザは、crontabの可用性の保証を使用することができます）キャッシュを使用する場合、当然のことながら、ビジネスの高可用性を満たすためにも、スペアノードを犠牲にすることができますが、同時に外部サービスのインスタンスが1つだけあります。
-
高性能。
短所：
-
これは、データの信頼性を保証するものではありません。
-
キャッシュ温暖化の問題を解決することはできません、まだデータが失われた後、予備ノードアドレスの高可用性がある場合でも、プロセスを再起動して、しかし、キャッシュを使用して、ビジネスの高いデータ信頼性要件に適していません。
-
高いパフォーマンスは、シングルコアCPU（Redisのは、シングルスレッド機構である）、メインCPUボトルネック、簡単な操作コマンドのように、発注、少ない計算シーンの処理能力によって制限されます。また、Memcachedの代替使用を考慮することができます。
Redisの複数のコピー（マスターとスレーブ）
Redisの複数のコピーは、最大の特徴の観点からの単一のコピーに比べて（複製）構造、からマスターの展開を使用すると、リアルタイムのデータから、インスタンス間のマスタの同期であり、データの永続性とバックアップ戦略を提供します。
別の物理サーバー上に展開マスタースレーブ・インスタンス、会社の基盤環境の構成に応じて、同時にサービスや個別の読み取りおよび書き込みポリシーを提供達成することができます。
利点：
-
高い信頼性：プライマリ・データベースは、サービスの円滑な動作を保証するサービスを提供するライブラリからの一次ライブラリーに、自動スイッチオーバーを失敗したときに一つの局面において、デュアルスタンバイアーキテクチャの使用を行うことができ、一方、データの永続性機能がオンになっていますかつ合理的なバックアップ戦略を設定し、効果的に異常なデータ誤用やデータの損失の問題を解決することができます。
-
別々の読み取りと戦略を書く：ノードから読み取る能力を効果的に読み込み、同時大量に対処するために、マスター・データベースのノードを展開することができます。
短所：
-
リカバリーコンプレックス、そうでない場合はRedisのHAシステム（開発が必要）、プライマリ・データベースのノードに障害が発生し、必要が手動でノードからマスターノードに昇格、およびビジネス側の設定変更を通知する必要があり、新しいライブラリのノードからコピーするために他人を聞かせする必要がありますしますメインライブラリー・ノードは、全体のプロセスは、より複雑な人間の介入を必要とします。
-
スタンドアロンのメインライブラリーを書く能力が制限され、断片化を検討してください。
-
メインライブラリの記憶容量が制限され、スタンドアローンで、ピカを考えます。
-
欠点の元のコピーのような以前のバージョンでより顕著になります。同期が成功しない場合は、中断した後、Redisの複製、スレーブはこの時点で、PSYNCを開始し、全体量が同期されます、同時にフルバックアップを実行するための主なライブラリは、ミリ秒を引き起こす可能性がありまたはカトンの第二レベル。
また、極端な場合には、メインのライブラリメモリオーバーフローを引き起こすCOWメカニズムは、プログラムが予期せずまたはダウン終了しているため、メインのライブラリー・ノードは、バックアップファイルには、サーバーのディスクIOとCPU（圧縮）リソースの消費を引き起こし発生し、サイズは数GBを送信すると、バックアップファイルをエクスポートするサーバーの原因となります帯域幅の急増は、要求をブロックし、最新のバージョンにアップグレードすることをお勧めします。
Redisのセンチネル（センチネル）
RedisのセンチネルRedisのデータクラスタとクラスタ：RedisのSentinelは、ネイティブの高可用性ソリューションの打ち上げのコミュニティ版は、展開アーキテクチャは、2つの部分から構成されています。
Redisのセンチネルセンチネルクラスタは、障害検出、障害の自動転送、物流センター、クライアント通知を達成することができ、分散クラスタの複数のノードで構成されています。2N + 1（N> = 1）を満たすようにRedisのセンチネルノード数が奇数です。
利点：
-
Redisのセンチネルクラスタの展開はシンプル。
-
Redisのマスタースイッチは、高可用性モードの問題を解決することができます。
-
線膨張が大幅にRedisの大容量または高性能なビジネス要件を満たすことができ、簡単に、Redisのデータノードを実現するのRedis自身のシングルスレッドのボトルネックを破ることは容易です。
-
あなたは、データノードを監視したり、データノードのセットセンチネルのRedisを達成することができます。
短所：
-
Redisのマスタースレーブモード相対原理のより複雑な、より複雑な理解を展開します。
-
バックアップノードなどのリソース、Redisのデータノードスレーブノードの廃棄物は、サービスを提供していません。
-
センチネルRedisのRedisのは、主ノードからRedisのノードのマスターノードのデータノード、2種類に主観的および客観オフラインの故障決意を行うRedisのデータをオフラインのノードを、スイッチング高可用性のための主観的な操作をオフラインで作成しなければなりませんフェイルオーバーしません。
-
別々の読み取りと書き込みが問題を解決することはできません、実装が比較的複雑です。
提案：
-
同じサービスモニタはプログラムセンチネルRedisのクラスタ・モニタ・データノードの複数の組を選択することができた場合は、それ以外のプログラムのRedisセンチネルを選択したデータノードを監視します。
-
センチネルIDCセンチネルが複数展開されたときにモニター<定足数>設定<定足数> <マスター名> <IP> <ポート>センチネルリンパ節の半分を加えを提供勧告、単一IDCセンチネル展開の数が推奨されていません（ - 定足数センティネルの数）を超えます。
-
偶然のカットを防止するための合理的な設定パラメータ、制御スイッチ感度制御：
A。インクルード
B。ダウンした後、ミリ秒30000
C。フェイルオーバーのタイムアウト180000
D。maxclient
電子。タイムアウト
-
各ノードサーバ導入時間は、そうでない場合は、ログのタイミングが混乱になり、可能な限り同期します。
-
Redisの要求の効率を向上させる、RTTの数を減少させる、マルチキーとパイプライン動作を推奨しました。
-
リンクインスタンスへのクライアントアクセスを容易にするため、自らの物流センター（飼育係）を取得します。
Redisのクラスタ
Redisのクラスタコミュニティ版は、主に、Redisのの分散の観点のニーズに対応するために、たとえば、スタンドアロンメモリ、同時実行に直面し、ボトルネックを流したときに、Redisのクラスタが良い負荷分散を再生することができ、Redisの分散型クラスタソリューションを立ち上げています目的。
マスタノードは、読み取りおよび書き込み操作を提供するノードクラスタノード6以上のRedisのクラスタの最小構成（第3主3）は、バックアップ・ノードとしてノードは、リクエストが利用できない、フェイルオーバーとしてのみ使用。
Redisのクラスタ仮想パーティション溝は、全てのキーが0〜16,383スロットハッシュ関数の整数にマッピングされ、各ノードは、キー溝の部分と溝のデータがマッピングさを維持する責任があります。
利点：
-
なしセンターアーキテクチャ。
-
分散ノード、ノード間のデータの共有を複数格納されたデータに応じたスロットは、動的データの分布を調整することができます。
-
スケーラビリティ：直線的に複数のノードに拡張1000は、ノードが動的に追加または削除することができます。
-
高可用性：一部のノードは、クラスタがまだ使用可能で、使用できません。スレーブを増やすことでメカニズムを投票によって役割を強化するために、マスタースレーブを完了するために、ゴシッププロトコルを介してスタンバイ・データのコピー、自動フェイルオーバーを実現するために失敗し、ノード間の交換ステータス情報を行います。
-
システムの拡張性と可用性を向上させ、運用コストを削減します。
短所：
-
クライアントがスマートクライアント、キャッシュスロットマッピング情報を達成し、開発の難しさを更新し、改善するために、未成熟なクライアントのビジネスの安定性に影響を与える複雑なドライブ要件を達成します。現在はJedisCluster比較的成熟した、例外処理部には、このような一般的な「最大リダイレクト例外」として、完璧ではありません。
-
ノードブロックが何らかの理由で発生する（時間ブロッキングclutserノードタイムアウトよりも大きい）、それはオフラインで決定され、このようなフェイルオーバーは不要です。
-
非同期データレプリケーション、強力なデータの一貫性を保証するものではありません。
-
クラスタの同じセットを使用して複数の事業は、統計に基づいて、ホット＆コールドデータを区別することができない場合は、リソースの分離が悪く、状況がお互いに影響を与えがちです。
-
クラスタ内のスレーブは「コールドスタンバイ」として機能し、合理的な設計スレーブSDKを介してリソースの使用率を向上させるために、当然のことながら、可能な圧力を緩和読み取ることはできません。
-
このような使用MSETとしてキー制限バッチ操作、MGETは、現在のみサポートするキースロット値は、同じバッチ操作で行われます。キーキーは、クロススロットのクエリをサポートしていないので、実行MSET、MGET、sunion及び他の操作は非友好的なサポート。による別のスロットの値にマッピングするための
-
主要な運用サポートサービスは、異なるノードに分散した複数のキーは、トランザクション機能を使用できない場合にのみ、同じノード上のマルチキーの事務作業をサポートし、制限します。
-
オブジェクトできないデータ・パーティションの最小粒子径とキーなど大型キーハッシュ、リストとして異なるノードにマッピング。
-
唯一の空間データベースのクラスタ化モード、すなわちデシベル0を使用することができ、スタンドアロンでのRedisは、最大16個のデータベースをサポートすることができ、マルチデータベーススペースをサポートしていません。
-
構造をコピーすることは一つだけが、唯一のマスターノードのノードからコピーすることができますサポートし、レプリケーションは、ネストされたツリー構造をサポートしていません。
-
マスターシステムのデータベース・ノードで、その結果、ホットキーを避けるためには、ショートボードになります。
-
その上で、遅いクエリを爆発し、ネットワークカードで、その結果、大きなキーを避けてください。
-
クラスタ・ノードの時刻時間以上でなければならない時間を再試行してください。
-
Redisのクラスタは、最大リダイレクト生成されたシーンを減らし、マルチキーやパイプライン動作を推奨しません。
Redisの自己開発
高可用性ソリューションのRedisの自己開発は、主に中央の設定、障害検出およびフェイルオーバー・ハンドリング機構では、通常、オンライン彼らのビジネスの実際の環境に応じてカスタマイズする必要があります。
利点：
-
高い信頼性と高可用性。
-
高い自己制御;
-
ビジネスの実際のニーズ、屈曲可能な抵抗、良好な相溶性に接着。
短所：
-
複雑な、高い開発コストを実装します。
-
などのようなメタデータ情報を格納するための監視、ドメインネームサービスデータベースなど近隣施設の支援の必要性。
-
高いメンテナンスコスト。