Redis データの量が大きすぎる場合の対処方法

インメモリ データベースである redis のパフォーマンスと安定性の高さには疑いの余地がありませんが、redis にデータを詰め込みすぎてメモリが大きすぎると、 、その後、何か問題が発生した場合、それは私たちに災害をもたらす可能性があります。

ここ数年のオンライン ビジネスでは、インメモリ データベースである Redis のパフォーマンスと安定性が高いことは疑いの余地がありませんが、Redis とメモリにあまりにも多くのデータを詰め込みすぎていました。大きすぎた。何か問題が発生した場合、それは私たちに災害をもたらすかもしれません（多くの企業がそれに遭遇したと思います）。ここに私たちが遭遇した問題のいくつかがあります：

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

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

#解決策

解決策は、もちろんメモリの使用を最小限に抑えることです。通常の状況では、これを実行します。

1 有効期限の設定

時間に敏感なキーの有効期限を設定し、Redis 独自の期限切れキーのクリーンアップ戦略を通じて期限切れキーのメモリ使用量を削減します。トラブル、定期的にクリーンアップする必要はありません

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

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

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

たとえば、Redis には 3 つのビジネスのデータが含まれており、一定期間後に 2 つのビジネスがオフラインになります。 2 つのビジネスの関連データはクリーンアップされました。

4 データを圧縮してみてください。

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

5 メモリの増加に注意し、大容量のキーを見つける

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

6 pika

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

Redis 関連の技術記事の詳細については、

「Redis データベース チュートリアルの使用方法の概要」

列にアクセスして学習してください。

以上がRedis データの量が大きすぎる場合の対処方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。