Redis (3) ストレージ原則とデータ モデル (ハッシュ競合、プログレッシブ リハッシュ)

Redis シリーズの記事

Redis (1) 原理と基本コマンド (フレキシブル アレイ)
Redis (2) ネットワーク プロトコルと非同期モード (楽観的ロックと悲観的ロック)
Redis (3) ストレージ原理とデータ モデル (ハッシュ競合、プログレッシブ リハッシュ)
Redis ジャンプ テーブル


1. Redis ストレージ構造

Redis はキーと値の構造であり、値には辞書、二重リンク リスト、圧縮リスト、スキップ リスト、整数配列、動的文字列が含まれます。
ここに画像の説明を挿入

ストレージ変換

Redis の各値のデータ構造には、状況に応じて異なる自動ストレージ変換があります。
ここに画像の説明を挿入

キーと値のストアの実装

Redis の KV 構成は、ディクショナリ、つまりハッシュ テーブルを通じて実装されます。キー文字列はハッシュ関数によって計算され、64 ビット整数が取得されます。

ハッシュの競合

Redis がハッシュ テーブルを使用してキーと値を保存すると、ハッシュの競合が発生します。一般的なハッシュ競合解決方法は次のとおりです。

  • オープンチェーン方式: ハッシュ競合の値をリンクリストで接続し、各ハッシュ結果のキー値の下にリンクリストを接続します。リンク リストが長すぎる場合は、最適化のためにリンク リストを赤黒ツリーに変換できます。
  • rehash: ハッシュ バケットのサイズを増やします。Redis には 2 つのハッシュ テーブルがあり、ハッシュ テーブル 1 が競合する場合はハッシュ テーブル 2 が使用され、通常、ハッシュ テーブル 2 のハッシュ バケット サイズはハッシュ テーブル 1 の 2 倍になります。

ただし、再ハッシュする場合、ハッシュ テーブル 1 のデータをハッシュ テーブル 2 にコピーするのは大規模なプロジェクトとなり、Redis スレッドのブロックが発生し、Redis のパフォーマンスに影響を与える可能性があります。したがって、redis には、この問題を解決するためのプログレッシブ再ハッシュ メカニズムが備わっています。

漸進的な焼き直し

プログレッシブリハッシュも、リハッシュと同様に、ハッシュ テーブル 1 のデータをハッシュ テーブル 2 にコピーする必要がありますが、このコピー プロセスは 1 回限りではなく、段階的にブロック転送されます。

Redis のプログレッシブには 2 つのルールがあります。

  1. 分割統治の考え方では、操作の追加、削除、変更、確認の各ステップに再ハッシュを分割します。つまり、redis が処理されるたびにキーをコピーします。
  2. タイマーでは、最大 1 ミリ秒の再ハッシュが実行され、毎回 100 個の配列キー スロットがコピーされます。

リハッシュプロセス中に追加、削除、チェック、変更があった場合はどうなりますか?

  • 検索: データを検索する場合、まずハッシュ テーブル 1 のデータを検索し、見つからない場合はハッシュ テーブル 2 のデータを検索します。
  • 追加: 新しいデータが追加される場合、ハッシュ テーブル 2 にのみ追加され、ハッシュ テーブル 1 に対して操作は実行されません。
  • 削除と変更: 両方のテーブルで操作できます。

再ハッシュ拡張に加えて、Redis は容量を縮小するときにも再ハッシュを使用します。
しかし、焼き直しフェーズでは拡大も縮小も起こらなくなります。リハッシュが終了するまで待つ必要があります。

大きな鍵

Redis インスタンスでは、大きなハッシュや大きな zset などの大きなオブジェクトが形成された場合、そのようなオブジェクトが展開されると、一度により大きなメモリが適用されるため、フリーズが発生します。大きなキーを削除すると、メモリが一度に再利用され、再びフリーズ現象が発生します。redis のメモリが大きく変動することが観察された場合は、大きなキーが原因である可能性が高くなります。

解決:

  • 分割値
  • 圧縮された値
  • 非ホットスポットの大きなキーを削除します (Redis の非同期メカニズムを使用して削除できます)

ジャンプ台

Redisのソートセット(Sorted Set)はスキップリスト(Skip list)で実装されています。ジャンプ テーブルは、順序付きノード シナリオにおけるリンク リストのクエリ時間の複雑さの問題を解決するためのものです。時間計算量は O(logn) に達する場合があります。
詳細については、Redis ジャンプ テーブルを参照してください。

おすすめ

転載: blog.csdn.net/weixin_44477424/article/details/131753476