Redis のブロック問題のトラブルシューティング

Redis はシングルスレッド アーキテクチャであり、すべての操作はメイン スレッドで完了します。したがって、Redis がブロックされると、それは悪夢になります。次に、Redis のブロック問題を見てみましょう。トラブルシューティングと解決方法。

Redis データ構造または API の不合理な使用

大きなオブジェクトがあり、大きなオブジェクトに対して複雑で高度なコマンドが実行されます

#1. 数千万の要素を含むハッシュに対して hgetall 操作または del 操作を実行します。同様の操作により Redis がブロックされます

2. このような大きなオブジェクトの場合は、redis を使用できます-cli -h {host} -p {port} 表示するビッグキー。ただし、このコマンドは特定のタイプの最大のキーのみを照会できます。複数のクエリを実行したい場合。 redis-cli ソース コードを変更できます (Redis のソース コードは C です)。ソース コードを変更したくない場合は、スキャンを使用してソース コードを完成させることもできます。

Scan コマンドに注意する必要があります。このコマンドは、単一の Redis 上のデータのみをスキャンできます。クラスターの場合は、各マシンで 1 回実行する必要があります。ただし、オープン ソース クライアント (例: Java の Lettuce クライアント) を使用している場合は、クラスター全体をスキャンするスキャン コマンドの実装にすでに役立ちます。

3. 次に、大きなオブジェクトを分割します。具体的な分割はビジネスによって異なります。

Redis の CPU 使用率は 100% に近いです。

1. スレーブはホスト データを同期します。スレーブは rdb ファイルを受信した後、ディスク

#2 からデータをロードし、マスター/スレーブはデータを永続化します。

3. CPU 使用率が 100% に達した場合は、実際のビジネス訪問数が非常に多い可能性があります。 1 つの Redis は 1 秒あたり 60,000 リクエストを処理できます。現時点では、水平方向の拡張しか実行できません。

4. 1 秒あたりの Redis 操作数が数百または数千にすぎず、CPU がまだ非常に高い場合は、高い処理能力を持つコマンドを使用することが可能です。アルゴリズムの複雑さ。たとえば、hgetall。もう 1 つの可能性は、メモリが過剰に最適化されていることです。このような状況はまだ発生していませんが、それも考慮されています。

Cpu 競合

1. Redis は CPU を集中的に使用するアプリケーションであるため、他の CPU を集中的に使用するサービスとのデプロイメントには適していません。

2. 運用環境では、サーバーの 1 台の構成は 32 コアの論理 CPU と 256 GB のメモリです。各マシンに Redis を 1 つだけデプロイするのは無駄です。したがって、複数の Redis を 1 台のマシンにデプロイすることができます。 Redis プロセスは通常、CPU にバインドされています。ただし、RDB ファイルや AOF 永続化を生成すると、子プロセスが生成されます。このようにして、子プロセスと親プロセスが CPU を奪い合います。したがって、永続性またはマスターノードをオンにするとき。 CPU をバインドすることはお勧めできません

メモリ交換

Redis はインメモリ データベースであり、すべてのデータはメモリに配置されます。したがって、メモリ スワップを有効にしないことを強くお勧めします。

ネットワークの問題

マスターとスレーブの同期ネットワーク遅延が大きい場合、スレーブ マシンが頻繁に切断され、再接続されます。 。長時間切断した場合。その結果、スレーブ マシンはマスター マシンに再度接続するときに完全に同期されます。このとき、マスター マシンとスレーブ マシンの両方が影響を受けます。

Redis の詳細については、注意してください。

redis 入門チュートリアル

列に移動します。

以上がRedis のブロック問題のトラブルシューティングの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。