Redis で Big Key 問題を解決する方法

1. Big Key とは何ですか?

簡単に言えば、Big Key とは、特定のキーに対応する値が非常に大きく、大量の Redis スペースを占有することを意味します。大きな値の問題です。 キーはプログラム自体によって設定できることが多く、値はプログラムによって制御されないことが多いため、値が非常に大きくなることがあります。

これらの Big Key に対応する Redis の値は非常に大きく、シリアル化/逆シリアル化のプロセスに時間がかかるため、Big Key を操作する場合、通常は時間がかかります。 Redis ブロックが発生するため、Redis のパフォーマンスが低下します。

いくつかの実用的な例を使用して、大きなキーの特性を説明します:

#● 文字列型のキー、その値は 5MB (データが大きすぎます);

● A List 型のキー、そのリストの数は 20,000 (リストの数が多すぎます);

# ZSet 型のキー、そのメンバーの数は 10,000 (メンバーの数が多すぎます) );

# ハッシュ形式のキーにはメンバーが 1,000 個しかありませんが、これらのメンバーの値の合計サイズは 100MB です (メンバー サイズが大きすぎます);

実際のビジネスにおいては、依然として Redis の実際の利用シーンやビジネスシナリオに基づいて、ビッグキーの決定を総合的に判断する必要があります。通常、データのサイズとメンバーの数によって判断されます。

2.ビッグキー発生シーン？

1. Redis データ構造の不適切な使用

Redis の機能に適していないシナリオで Redis を使用すると、キーの値が大きくなりすぎます。 String型のKeyを使用すると、大容量のバイナリファイルデータが格納されます。

2. ジャンクデータを適時にクリーンアップできなかった場合

無効なデータを定期的にクリーンアップできなかったために、HASH タイプのキーのメンバー数が増加し続けます。を増やす。削除機構を持たずにデータを受信し続けるだけなので、価値は無限に増加します。

3. 不正確な事業見積り

事業開始前の計画・設計における検討が不十分で、Key 内のメンバーを合理的に分割できず、個々の Key に不正確さが生じる メンバーが多すぎる。

4. 有名人やインターネット有名人のファンのリスト、および特定のホットなニュース項目に対するコメントのリスト

List データ構造を使用して、特定の芸能人・ネット有名人のファンや、話題のニュースのコメント一覧を保存 話題のニュースはファンの数が多いため、クリック率やコメント数も多く、保存される要素が多くなりますList コレクションの場合、値が大きすぎてビッグ キーの問題が発生する可能性があります。

3. Big Key の危険性は何ですか?

1. ブロッキングリクエスト

Big Keyに相当する値が大きいため、読み書きすると時間がかかり、ブロッキングが発生する可能性があります。リクエスト処理。 Redis のコア スレッドはシングルスレッドであるため、すべてのリクエストがシリアルに処理され、前のリクエストが完了しない場合、後続のリクエストは処理されません。

2. メモリの増加

Big Key の読み取りに消費されるメモリは、通常の Key に比べて増加します。増加し続けると、OOM (メモリ不足) が発生する可能性があります。オーバーフロー）、または redis の最大メモリ maxmemory 設定値に達すると、書き込みブロックが発生したり、重要なキーが削除されたりします。

3. ネットワークのブロック

大きな単一値を読み取ると、サーバー ネットワーク カードのより多くの帯域幅を占有し、速度が低下し、他のサーバーに影響を与える可能性があります。サーバー、Redis インスタンスまたはアプリケーション。

4. マスター/スレーブ同期およびマスター/スレーブ切り替えへの影響

大きなキーを削除すると、メイン ライブラリが長時間ブロックされ、同期が発生します。中断またはマスター/スレーブ切り替え。

4. ビッグキーを特定するにはどうすればよいですか?

1. redis に付属のコマンド ID を使用します

たとえば、公式 Redis クライアント redis-cli と --bigkeys パラメーターを使用して、インスタンス 5 データ型の最大のキー (文字列、ハッシュ、リスト、セット、zset)。

利点は、サービスをブロックすることなくオンラインでスキャンできることですが、欠点は、情報が少なく、コンテンツが十分正確ではないことです。

2. デバッグ オブジェクト キー コマンド

を使用して、受信オブジェクト (キーの名前) に従ってキーを分析し、大量のデータを返します。ここで、serializedlength の値は、キーのシリアル化された長さです。キーのシリアル化された長さは、メモリ空間内の実際の長さと等しくないことに注意してください。さらに、デバッグ オブジェクトはデバッグ コマンドです。実行にはコストがかかります。実行中に「Redis への残りのリクエストは完了するまでブロックされます」と入力します。また、一度に検索できるのは 1 つのキーの情報のみであるため、公式には推奨されていません。

3. redis-rdb-tools オープン ソース ツール

この方法では、redis インスタンスで bgsave を実行します。bgsave は、redis のスナップショット バックアップをトリガーし、rdb を生成します。 persistence.ファイルを作成し、ダンプされた rdb ファイルを分析してその中に大きなキーを見つけます。

メリットは取得したキー情報が詳細であること、オプションパラメータが多いこと、カスタマイズ要件に対応していること、結果情報はjsonまたはcsv形式で選択でき、その後の処理が便利であること、デメリットはオフラインでの操作が必要であり、結果が得られるまでに時間がかかること。

5. ビッグキー問題を解決するにはどうすればよいですか?

ビッグ キーの問題を解決するには、キーに対応する値のサイズを減らすこと、つまり、文字列データ構造の場合は保存される文字列の長さを減らすこと、リストの場合は、 Hash、Set、ZSet のデータ構造 コレクション内の要素の数を減らすためです。

1. 大きなキーを分割する

將一個Big Key拆分為多個key-value這樣的小Key，並確保每個key的成員數量或者大小在合理範圍內，然後再進行存儲，通過get不同的key或者使用mget批量獲取。

2、對大Key進行清理

對Redis中的大Key進行清理，從Redis中刪除此類資料。 Redis自4.0起提供了UNLINK指令，該指令能夠以非阻塞的方式緩慢逐步的清理傳入的Key，透過UNLINK，你可以安全的刪除大Key甚至特大Key。

3、監控Redis的記憶體、網路頻寬、逾時等指標

透過監控系統並設定合理的Redis記憶體警報閾值來提醒我們此時可能會有大Key正在產生，如：Redis記憶體使用率超過70%，Redis記憶體1小時內成長率超過20%等。

4、定期清理失效資料

堆積大量失效資料會發生，如果有某個Key一直在以增量方式寫入大量數據，但忽略了數據的時效性。可以透過定時任務的方式，對失效資料進行清理。

5、壓縮value

用序列化和壓縮演算法控制key的大小，但需要注意序列化和反序列化都會造成一定的效能消耗。如果壓縮後，value仍然非常大，那麼可以考慮進一步拆分key。

補充知識：key設計

(1)【建議】: 可讀性與可管理性

以業務名稱(或資料庫名稱)為前綴(防止key衝突)，用冒號分隔，例如業務名稱:表名:id
o2o:order:1

(2)【建議】：簡潔性

保證語意的前提下，控制key的長度，當key較多時，記憶體佔用也不容忽視，例如：
user:{uid}:friends:messages:{mid} 簡化為u:{uid} m:{mid}

(3)【強制】：不要包含特殊字元

#反例：包含空格、換行、單雙引號以及其他轉義字元

以上がRedis で Big Key 問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。