Redisセンチネルとクラスタリング
Redis sentinelは、複数のredisインスタンス間でHA（高可用性）を構成する方法であると理解しています。私が見るように、いつでもクライアントのリクエストをアクティブに処理する1つのredisインスタンスがあります。 2つの追加サーバーがスタンバイ状態にあります（障害が発生するのを待機しているため、そのうちの1つが再び動作可能になります）。
- リソースの無駄ですか？
- 利用可能なリソースを最大限に活用するより良い方法はありますか？
- RedisクラスタリングはRedisセンチネルに代わるものですか？
sentinel および clustering のredisのドキュメントを既に検索しました。経験のある人が説明してもらえますか。
UPDATE
OK。実際の展開シナリオでは、redis専用の2台のサーバーがあります。 Jbossサーバーが実行されている別のサーバーがあります。 Jbossで実行されているアプリケーションは、redisマスターサーバー（M）に接続するように構成されています。
フェイルオーバーシナリオ
理想的には、マスターキャッシュサーバーに障害が発生した場合（Redisプロセスがダウンするか、マシンに障害が発生した場合）、Jbossのアプリケーションはスレーブキャッシュサーバーに接続する必要があります。これを実現するためにredisサーバーをどのように構成しますか？
+--------+ +--------+
| Master |---------| Slave |
| | | |
+--------+ +--------+
Configuration: quorum = 1
まず、センチネルについて話しましょう。
Sentinelはフェイルオーバーを管理し、RedisをHA用に構成しません。これは重要な違いです。第二に、投稿した図は実際には不適切な設定です。管理しているRedisノードと同じノードでSentinelを実行したくないのです。そのホストを失うと、両方を失います。
「リソースの無駄ですか？」それはユースケースに依存します。そのセットアップでは3つのRedisノードは必要ありません。2つだけ必要です。 3は冗長性を高めますが、必須ではありません。追加の冗長性が必要な場合は、リソースの無駄ではありません。冗長性が必要ない場合は、単一のRedisインスタンスを実行して、それを適切に呼び出すだけです。それ以上実行すると「無駄」になります。
2つのスレーブを実行するもう1つの理由は、読み取りを分割することです。繰り返しますが、必要な場合は無駄ではありません。
「利用可能なリソースを最大限に活用するより良い方法はありますか？」特定のシナリオとコードに大きく依存しているため、これに答えることはできません。つまり、保存するデータ量が「小さく」、コマンドレートが極端に高くない場合は、ホストをRedis専用にする必要がないことを思い出してください。
さて、「RedisクラスタリングはRedisセンチネルに代わるものですか？」それは本当にあなたのユースケースに完全に依存しています。 RedisクラスターはHAソリューションではありません-複数のライター/ RAMより大きいソリューションです。あなたの目標がただのHAであるなら、それはあなたにふさわしくないでしょう。 Redisクラスターには、特にマルチキー操作に関する制限が伴うため、必ずしも単純な「クラスターを使用する」操作ではありません。
Redisを実行している3つのホスト（およびセンチネルを実行している3つのホスト）が無駄であると考える場合、より多くのリソースを必要とするため、Clusterをさらに保持する可能性があります。
あなたが尋ねた質問は、おそらく広すぎて意見に基づいているため、書かれたままでは生き残れません。解決しようとしている特定のケース/問題がある場合は、更新してください。具体的な支援と情報を提供できます。
詳細の更新：
シナリオで適切なフェイルオーバー管理を行うには、JBossサーバーで実行されている3つのセンチネルを使用します。 3つのJBossノードがある場合、それぞれに1つを使用します。別のノードにRedisポッド（マスター+スレーブ）があり、センチネルにフェイルオーバーを管理させます。
そこから、JBoss/Jedisを接続して、情報と接続管理にSentinelを使用する必要があります。私はこれらを使用しないので、Jedisがクイック検索でサポートしているので、正しく構成する必要があります。私が見つけたいくつかの例は、 Sentinelを使用したJedisの例を探しています および https://github.com/xetorthio/jedis/issues/725 にあり、JedisSentinelPoolがプールを使用するためのルート。
Sentinelがフェイルオーバーを実行すると、クライアントは切断され、Jedisは現在のマスターが誰であるかをセンチネルに尋ねることにより再接続を処理します（すべきですか？）。
どこでも、2つまたは2の倍数を使用せずに、奇数のインスタンスから開始することをお勧めします。それは修正されましたが、他のいくつかの点を修正できます。
まず、SentinelがHAなしでフェイルオーバーを提供すると言うのは誤りです。フェールオーバーがある場合、HAがあり、アプリケーションの状態がレプリケートされるという追加の利点があります。違いは、レプリケーションのないシステムでHAを使用できることです（HAですが、フォールトトレラントではありません）。
第二に、ターゲットのredisインスタンスと同じマシンでセンチネルを実行することは「悪いセットアップ」ではありません。センチネル、redisインスタンス、またはマシン全体を失っても、結果は同じです。そのため、このような構成のすべての例で、両方が同じマシンで実行されていることがわかります。
これはあなたの質問に対する直接的な答えではありませんが、私のようなRedis初心者にとって役立つ情報だと思います。また、この質問は、「Redis cluster vs sentinel」を検索するときにGoogleの最初のリンクとして表示されます。
Redis SentinelはRedis高可用性ソリューションの名前です... Redis Clusterとは関係がなく、Redis Clusterを必要としない人々が使用することを意図していますが、単にマスターがインスタンスが正しく機能していません。
Redis Sentinel design draft 1. から取得
Redisを初めて使用し、フェイルオーバーソリューションを実装する場合、それは不明瞭ではありません。 sentinel と clustering に関する公式ドキュメントは互いに比較されないため、大量のドキュメントを読まずに正しい方法を選択することは困難です。
これはドキュメンテーション全体に頭を突っ込んだ後の私の理解です。
Sentinelは、スレーブがレプリケートされ、いつでも昇格できるようになっているホットスタンバイソリューションです。ただし、マルチノード書き込みはサポートしません。スレーブは読み取り操作用に構成できます。 SentinelがHAを提供しないというのは事実ではなく、典型的なアクティブ/パッシブクラスターのすべての機能を備えています（ただし、ここで使用するのは適切ではありません）。
Redisクラスターは多かれ少なかれ分散型ソリューションであり、シャードの上で動作します。データの各チャンクは、マスターノードとスレーブノードに分散されています。 2の最小レプリケーション係数により、マスターとスレーブ間で2つのアクティブなシャードを使用できるようになります。 MongoまたはElasticsearchのシャーディングを知っていれば、簡単に追いつくことができます。
Redis Sentinelは、マスターがダウンしていることを確認すると、レプリカを促進するフェイルオーバーを実行します。通常、奇数個のセンチネルノードが必要です。 1つのマスターと1つのレプリカの例では、3人のセンチネルを使用して、決定についてコンセンサスを得る必要があります。理想的には、3番目のセンチネルは3番目のサーバー上にあるため、決定が歪まないようにします（障害に応じて）。 Sentinelはノードのマスター/レプリカ構成設定の変更を処理します。これにより、昇格と同期が正しい順序で行われ、古いデータが含まれる古いマスターに障害が発生してデータが上書きされないようになります。
フェイルオーバーを実行するようにセンチネルノードを設定したら、正しいインスタンスを指していることを確認する必要があります。 このためのHAProxy設定 の例を参照してください。 HAProxyはヘルスチェックを実行し、障害が発生すると新しいマスターをポイントします。
クラスタリングを使用すると、水平方向にスケーリングでき、高負荷の処理に役立ちます。事前のセットアップと構成には少し手間がかかります。
Redisのオープンソースフォークである「KeyDB」により、アクティブレプリカオプションを備えたセンチネルノードが不要になりました。これにより、レプリカノードは読み取りと書き込みを受け入れることができます。フェイルオーバーが発生すると、HAProxyは失敗したノードとの読み取り/書き込みを停止し、既に同期されている残りのアクティブノードを使用します。タイムスタンプにより、障害が発生したノードは自動的に再結合し、オンラインに戻ったときにデータを失うことなく再同期できます。セットアップは簡単で、トラフィックが多い場合は、レプリカノードへの読み取りとマスターへの読み取り/書き込みを行うための特別な事前設定は必要ありません。 ここでアクティブなレプリケーションの例を参照 。 KeyDBはマルチスレッド化されているため、一部のアプリケーションではクラスタリングの代わりになる場合がありますが、実際にはニーズに依存します。
手動でクラスタリング および create-cluster tool を設定する例もあります。 Redisを使用している場合、これらは同じ手順です（命令で「keydb」を「redis」に置き換えます）
Redisは、パーティションクラスター（これらのマスターの多くのマスターとスレーブ）またはシングルインスタンスモード（レプリカスレーブを備えた単一マスター）で動作できます。
リンク は次のとおりです。
単一のRedisサーバーがパーティション化されていないデータベース全体を管理するシングルインスタンスモードでRedisを使用する場合、Redis Sentinelを使用して可用性を管理します
それはまた言う：
データが複数のプライマリインスタンスに分割されているRedisクラスターは、それ自体で可用性を管理し、追加のコンポーネントを必要としません。
したがって、前述の2つのシナリオでHAを確保できます。これが疑問をクリアすることを願っています。 Redisクラスターとセンチネルは互いに代替ではありません。これらは、パーティションマスターまたは非パーティションマスターのさまざまなケースでHAを確保するためにのみ使用されます。