すべてのノードをマスター (スレーブ レプリケーションなし) として、7 ノードの Redis クラスターを実行しています。これをメモリ内キャッシュとして使用しているため、redis.conf 内のすべての保存をコメントアウトし、redis.conf 内に次のようなデフォルト以外のものを用意しました。
maxmemory: 30gb
maxmemory-policy allkeys-lru
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-require-full-coverage no
このクラスターのクライアントは、ドライバーとして jedis で spring-data-redis を使用する spring-boot REST API アプリケーションです。主にスプリング キャッシング アノテーションを使用します。
先日、マスターの 1 つがしばらくダウンするという問題が発生しました。7 ノード クラスターで 1 つのマスターがダウンした場合、redis を含む API 呼び出しの平均応答時間が大幅に増加することがわかりました。
ダウンしたマスターがオンラインに戻ってクラスターに再び参加したとき、応答時間に大幅なスパイクが発生しました。newrelic を介して、アプリが大量の redis クラスター呼び出しを開始したことを確認できます (newrelic は、どのクラスター サブコマンドが使用されたかを通知しません)。通常の平均応答時間は約 5 ミリ秒です。この間に最大 800 ミリ秒になり、70 秒を超える遅いサンプル トランザクションがいくつかありました。この間、すべてのアプリ jvm で、アクティブなスレッドの数が通常の 8 ～ 9 から約 300 に跳ね上がっていることがわかります。最大 400 スレッドを許可するように tomcat http スレッド プールを構成しました。約 3 分後、問題は解消されましたが、選択したキャッシュ ソリューションの安定性に疑問を持っている人がいます。Newrelic は、長いリクエストの追加の時間がどこに費やされているかについての洞察を提供しません (それは '
開発環境に対していくつかの jmeter 負荷テストを実行して再現を試みましたが、redis-cluster マスターを再接続するときに中程度の応答時間のスパイクが見られますが、本番環境で見たものに近いものは見られません. https://github.com/xetorthio/jedis/issues/1108にも出くわしましたが、そこから有益な洞察は得られません。spring.redis.cluster.max-redirects をデフォルトの 5 から 0 に減らしてみましたが、負荷テストの結果にはあまり影響がないように見えました。また、私のユースケースにどの程度の変更が適切かはわかりません。