Redisのシリーズは------ Redisのオブジェクト（8）は、メモリを理解します

序文

Redisのは、直接、キーと値のペアを達成するためにデータ構造を使用していないデータベースを、これらのデータ構造に基づいて文字列が含まれているオブジェクトシステムを作成するには、リスト、ハッシュオブジェクト、オブジェクトのコレクションと5つのオブジェクトのコレクションを命じましたオブジェクトの種類は、各オブジェクトは、我々が先に記載の少なくとも1つのデータ構造を使用します。オブジェクトの5種類により、 Redisのは、オブジェクトがコマンドを実行することができる与えられているかどうかを決定するために、オブジェクトの種類に応じて、コマンドを実行する前にすることができます。オブジェクトを使用する別の利点は、さまざまなシーンでのオブジェクトの使用効率を最適化するように、我々は、異なるデータ構造の多様性を達成するために、オブジェクトに設定された異なるシナリオのために使用することができるということです。

また、Redisのシステムオブジェクトは、に基づいて達成されるカウント参照のRedisで参照してさらに、プログラムがもはやオブジェクトを使用している場合、オブジェクトによって占められるメモリは自動的に解放されない：ガベージコレクション機構の技術をテクノロジーオブジェクト共有メカニズムを数え、このメカニズムは、適切な条件下で、メモリデータベースを保存するために複数のキーを持つことによって、同じオブジェクトを共有することができます。

符号化対象の種類

Redisのデータベース内のキーと値を表すためにオブジェクトを使用し、我々はRedisのデータベースに新しいキーと値のペアを作成するたびに、我々は、キーと値のペアとして使用されるオブジェクト（キーオブジェクト）は、少なくとも2つのオブジェクトを作成します別の目的は、キーと値のペア（目標値）として使用されます。

Redisの各オブジェクトが表されるのRedisのオブジェクト構造、構造及びそれぞれのtype属性に関連する3つのストアドデータ、プロパティおよびプロパティPTR符号化の性質は言いました：

1のtypedef 構造体redisObject {
 2  
3。     // タイプ
4。      unsigned型：4 ;
 5。 
6。     // 符号
7。      符号なしエンコーディング：4 ;
 8。 
9。     // 点基礎となる実装ポインタのデータ構造への
10      ボイド * PTR;
 11。 
12である     // ... 
13は、 
14 } robj。

私たちは、オブジェクトは三つの主要なフィールドが含まれて見ることができます。

タイプ：オブジェクトの種類を示します。などの文字列、リスト、ハッシュ、など

エンコーディング：どのような基本的なデータ構造によって表されるオブジェクト。等INT（整数）、EMBSTR（簡潔なバージョンSDS）、RAW（SDS）、HT（マップ）として

PTRは：PTRは、使用されるオブジェクトデータ構造へのポインタです。

下図のように：

セットKV

kは、SDSの簡潔なバージョン、フォローアップの話であるString型、embstrデータ構造、です。

www.wityx.com

embstrおよびSDSの違い

我々は、データ構造について話embStrを見ていない前に、はい、私はまた、このセクションでは、これだけの事を知ってご覧ください。

RedisのembStrに従事し、最適化するためには、彼は短い文字列の最適化をコードメモリに専用されています。

embstr メモリ割り当てられたコードの数からしたい文字列オブジェクトを作成します raw 一度符号化された2つの下。raw コーディングは、それぞれ、作成するために、二回のメモリ割り当て関数と呼ばれる redisObject 構造と sdshdr 建築を、そして embstr コーディングは、メモリ割り当て機能により、一度呼び出される連続した領域のブロック割り当て順にスペースが含まれ、 redisObject そして sdshdr 二つの構造を。、連続不連続ので。

リリース embstr エンコードさ文字列オブジェクトのみを解放するメモリ解放機能一度呼び出す必要がある raw 二つのメモリ割り当て解除関数を呼び出すために、文字列のエンコーディングを。同上

ので embstr エンコードされた文字列オブジェクトは、内部の連続したメモリに格納されたデータなので、よりこのエンコードされた文字列オブジェクトのすべての raw エンコードされた文字列オブジェクトは、キャッシュがもたらすを利用しやすくなります。

embstrはメモリの連続割り当てであるため、一般的に、それはメモリを割り当て作ることは再び解放されるので、効率が向上します。一方embste <==> SDS 44バイトです。

図から、我々ははっきりと見ることができます。LEN生に44の遷移<= 44は、lenの場合embsterデータ構造です>を。なぜ44について。

あなたは数えるに行くことができます。参考記事：

https://zhuanlan.zhihu.com/p/67876900

https://xiaoyue26.github.io/2019/01/19/2019-01/redis%E7%9A%84embstr%E4%B8%BA%E4%BB%80%E4%B9%88%E6%98% AF39B /

www.wityx.com

メモリ

実際に、多くの問題をメモリに保存するのRedis。

Javaの、移動や他の言語のようなC言語は、それ自体はメモリの回復のための自動メカニズムを持っていません。Javaのガベージコレクションは、STWにつながる批判されている、ZGCは、最近のデータを読んで、ジャワの上昇が本当にあります。

したがって、システムで独自のオブジェクトに参照カウント（構築Redisの参照カウント）ガベージコレクションのメカニズム実装技術は、このメカニズムを介して、プログラムがオブジェクトを追跡することによってカウント情報を参照することができ、オブジェクトは自動的に適切な時間とメモリのリコールで放出されます。

JVMに精通している人々は、彼が参照カウントに欠陥があることを知っている。しかし、循環参照の問題を解決しません。

A <==> Bが、他のノードABのが、原因1の相互参照AB数への参照を持っていないが回収されることはありません。GCのROOTを持つJavaはそう。

しかし、Redisのは問題がない理由、情報を探して、理由を見つけることができませんでしたかわかりません。大半は、Redisのは、そう、複雑な構造ではないことを言うの？兄があるなしに答えることができますか？

私たちは、数える参照することができます 参照カウントトークンオブジェクトの 0の場合、それが回復することができ、トークンが複数回参照されている照会、コマンドを。

そして、最も重要な点は、Redisの整数、ということである0-9999（1Wの整数の合計）は、キャッシングを行います。同じキャッシュを行うためにJavaに似-128-127。

しかし、文字列の後、キャッシュAAAAAなどの値、のない文字列は、ライブラリ全体を掃引する必要があるライブラリー、時間がかかり、非常に大きな圧力CPUかどうかを決定ではありません。

最適化では、妥協点を考慮し、それは0-9999バーをキャッシュします。実際には、価格淘宝網財、十分なキャッシュ0-100、0-100を見て、結局、商品の99％を占めました。

具体的に見るためにします。http：//redisbook.com/preview/object/share_object.html

言葉の後

オブジェクトの各キーと値のペアのRedisのデータベースキー。

そこRedisの文字列、リスト、ハッシュ、コレクションは、オブジェクトの5種類のコレクションを命じ、オブジェクトの各タイプは、符号化の少なくとも二つ以上を持って、エンコード異なるオブジェクトは、異なる使用シナリオに最適化することができ、効率。

サーバーの特定のコマンドを実行する前に、あなたが最初に型チェックキーの値オブジェクトを入力し、タイプ指定された鍵が指定されたコマンドを実行するかどうかをチェックするには、キーをチェックすることです。

オブジェクトが使用されなくなった時に実装されていない参照カウントメモリの回復メカニズムとRedisのオブジェクトシステムは、オブジェクトによって占有されていたメモリを自動的に解放されます。

Redisのシェア値は、オブジェクトの0から9999の整数です。

最後にアクセスされたオブジェクトが自分の時間を記録します、この時間は、アイドル時間のオブジェクトを計算するのに使用することができます。

参考：