Redisの一般的な遅延問題のトラブルシューティングマニュアル！33の最適化提案

     メモリデータベースとして、Redisは非常に高いパフォーマンスを発揮し、単一インスタンスのQPSは約10Wに達する可能性があります。ただし、Redisを使用すると、アクセスの遅延が非常に長くなることがよくあります。Redisの内部実装の原則がわからない場合は、トラブルシューティングの際に混乱する可能性があります。

多くの場合、Redisはアクセス遅延を増加させています。これは、不適切な使用または不当な操作とメンテナンスが原因です。

Redisの速度が低下しましたか？一般的な遅延問題の場所と分析

Redisが使用プロセスで頻繁に発生する遅延の問題と、それを見つけて分析する方法を分析してみましょう。

複雑なコマンドを使用する

Redisの使用時にアクセス遅延が突然増加した場合のトラブルシューティング方法は？

まず、最初のステップは、Redisの遅いログを確認することです。Redisは、低速ログコマンドの統計機能を提供します。以下の設定により、実行の遅延が大きいコマンドを確認できます。

最初にRedisの低速ログしきい値を設定します。しきい値を超えるコマンドのみが記録されます。ここでの単位は微妙です。たとえば、低速ログしきい値を5ミリ秒に設定し、最後の1000個の低速ログレコードのみを保持するように設定します。

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000

# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

設定が完了した後、実行されたすべてのコマンドの遅延が5ミリ秒を超えると、Redisによって記録されます。SLOWLOGget5を実行して、最後の5つの遅いログをクエリします。

127.0.0.1:6379> SLOWLOG get 5

1) 1) (integer) 32693       # 慢日志ID

   2) (integer) 1593763337  # 执行时间

   3) (integer) 5299        # 执行耗时(微妙)

   4) 1) "LRANGE"           # 具体执行的命令和参数

      2) "user_list_2000"

      3) "0"

      4) "-1"

2) 1) (integer) 32692

   2) (integer) 1593763337

   3) (integer) 5044

   4) 1) "GET"

      2) "book_price_1000"

遅いログレコードを調べることで、sort、sunion、zunionstore、Oの実行など、O（n）を超える複雑さのコマンドを頻繁に使用する場合に、どのコマンドをいつ実行するのに時間がかかるかを知ることができます。 （n）コマンド中に操作されるデータの量は比較的多く、これらの場合、Redisのデータ処理には時間がかかります。

サービスリクエストの量は多くないが、RedisインスタンスのCPU使用率が高い場合は、非常に複雑なコマンドの使用が原因である可能性があります。

解決策は、これらのより複雑なコマンドを使用せず、一度に多くのデータを取得せず、毎回少量のデータを操作して、Redisが時間内に処理して戻ることができるようにすることです。

大きな鍵を保管する

遅いログを照会し、それが遅いログレコードに表示されるSETおよびDELETE操作などのより複雑なコマンドが原因ではないことがわかった場合、Redisが大きなキーを書き込んだ状況があるかどうかを疑う必要があります。

Redisがデータを書き込むときは、新しいデータにメモリを割り当てる必要があります。Redisからデータが削除されると、対応するメモリスペースが解放されます。

キーによって書き込まれるデータが非常に大きい場合、Redisはメモリの割り当てにも時間がかかります。同様に、このキーのデータを削除すると、メモリの解放に時間がかかります。

ビジネスコードをチェックする必要があります。大きなキーが書き込まれているかどうか、書き込まれたデータのサイズを評価する必要があります。ビジネスレイヤーは、過剰な量のデータを含むキーを保存しないようにする必要があります。

では、Redisに大きな重要なデータがあるかどうかをスキャンする方法はありますか？

Redisは、大きなキーをスキャンする方法も提供します。

redis-cli -h $host -p $port --bigkeys -i 0.01

上記のコマンドを使用して、タイプディメンションに表示されるインスタンス全体のキーサイズの分布をスキャンします。

オンラインインスタンスで大規模なキースキャンを実行すると、RedisのQPSが急激に増加することに注意してください。スキャンプロセス中のRedisへの影響を減らすには、スキャンの頻度を制御する必要があります。 -iパラメーター制御（スキャンを意味します）プロセス内の各スキャンの時間間隔（秒単位）。

このコマンドの使用の原則は、Redisが内部でスキャンコマンドを実行し、すべてのキーをトラバースしてから、さまざまなタイプのキーに対してstrlen、llen、hlen、scar、zcardを実行して、文字列の長さとコンテナータイプ（list / dict / set / zset）要素の数。

コンテナタイプのキーの場合、スキャンできるのは要素が最も多いキーのみですが、要素が最も多いキーが必ずしも最も多くのメモリを占有するわけではないため、注意が必要です。ただし、通常、このコマンドを使用すると、インスタンス全体でのキーの分布をより明確に理解できます。

大きなキーの問題に対応して、Redisはバージョン4.0でレイジーフリーメカニズムを正式に開始し、大きなキーのメモリを非同期的に解放して、Redisのパフォーマンスへの影響を軽減しました。それでも、大きなキーの使用はお勧めしません。大きなキーは、クラスター移行プロセス中の移行のパフォーマンスにも影響します。これについては、クラスター関連の記事を紹介するときに詳しく説明します。

一元化された有効期限

Redisを使用すると遅延がなくなることがありますが、特定の時点で突然遅延の波が現れ、特定の時間や間隔の長さなど、速度低下の時点は非常に規則的です。それは一度起こります。

これが発生した場合は、キーの有効期限が多数あるかどうかを検討する必要があります。

一定の時点で多数のキーが期限切れになると、その時点でRedisにアクセスすると、遅延が増加する可能性があります。

Redisの有効期限戦略は、アクティブ有効期限+レイジー有効期限の2つの戦略を採用しています。

• アクティブな有効期限：Redisは内部で時間指定タスクを維持します。デフォルトでは、100ミリ秒ごとに期限切れのディクショナリから20個のキーがランダムに取得され、期限切れのキーが削除されます。期限切れのキーの割合が25％を超える場合は、引き続き20個のキーを取得して期限切れのキーを削除します。のキーは、期限切れのキーの割合が25％に低下するか、このタスクの実行に25ミリ秒以上かかるまで、サイクルを終了します。

• 遅延有効期限：キーにアクセスした場合にのみ、キーの有効期限が切れているかどうかを判断できます。有効期限が切れている場合は、インスタンスから削除されます。

Redisのアクティブに期限切れのタイミングタスクはRedisメインスレッドでも実行されることに注意してください。つまり、アクティブな有効期限の実行中に多数の期限切れのキーを削除する必要がある場合は、ビジネスアクセス中にこれを待つ必要があります。期限切れのタスクが実行された後、ビジネスリクエストを処理できます。このとき、サービスアクセス遅延が大きくなるという問題があり、最大遅延は25ミリ秒です。

また、このアクセス遅延は低速ログに記録されません。スローログは、特定のコマンドの実行にかかる時間のみを記録します。Redisアクティブ有効期限戦略は、操作コマンドの前に実行されます。操作コマンドの時間がスローログのしきい値よりも短い場合、スローログ統計にはカウントされません。 、しかし私たちビジネスは遅延が増加したと感じました。

この時点で、ビジネスをチェックして、集中型の期限切れコードが実際に存在するかどうかを確認する必要があります。通常、集中型の期限切れに使用されるコマンドは、expireatまたはpexpireatです。コードでこのキーワードを検索するだけです。

あなたのビジネスが本当に特定のキーの期限切れに集中する必要があり、Redisをジッターさせたくない場合、最適化ソリューションは何ですか？

解決策は、フォーカスが期限切れになるときにランダムな時間を追加し、期限切れが必要なこれらのキーの時間を分割することです。

擬似コードは次のように記述できます。

# 在过期时间点之后的5分钟内随机过期掉

redis.expireat(key, expire_time + random(300))

このように、Redisが有効期限を処理しているときに、キーの集中削除による過度のプレッシャーが発生したり、メインスレッドがブロックされたりすることはありません。

また、業務でのこの問題に注意を払うだけでなく、運用や保守によってこの状況を時間内に見つけることもできます。

このアプローチでは、Redisのさまざまな操作データを監視し、情報を実行してすべての操作データを取得する必要があります。ここでは、これまでにインスタンス全体で削除された期限切れのキーの総数を表す項目expired_keysに注目する必要があります。 。

この指標を監視する必要があります。短期間にこの指標が急増した場合は、警察に適時に報告し、事業報告が遅い時期と比較・分析して確認する必要があります。時間は一定です。一貫している場合は、この理由による遅延が増加しているためと考えられます。

インスタンスメモリが上限に達しました

Redisを純粋なキャッシュとして使用する場合があります。インスタンスのメモリ制限maxmemoryを設定してから、LRU除去戦略をオンにします。

インスタンスのメモリがmaxmemoryに達すると、新しいデータを書き込むたびに速度が低下する可能性があります。

速度が低下する理由は、Redisメモリがmaxmemoryに達すると、メモリをmaxmemoryの下に保つために、新しいデータを書き込む前に毎回一部のデータをキックアウトする必要があるためです。

古いデータを追い出すこのロジックにも時間がかかり、特定の時間のかかる長さは、構成された除去戦略によって異なります。

• allkeys-lru：キーの有効期限が切れるように設定されているかどうかに関係なく、最も最近アクセスされていないキーを削除します。

• Volatile-lru：最も最近アクセスされて設定された期限切れのキーのみを削除します。

• allkeys-random：キーが期限切れに設定されているかどうかに関係なく、ランダムに削除されます。

• Volatile-random：設定が期限切れのキーのみをランダムに削除します。

• allkeys-ttl：キーが期限切れになるように設定されているかどうかに関係なく、期限切れになりそうなキーは削除されます。

• noeviction：キーを削除せず、いっぱいになった直後に書き込み、エラーを直接報告します。

• allkeys-lfu：キーの有効期限が切れるように設定されているかどうかに関係なく、アクセス頻度が最も低いキーを削除します（4.0以降のサポート）。

• Volatile-lfu：アクセス頻度が最も低い（4.0以降のサポート）期限切れのキーのみを削除します。

どの戦略を使用するかは、決定するビジネスシナリオによって異なります。

最も一般的に使用される戦略は、allkeys-lruまたはvolatile-lru戦略です。それらの処理ロジックは、インスタンスから毎回ランダムにキーのバッチ（構成可能）を取り出し、最もアクセスの少ないキーを削除して、残りを取得することです。キーは一時的にプールに保存され、次にキーのバッチがランダムに取り出され、前のプールのキーと比較され、最もアクセスの少ないキーが削除されます。メモリがmaxmemoryを下回るまで、これを繰り返します。

allkeys-randomまたはvolatile-random戦略を使用すると、ランダムに削除されるため、はるかに高速になり、キーアクセス頻度の比較にかかる時間が短縮され、ランダムに取り出した直後にキーのバッチを削除できます。キーのバッチであるため、この戦略は上記のLRU戦略よりも高速です。

ただし、上記のロジックは、Redisにアクセスするときに実際のコマンドが実行される前に実行されます。つまり、Redisにアクセスするときに実行されるコマンドに影響します。

また、この時点でRedisインスタンスに大きなキーが格納されている場合、大きなキーを削除してメモリを解放すると、時間がかかり、遅延が大きくなるため、特に注意が必要です。

ビジネス訪問の量が非常に多く、インスタンスのメモリ上限を制限するようにmaxmemoryを設定する必要があると同時に、キーを削除すると遅延が増加するという状況に直面している場合は、この状況を緩和します。上記のように大きなキーの保存を回避し、ランダムな削除を使用することに加えて、戦略に加えて、インスタンスを分割して軽減する方法を検討することもできます。インスタンスを分割すると、1つのインスタンスの圧力を分散して、キーを削除することができます。複数のインスタンス。これにより、遅延をある程度減らすことができます。

フォークは時間がかかります

RedisでRDBとAOFの書き換えを自動生成する機能が有効になっている場合、バックグラウンドでRDBとAOFの書き換えを生成すると、Redisのアクセス遅延が大きくなり、これらのタスクを実行すると遅延がなくなる可能性があります。

この場合、一般的にRDBとAOFの書き換えを生成するタスクが原因です。

RDBとAOFを生成するには、親プロセスがデータの永続性のために子プロセスをforkする必要があります。forkの実行中に、親プロセスはメモリページテーブルを子プロセスにコピーする必要があります。インスタンスメモリ全体が大量に占有する場合、次に、コピーされたメモリページをコピーする必要があります。テーブルには時間がかかり、このプロセスは多くのCPUリソースを消費します。フォークが完了する前に、インスタンス全体がブロックされ、リクエストを処理できなくなります。この時点でCPUリソースが不足していると、フォーク時間は長くなり、最大で数秒になります。これは、Redisのパフォーマンスに深刻な影響を及ぼします。

特定の原則は、私が以前に書いた記事を参照することもできます：Redisの永続性はどのように機能しますか？RDBとAOFの比較分析。

infoコマンドを実行して、最後のフォーク実行の時間のかかるlatest_fork_usecを表示できます。単位は微妙です。この時間は、インスタンス全体がブロックされ、リクエストを処理できない時間です。

バックアップ上の理由によるRDBの生成に加えて、マスターノードとスレーブノードが初めてデータ同期を確立するときに、マスターノードはスレーブノードが完全同期を実行するためのRDBファイルも生成します。これもパフォーマンスに影響します。 Redisで。

この状況を回避するには、データのバックアップサイクルを計画する必要があります。スレーブノードでバックアップを実行することをお勧めします。これは、ピークの低い期間に実行するのが最適です。ビジネスが失われたデータに敏感でない場合は、AOFおよびAOF書き換え機能を有効にすることはお勧めしません。

さらに、フォークの消費時間もシステムに関係しています。Redisを仮想マシンにデプロイすると、この時間も増加します。したがって、Redisを使用する場合は、フォークの影響を減らすために、物理マシンにRedisをデプロイすることをお勧めします。

CPUをバインドする

多くの場合、サービスをデプロイするとき、プログラムが複数のCPUを使用するときのコンテキスト切り替えのパフォーマンスを向上させ、パフォーマンスの損失を減らすために、通常、CPUをプロセスにバインドする操作を使用します。

ただし、Redisを使用する場合は、次の理由からお勧めしません。

RedisがCPUにバインドされている場合、データが永続化されると、子プロセスforkは親プロセスのCPU使用設定を継承し、子プロセスはデータ永続化のために多くのCPUリソースを消費し、子プロセスはCPUを使用しますメインプロセスで競合が発生し、メインプロセスのCPUリソースが不足して、アクセス遅延が増加します。

したがって、Redisプロセスをデプロイするときに、RDBおよびAOFの書き換えメカニズムを有効にする必要がある場合は、CPUバインディング操作を実行しないでください。

AOFをオンにします

前述のように、AOFファイルを書き換えると、フォークの実行に時間がかかるため、Redisの遅延が大きくなります。また、AOFメカニズムをオンにすると、設定戦略が不合理になり、パフォーマンスの問題も発生します。 。

AOFをオンにすると、Redisは書き込まれたコマンドをリアルタイムでファイルに書き込みますが、ファイルを書き込むプロセスは最初にメモリに書き込むことであり、メモリ内のコンテンツはメモリ内のデータが特定のしきい値を超えるか、特定の期間に達します。実際にはディスクに書き込まれます。

ファイルをディスクに書き込む際の安全性を確保するために、AOFには次の3つのブラッシングメカニズムが用意されています。

• appendfsync always：書き込むたびにディスクをフラッシュします。これはパフォーマンスに最大の影響を与え、ディスクIOを比較的高く消費し、最高のデータセキュリティを備えています。

• appendfsync everysec：1秒に1回ディスクをフラッシュしても、パフォーマンスへの影響は比較的小さく、ノードがダウンすると最大1秒のデータが失われます。

• appendfsync no：オペレーティングシステムのメカニズムに従ってディスクをフラッシュします。これは、パフォーマンスへの影響が最も少なく、データセキュリティが低く、ノードのダウンタイムによるデータ損失は、オペレーティングシステムのディスクフラッシュメカニズムによって異なります。

最初のメカニズムappendfsyncを常に使用する場合、Redisが書き込みコマンドを処理するたびに、コマンドがディスクに書き込まれ、この操作はメインスレッドで実行されます。

メモリ内のデータはディスクに書き込まれるため、ディスクのIO負荷が増加し、ディスクの運用コストはメモリの運用コストよりもはるかに高くなります。書き込み量が多いと、すべての更新がディスクに書き込まれます。このとき、マシンのディスクIOが非常に高くなり、Redisのパフォーマンスが低下するため、これを使用することはお勧めしません。機構。

最初のメカニズムと比較すると、appendfsync everysecは1秒ごとにディスクを更新しますが、appendfsync noはオペレーティングシステムの更新時間に依存するため、安全性は低くなります。したがって、appendfsync everysecを使用することをお勧めします。最悪の場合、失われるデータは1秒だけですが、アクセスパフォーマンスを向上させることができます。

もちろん、一部のビジネスシナリオでは、データ損失の影響を受けにくく、AOFが有効になっていない場合があります。

スワップを使用する

Redisが突然非常に遅くなり、各アクセスに数百ミリ秒または数秒かかる場合は、Redisがスワップを使用しているかどうかを確認します。この場合、Redisは基本的に高性能サービスを提供できません。

ご存知のように、オペレーティングシステムはスワップメカニズムを提供します。目的は、メモリが不足している場合に、メモリ使用量のバッファリングを実現するために、メモリ内のデータの一部をディスクに交換できるようにすることです。

ただし、メモリ内のデータがディスクに変更された場合、データへのアクセスをディスクから読み取る必要があります。この速度はメモリよりもはるかに低速です。

特に、Redisなどの高性能メモリデータベースの場合、Redisのメモリがディスクに変更された場合、この操作時間は、Redisなどの非常に機密性の高いパフォーマンスのデータベースでは許容できません。

マシンのメモリ使用量をチェックして、メモリ不足のためにスワップが実際に使用されているかどうかを確認する必要があります。

スワップを使用する場合は、Redisが使用するのに十分なメモリを解放するのに間に合うようにメモリ空間を整理してから、Redisがメモリを再利用できるようにRedisのスワップを解放する必要があります。

redisスワッププロセスには通常、インスタンスの再起動が含まれます。インスタンスの再起動によるビジネスへの影響を回避するには、通常、最初にマスタースレーブスイッチを実行してから、古いマスターノードのスワップを解放し、サービスを再起動して、元に戻します。データ同期が完了した後、マスターノードに送信できます。

RedisがSwapを使用する場合、この時点でRedisの高性能は基本的に廃止されていることがわかりますので、事前にこの状況を防ぐ必要があります。

Redisマシンのメモリとスワップの使用状況を監視し、メモリが不足してスワップが使用されたときにアラームを発し、対応する処理が時間内に実行される必要があります。

ネットワークカードの負荷が高すぎる

パフォーマンスの問題を引き起こす上記のシナリオを回避し、Redisが長い間安定して実行されていたが、ある時点以降、Redisへのアクセスが遅くなり始め、現在まで続いている場合。この状況は何ですか。それを引き起こした？

このような問題は以前にも経験したことがありますが、ある時点から減速し始め、継続するのが特徴です。このとき、マシンのネットワークカードトラフィックをチェックして、ネットワークカードトラフィックがいっぱいかどうかを確認する必要があります。

ネットワークカードの負荷が高すぎると、ネットワーク層とTCP層でデータ転送の遅延とデータパケット損失が発生します。メモリに加えて、Redisの高性能はネットワークIOにあり、要求量が急激に増加すると、ネットワークカードの負荷が高くなります。

この場合、このマシンのどのRedisインスタンスのトラフィックが多すぎてネットワーク帯域幅がいっぱいになっているのかを確認してから、トラフィックの急激な増加が通常のビジネス状況であるかどうかを確認する必要があります。そうである場合は、拡張または移行する必要があります。これを回避するための時間内のインスタンスマシンの他のインスタンスが影響を受けます。

運用・保守レベルでは、ネットワークトラフィックを含むマシンのさまざまな指標の監視を強化し、しきい値に達したときに事前に警告し、時間内にビジネスに確認し、容量を拡張する必要があります。

上記では、遅延の増加やブロックにつながる可能性のあるRedisの一般的なシナリオを要約しました。これには、ビジネス使用の問題とRedisの運用および保守の問題の両方が含まれます。

Redisの高性能な動作を保証するために、オペレーティングシステムの関連機能の使用を含め、CPU、メモリ、ネットワーク、さらにはディスクのすべての側面が関係していることがわかります。

開発者は、各コマンドの実行時間の複雑さ、データの有効期限戦略、データ除去戦略など、Redisの操作メカニズムを理解し、合理的なコマンドを使用して、ビジネスシナリオと組み合わせて最適化する必要があります。

DBAの運用および保守担当者は、データの永続性、オペレーティングシステムのフォークの原則、スワップメカニズムなどを理解し、Redisの容量を合理的に計画し、十分なマシンリソースを予約し、マシンを完全に監視して安定性を確保する必要があります。 Redisの実行。

Redisのベストプラクティス：ビジネスレベルと運用および保守レベル

上記では、主に不当なビジネス使用と不適切な運用および保守によって引き起こされる、Redisの一般的な速度低下シナリオと問題の場所および分析について説明しました。

Redisの速度が低下する理由を理解したら、Redisを安定させ、ターゲットを絞って最適化することでパフォーマンスを向上させることができます。

次に、Redisを使用する際のベストプラクティスを要約します。これには、主にビジネスレベルと運用および保守レベルの2つのレベルが含まれます。

以前に多くのUGCバックエンドサービスを作成し、多くのシナリオでRedisを使用したことがあるので、このプロセスでも多くの落とし穴を踏んだので、使用中の一連の合理的な使用方法も要約しました。処理する。

その後、基本的なアーキテクチャを作成し、CodisおよびRedis関連のミドルウェアを開発しました。この段階では、この分野の焦点は、Redisの使用レベルから開発および運用に移り、 Redisの内部実装と運用および保守。、この分野でもある程度の経験を積んでいます。

これらの2つの領域について、Redisの合理的な使用方法と運用および保守について説明します。これは、最も包括的ではなく、Redisの使用方法とは異なる場合がありますが、次の方法があります。ピットを踏んだ後に要約した実際の結論。参考までに、経験してください。

ビジネスレベル

ビジネスレベルでは、開発者は注意を払う必要があります。つまり、ビジネスコードを作成するときにRedisを合理的に使用する方法です。開発者は、ビジネスレベルによって引き起こされる遅延を回避するために、適切なビジネスシナリオでRedisを使用するために、Redisの基本を理解している必要があります。

開発プロセス中のビジネスレベルでの最適化の提案は次のとおりです。

• キーの長さはできるだけ短くする必要があります。データ量が非常に多い場合、長いキー名はより多くのメモリを占有します。

• 過度に大きなデータ（大きな値）を格納しないように注意してください。過度に大きなデータは、メモリの割り当てと解放に多くの時間を消費し、メインスレッドをブロックします。

• Redis 4.0以降では、メインスレッドをブロックすることなく、大きな値が解放されたときにレイジーフリーメカニズムが非同期で動作できるようにすることをお勧めします。

• 有効期限を設定し、Redisをキャッシュとして使用することをお勧めします。特に数が多い場合は、有効期限を設定しないと、メモリが無制限に増加します。

• SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTOREなどの非常に複雑なコマンドは使用しないでください。これらのコマンドの使用には時間がかかり、メインスレッドがブロックされます。

• データをクエリするときは、一度に取得するデータをできるだけ少なくするようにしてください。コンテナ要素の数がわからない場合は、LRANGEキー0-1やZRANGEキー0-1などの操作を避けてください。特定のクエリ要素。一度に100未満の要素をクエリすることをお勧めします。

• データを書き込むときは、HSET key value1 value2 value3 ...など、一度に書き込むデータをできるだけ少なくし、一度に書き込む要素の数を制御するようにしてください。100未満で、データ量が多いことをお勧めします。複数のバッチで書かれています。

• データをバッチで操作する場合は、GET / SETをMGET / MSETに置き換え、HGET / HSETをHMGET / MHSETに置き換えて、ネットワークIO要求の数を減らし、遅延を減らします。バッチ操作のないコマンドの場合は、次を使用することをお勧めします。複数のコマンドを一度にサーバーに送信するパイプライン

• KEYSコマンドの使用は禁止されています。インスタンスをスキャンする必要がある場合は、SCANを使用することをお勧めします。Redisのパフォーマンスのジッターを回避するために、オンライン操作でスキャン頻度を制御する必要があります。

• 特定の時点で多数のキーが期限切れになるのを防ぐために、有効期限が集中しているときにランダムな時間を追加して有効期限を分割し、キーが集中して期限切れになったときにRedisの圧力を下げて回避することをお勧めします。メインスレッドをブロックします。

• ビジネスシナリオに従って、適切な削除戦略を選択します。通常、データを削除するには、ランダムな有効期限がLRUの有効期限よりも速くなります。

• 接続プールを使用してRedisにアクセスし、接続が短くならないように適切な接続プールパラメータを設定します。TCPスリーウェイハンドシェイクと4つのウェーブハンドも時間がかかります。

• db0のみを使用してください。複数のデータベースを使用することはお勧めしません。複数のデータベースを使用すると、Redisの負担が大きくなります。異なるデータベースにアクセスするたびに、SELECTコマンドを実行する必要があります。ビジネスラインが異なる場合は、複数のインスタンスを分割することをお勧めします。単一のインスタンスを増やします。パフォーマンス。

• 読み取り要求の数が多い場合は、セクションからのデータを時間内に更新しないという問題を許容できる限り、読み取りと書き込みの分離を使用することをお勧めします。

• 書き込み要求の量が多い場合は、クラスターを使用し、複数のインスタンスをデプロイして書き込みプレッシャーを共有することをお勧めします。

運用レベル

運用と保守のレベルは、主にDBAが注意を払う必要があるものです。目的は、Redisの展開を合理的に計画し、Redisの安定した運用を確保することです。主な最適化は次のとおりです。

• 異なるビジネスラインの異なるインスタンスを互いに独立してデプロイして、混合を回避します。異なるビジネスラインが異なるマシンを使用し、ビジネスの重要性に応じて異なるグループにデプロイして、あるビジネスラインの問題が他のビジネスに影響を与えないようにすることをお勧めします。行;

• 過度の負荷がRedisのパフォーマンスに影響を与えないように、マシンに十分なCPU、メモリ、帯域幅、およびディスクリソースがあることを確認してください。

• インスタンスをマスタースレーブクラスターにデプロイし、それらを異なるマシンに分散して、単一のポイントを回避します。スレーブは読み取り専用に設定する必要があります。

• マスターノードとスレーブノードが配置されているマシンは互いに独立しています。インスタンスを相互展開しないでください。通常、バックアップ作業はスレーブで実行されるため、バックアップを実行するときにマシンリソースが消費されます。相互展開は影響します。マスターのパフォーマンス。

• 可用性を高めるためにセンチネルノードを展開することをお勧めします。ノードの数は少なくとも3つで、障害の自動フェイルオーバーを実現するために異なるマシンに分散する必要があります。

• 事前に容量を計画します。マシン展開インスタンスのメモリの上限は、マシンのメモリの半分であることが望ましいです。マスタースレーブ同期は、大規模なネットワーク障害が原因でメモリが発生するのを防ぐために、メモリスペースの最大2倍を占有します。すべてのマスタースレーブの全量同期により、マシンのメモリが消費されます。

• マシンのCPU、メモリ、帯域幅、ディスクを適切に監視し、リソースが不足している場合はすぐにアラームを発します。RedisがSwapを使用すると、パフォーマンスが急激に低下し、ネットワーク帯域幅の負荷が高くなり、アクセス遅延が発生します。ディスクIOが高すぎる場合、AOFをオンにするとRedisのパフォーマンスが低下します。

• 過剰なクライアント接続が過剰なサービス負荷を引き起こさないように、接続の最大数の上限を設定します。

• 単一インスタンスのメモリ使用量は10G未満に制御することをお勧めします。インスタンスが大きすぎると、バックアップ時間が長くなり、リソース消費量が多くなり、マスタースレーブの完全なデータ同期のブロック時間が長くなります。

• 妥当なスローログしきい値を設定し、10ミリ秒を推奨し、それを監視します。生成されるスローログが多すぎる場合は、タイムリーなアラームが必要です。

• レプリケーションバッファrepl-backlogの適切なサイズを設定し、repl-backlogを適切に増やして、マスタースレーブの完全なレプリケーションの可能性を減らします。

• スレーブノードの適切なclient-output-buffer-limitサイズを設定します。書き込み量が多いインスタンスの場合、サイズを適切に増やすことで、マスタースレーブレプリケーションの中断を回避できます。

• マスターのパフォーマンスに影響を与えないスレーブノードでバックアップを実行することをお勧めします。

• ディスクIOの消費を回避し、Redisのパフォーマンスを低下させるために、AOFを有効にしたり、AOF構成を有効にしてディスクを毎秒フラッシュしたりしないでください。

• インスタンスがメモリの上限を設定し、メモリの上限を増やす必要がある場合は、最初にスレーブを調整してからマスターを調整します。そうしないと、マスターノードとスレーブノードのデータに一貫性がなくなります。

• Redisに監視を追加します。情報情報を監視および収集するときは、長い接続を使用します。頻繁に短い接続を行うと、Redisのパフォーマンスにも影響します。

• オンラインでインスタンスの総数をスキャンするときは、スキャン中にQPSが突然増加して、Redisでパフォーマンスのジッターが発生しないように、スリープ時間を設定することを忘れないでください。

• 特にexpired_keys、evicted_keys、latest_fork_usecインジケーターなど、Redisのランタイムモニタリングを適切に行ってください。これらのインジケーターの値が短期間に急激に増加すると、インスタンス全体がブロックされ、パフォーマンスの問題が発生する可能性があります。

上記は、私がRedisを使用してRedis関連のミドルウェアを開発するときにRedisが推奨する実践方法です。上記のこれらの側面は、実際の使用で多かれ少なかれ遭遇しました。

Redisの高いパフォーマンスを安定して発揮するためには、あらゆる面で良い仕事をする必要がありますが、ある面で問題が発生すると、必然的にRedisのパフォーマンスに影響を及ぼし、使用に対する要件が高くなります。運用および保守。

より多くの問題が発生した場合、またはRedisの使用経験が豊富な場合は、メッセージを残して一緒に話し合うことができます。

                      パブリックアカウント「Javaシニアアーキテクト」、「インタビューの質問」への返信入手：大廠からの実際のインタビューの質問のHD3585ページ

​