クラスタインスタンスのデータシャード数が N であると仮定します。いずれかのデータシャードに障害が発生すると、障害が発生したデータシャードでマスターレプリカのフェールオーバーが開始されます。フェールオーバープロセス全体には、数秒から数十秒かかります。このプロセス中、データシャードに送信されたすべてのリクエストは失敗します。リクエストがすべてのデータシャードに均等に分散されている場合、インスタンスの理論上のリクエスト失敗率は 1/N です。
ただし、実際の失敗したリクエスト数は、以下の理由により、理論値よりも高くなる可能性があります。この例では、2 つのデータシャードを含み、プロキシモードで実行されているクラスタインスタンスを使用します。
直接接続モードのクラスタインスタンスの場合、実際の失敗率が高くなる唯一の理由は、複数キーコマンドの使用です。
複数のキーを含むコマンドが使用されている
プロキシモード: プロキシサーバーは、複数キーコマンドを複数のサブコマンドに分割し、ルートテーブルに基づいて対応するデータシャードにルーティングします。
直接接続モード: クライアントは、各サブコマンドを対応するデータシャードに送信します。
複数キーコマンドに障害が発生したデータシャードが含まれている場合、次の図に示すように、リクエスト全体が失敗する傾向があります。
最適化ソリューション: データシャードに障害が発生した場合の複数キーコマンドの失敗の可能性を減らすために、単一のコマンド内のキーの数を最小限に抑えます。
クライアントが単一の接続を使用している
Lettuce などの一部のクライアントは、単一の接続を介してリクエストを非同期で送信します。たとえば、2 つの GET リクエストが 1 つの接続を介してプロキシサーバーに順番に送信されるシナリオでは、Redis Serialization Protocol（RESP）では、リクエストが送信されたのと同じ順序で応答が返される必要があります。ノード障害が原因で
GET key2リクエストが失敗した場合、リクエストが正常に実行されたとしても、クライアントはGET key2に続くリクエストへの応答を受信できません。最適化ソリューション: 接続プールモデルをサポートする Jedis などのクライアントを使用します。
クライアントの接続プールリソースが枯渇している
接続プールモデルを使用するクライアントの場合、許可される最大接続数を構成できます。接続数が最大制限に達し、アイドル接続がない場合、新しいリクエストは失敗するかブロックされます。
次の図では、Jedis クライアントが使用されています。
maxTotal が 3 に設定され、timeout が 2000 に設定されており、3 つのGET key2リクエストが 2 秒以内に開始された場合、接続プールは 2 秒後にすべて使用中の接続で最大容量に達します。いずれかのノードが応答に失敗した場合、新しいリクエストは blockWhenExhausted 構成に基づいて失敗するかブロックされ、クライアント側のリクエストが失敗するかタイムアウトになります。最適化ソリューション: JedisPool リソースプールサイズ を適切に構成し、timeout パラメーターを 200 ～ 300 ミリ秒などの低い値（デフォルトの 2,000 ミリ秒ではなく）に設定します。この調整により、障害発生時の応答の高速化と、多数の接続がブロックされるのを防ぐことができます。