Redis メモリが大きすぎる場合はどうなりますか?

1 メイン データベースのダウンタイム

まず、以下に示すように、メイン データベースのダウンタイムの災害復旧プロセスを見てみましょう。 #In メイン データベースがダウンした場合、最も一般的な災害復旧戦略は「メイン データベースを切断する」ことです。具体的には、クラスタに残っているスレーブ ライブラリからスレーブ ライブラリを選択してマスター ライブラリにアップグレードし、スレーブ ライブラリがマスター ライブラリにアップグレードされた後、残りのスレーブ ライブラリがその下にマウントされてスレーブ ライブラリになり、最終的にはスレーブ ライブラリがマスター ライブラリにアップグレードされます。マスター/スレーブ データベース全体が復元されます クラスター構造。

上記は完全な災害復旧プロセスであり、最もコストがかかるプロセスは、メイン ライブラリの切り替えではなく、スレーブ ライブラリの再マウントです。

これは、mysql や mongodb などの同期ポイントに基づいてメイン データベースが変更された後、redis が新しいメイン データベースからのデータの同期を続行できないためです。スレーブ データベースが Redis クラスター内のマスターを変更すると、Redis のアプローチは、置き換えられたマスター データベースのスレーブ データベースをクリアし、転送を再開する前に新しいマスター データベースからのデータのコピーを完全に同期します。

スレーブ データベースのやり直しプロセス全体は次のとおりです。

メイン ライブラリは、独自のデータをディスクに保存します。

1. メイン ライブラリは rdb ファイルをスレーブ ライブラリに送信します。

2. ライブラリからロードを開始します。

3. ロードが完了すると、アップロードが再開され、サービスは同時に開始されます

4. 明らかに、このプロセス中の Redis のメモリ サイズが大きいほど、上記の各ステップの時間は長くなります。実際のテスト データは次のとおりです(マシンのパフォーマンスが向上していると信じています):

データが 20G に達すると、スレーブ データベースの回復時間が 20 近くまで延長されていることがわかります。分。10 個のスレーブ データベースがある場合、順番に回復するには合計 10 個のスレーブ データベースがかかります。200 分かかります。この時点でスレーブ ライブラリが大量の読み取りリクエストを処理している場合、このような長い回復を許容できますか?

これを見ると、必ず疑問に思うでしょう:なぜすべてのスレーブ ライブラリを同時にやり直すことができないのでしょうか?これは、すべてのスレーブ ライブラリが同時にメイン ライブラリから RDB ファイルを要求すると、そうすると、図書館本館のネットワークカードがすぐにいっぱいになってしまい、正常にサービスが提供できない状態になり、そのとき本館図書館はまた死んでしまいますし、追い打ちをかけるだけです。

もちろん、スレーブ データベースをバッチで (たとえば 2 つのグループで) 復元することもできますが、その場合、すべてのスレーブ データベースの回復時間は 200 分から 100 分に短縮されるだけです。

もう 1 つの重要な問題は、4 番目のポイントの赤色の位置にあります。再開転送は、簡略化された mongodb oplog として理解できます。これは、固定ボリュームのメモリ空間であり、これを私たちが呼んでいます。 「同期バッファ」。

Redis メイン ライブラリの書き込み操作はこの領域に保存され、スレーブ ライブラリに送信されます。上記の手順 1、2、および 3 に時間がかかりすぎる場合、同期バッファーがRewrite の場合、スレーブ ライブラリが対応する再開場所を見つけられない場合はどうなりますか? 答えは、ステップ 1、2、および 3 をやり直すことです!

しかし、時間のかかるステップ 1、2 を解決できないためです。 、および 3 したがって、スレーブ ライブラリは永久に悪循環に陥ることになります。つまり、スレーブ ライブラリはメイン ライブラリに完全なデータを常に要求し、メイン ライブラリのネットワーク カードに重大な影響を与えることになります。

2 容量拡張の問題

トラフィックが突然増加することがよくありますが、通常、原因が判明する前に緊急対応として容量を拡張します。

シナリオ 1 の表によると、20G Redis スレーブ データベースを拡張するには 20 分近くかかります。この重要な瞬間に 20 分のビジネスは耐えられますか? 拡張が完了する前に機能しなくなる可能性があります。

3 ネットワークが貧弱であると、スレーブ ライブラリがやり直しになり、最終的には雪崩が発生します。

このシナリオの最大の問題は、マスター ライブラリとスレーブ間の同期が確立されていないことです。スレーブ ライブラリはまだ書き込み要求を受け入れている可能性が高いため、中断時間が長すぎると同期バッファが上書きされる可能性があります。このとき、スレーブライブラリの最後の同期位置が失われており、ネットワーク復旧後、マスターライブラリは変更されていないものの、スレーブライブラリの同期位置が失われているため、スレーブライブラリをやり直す必要があります。問1の1、2、3の4ステップ。このとき、メイン ライブラリのメモリ サイズが大きすぎると、スレーブ ライブラリの REDO 速度が非常に遅くなり、スレーブ ライブラリに送信される読み取りリクエストに重大な影響を与えます。転送された rdb ファイルが大きすぎると、メインライブラリのネットワークカードが長期間にわたって深刻な影響を受けます。

4 メモリが大きくなるほど、永続性をトリガーする操作がメイン スレッドをブロックする時間が長くなります。

Redis はシングルスレッドのメモリ内データベースです。redis では、時間のかかる操作を実行する必要があるため、操作中に bgsave や bgrewriteaof などの新しいプロセスがフォークされます。新しいプロセスをフォークするとき、共有可能なデータ コンテンツをコピーする必要はありませんが、前のプロセス領域のメモリ ページ テーブルがコピーされます。このコピーはメイン スレッドによって実行され、すべての読み取りおよび書き込み操作がブロックされます。メモリ使用量が増加するため、時間がかかります。たとえば、20G のメモリを備えた Redis の場合、bgsave はメモリ ページ テーブルをコピーするのに約 750 ミリ秒かかり、Redis メイン スレッドも 750 ミリ秒ブロックされます。

#解決策

解決策は、もちろんメモリ使用量を削減することです。通常の状況では、これを実行します:

1 セット有効期限

時間に敏感なキーの有効期限を設定し、redis 独自の期限切れキーのクリーンアップ戦略を使用して、期限切れキーのメモリ使用量を削減します。また、ビジネス上の問題を軽減し、必要な作業を排除することもできます。定期的にクリーンアップする必要があります

2 redis にゴミを保存しないでください

これはまったくナンセンスですが、私たちと同じ問題を抱えている人はいますか?

3 不要なデータを適時にクリーンアップする

たとえば、次のようにします。 Redis には 3 つのビジネス データが含まれています。一定の時間が経過すると、2 つのビジネスがオフラインになった場合、これら 2 つのビジネスの関連データをクリーンアップする必要があります。

4 データをできるだけ圧縮してください。

たとえば、一部の長いテキスト データの場合、圧縮によってメモリ使用量が大幅に削減される可能性があります

#5 メモリの増加に注意し、大容量のキーを見つけてください

DBA であろうと開発者であろうと、Redis を使用するときはメモリに注意を払う必要があります。そうでないと、実際には無能です。ここでは、Redis インスタンス内のどのキーが比較的大きいかを分析して、ビジネスを迅速に支援できます。異常なキーを特定します (多くの場合、キーの予期せぬ増加が問題の原因です)

6 pika

本当に疲れたくない場合は、移行してください。ビジネスを新しいオープンソース pika に移行することで、メモリにあまり注意を払う必要がなくなります。Redis メモリによって引き起こされる問題はもう問題ではありません。

以上がRedis メモリが大きすぎる場合はどうなりますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。