Redis淘汰メカニズム+ホットスポットデータ問題

なぜ淘汰が必要なのか
Redisはメモリ・データベースであり、Redisの作成者がメモリをよりよく使用するために様々な工夫を凝らしていることを常に感じることができます.例えば、圧縮リスト、ジャンプテーブルなど、同じデータ構造に対して異なるアプリケーション・シーンで異なる下位符号化に基づく実装が提供されていることが最も明らかです.
Redisの最も一般的な2つのアプリケーションシーンはキャッシュと永続的なストレージであり、Redisがキャッシュを行うとき、1つのRedisサーバがあり、サーバの物理メモリサイズは1 Gであり、Redisに存在するデータ量は非常に小さく、これは十分に長い時間がかかるように見えます.ビジネス量の増加に伴い、Redisに置かれているデータはますます多くなりました.データ量の大きさは1 Gを超えているようですが、アプリケーションは正常に動作します.これは、オペレーティングシステムの可視メモリが物理メモリに制限されていないためです.仮想メモリです.物理メモリが足りなくても大丈夫です.オペレーティングシステムはハードディスクからダミーメモリを構築するために空間を画定します.例えば、32ビットのオペレーティングシステムの可視メモリサイズは2^32です.ユーザースペースの可視メモリは2^32より多く、3 G程度です.はい、オペレーティングシステムが私たちのためにこれらをしてくれたことを喜んでいますが、この背後にある代価は高くないことを知っておく必要があります.不合理なメモリの使用は頻繁なswapが発生する可能性があります.頻繁なswapの代価は痛ましいです.だから振り返ってみると、追求するプログラマーとして、私たちは慎重にメモリを使って、ユーザーコードが解決できる問題をできるだけオペレーティングシステムに捨てないでください.
したがって、メモリをよりよく利用するために、Redisがキャッシュされたホットスポットデータを格納するために、Redisは対応するメモリ淘汰メカニズム(キャッシュ淘汰メカニズムとも呼ばれる)を設計した.
プロファイルの一般的な変更
淘汰メカニズムを開く
redisを構成することができます.confのmaxmemoryという値はメモリ淘汰機能をオンにします

maxmemory 

淘汰ポリシーの変更
適用シーンに基づいて、淘汰ポリシーを選択

maxmemory-policy noeviction

一般的なコマンド変更(ダイナミック、再起動不要)
最大メモリの設定

config set maxmemory 100000

淘汰ポリシーの設定

config set maxmemory-policy noeviction

メモリの淘汰プロセスは

まず、クライアントはsetのようなより多くのメモリを申請するコマンドを開始する.

その後、Redisはメモリの使用状況をチェックし、使用したメモリがmaxmemoryより大きい場合、ユーザ構成の異なる淘汰ポリシーに基づいてメモリ(key)を淘汰し始め、一定のメモリを交換する.

最後に、上記に問題がなければ、このコマンドは正常に実行されます.

ヒント:maxmemoryが0の場合、Redisのメモリ使用に制限はありません.
データ削除ポリシーは3つあります

受動削除:GETなどのキーが操作されている場合にのみ、Redisはそのキーが期限切れであるかどうかを受動的にチェックし、期限切れであれば削除し、NILに戻る.

アクティブ削除:期限切れのデータを定期的に削除し、

を構成できます.

現在使用されているメモリがmaxmemoryの制限を超えた場合、データ淘汰ポリシー

がトリガーされる.
パッシブ削除フィーチャー

このような削除ポリシーはCPUに友好的であり、削除操作はやむを得ない場合にのみ行われ、他のexpire keyで無駄なCPU時間を浪費することはない.

しかし、このポリシーはメモリに友好的ではなく、keyが期限切れになったが、操作される前に削除されず、メモリ領域を占めている.大量の期限切れキーが存在しますが、アクセスが少ない場合は、メモリ容量の浪費が発生します.

Redisは6種類のデータ淘汰ポリシーを提供しています

volatile-lruは、有効期限が設定されているデータセット(server.db[i].expires)から、最近最も少ないデータ淘汰を選択します.注意:redisは、すべてのデータセットで最も最近使用されているキー値ペアを取得することを保証するものではありません.ランダムに選択されたいくつかのキー値ペアのうち、メモリが制限に達した場合、期限切れでないデータセットを書き込むことはできません.

volatile-ttl期限切れが設定されているデータセット(server.db[i].expires)から期限切れにするデータを選択します.注意:redisは、すべてのデータセットが最近期限切れになるキー値ペアを取得することを保証するものではありません.ランダムに選択されたいくつかのキー値ペアのうち、メモリが制限に達した場合、期限切れでないデータセットを書き込むことはできません.

volatile-randomは、有効期限が設定されているデータセット(server.db[i].expires)から任意にデータ淘汰を選択します.メモリが制限に達した場合、期限切れでないデータセットは書き込めません.

allkeys-lruは、データセット(server.db[i].dict)から最近最も使用されているデータの淘汰を選択します.メモリが制限に達した場合、すべてのデータセットに対して最近最も少ないデータ淘汰を選択し、新しいデータセットに書き込むことができます.

allkeys-randomはデータセット(server.db[i].dict)から任意にデータ淘汰を選択し、メモリが制限に達した場合、すべてのデータセットに対してランダム淘汰を選択し、新しいデータセットに書き込むことができる.

no-envictionメモリが制限に達した場合、データは淘汰されず、データセットに書き込まれず、メモリを申請するコマンドがエラーになります.

淘汰ポリシーの選択
使用経験に基づいて、回収ポリシーは一般的に次のように構成できます.

allkeys-lru:ユーザがべき乗則分布(power-law distribution)の提示を要求する場合、すなわち、一部のサブセット要素が他の要素よりはるかに多くアクセスされることが望ましい場合、allkeys-lruポリシーを使用することができる.あなたが不確実な時これは良い選択です

allkeys-random:ループサイクルのアクセスが望ましい場合、すべてのキーが連続的にスキャンされるか、要求が平均分布(各要素が同じ確率でアクセスされる)に合致することが望ましい場合、allkeys-randomポリシーを使用することができる.

volatile-ttl:キャッシュ・オブジェクトを作成するときに設定したTTL値を使用して、どのオブジェクトがより良いパージ候補であるべきかをRedisに決定したい場合は、volatile-ttlポリシーを使用します.

また、キーの有効期限を設定するにはメモリを消費する必要があるため、allkeys-lruのようなポリシーを使用すると、メモリ圧力の下でキーの回収に有効期限を設定する必要がないため、より効率的になります.
正確でないLRU
上記のLRU(Least Recenly Used)ポリシーは、実際にRedisが実現するLRUは信頼できるLRUではありません.つまり、名目上、LRUアルゴリズムを使用してキーを淘汰しますが、実際に淘汰されたキーは必ずしも実際に最も長く使われていないわけではありません.ここでは、すべてのキー空間で最適解を検索する必要がある場合、システムのオーバーヘッドが必然的に増加します.Redisは単一スレッドであり、同じインスタンスが各時点で1つのクライアントにしかサービスできないため、時間のかかる操作は慎重に行わなければならない.一定のコスト内で相対的なLRUを実現するために、初期のRedisバージョンは、サンプリングされたLRUに基づいており、すなわち、すべてのキー空間内探索解を放棄してサンプリング空間探索最適解に変更された.Redis 3から0バージョン以降、Redisの作成者は、サンプルベースのLRUをいくつか最適化し、一定のコストで結果を実際のLRUに近づけることを目的としています.
Redisホットスポットデータの問題
質問:メモリ制限のため、Redisには最大1 Wのデータ情報しか格納できません.この1 wのデータが最も人気のあるデータであることをどのように確保しますか?
ソリューション

ホットスポットデータのソート(クリック回数)ホットスポットデータである以上、ソートが必要であり、redisのzsetデータ型を使用するのは自然な考え方である.データの中の1つの唯一のフィールドはzsetの中のvalueとして、クリック回数はscoreとしてclick_と記入しますzset.これで最も人気のあるデータを選ぶことができます.データは、そのままHashMapで格納されます.

ホットスポットデータ時間(最近アクセス)1 wのデータしか保存できず、ホットスポットデータが必要である以上、クリック回数は一方で、時効性も一方で、どのように保証しますか?別のzsetを開始できます.データのフィールドはvalueで、クリックするたびに現在のタイムスタンプをscoreとして更新し、time_とします.zsetこれで時間を記録できます.バックグラウンドで1つのタスクを走り、一定時間間隔で2つのzsetの中で長時間クリックイベントが発生していないキーを削除し、hashデータを削除し、生成した新しいデータのためにデータ空間を空ける.

は、新しいホットスポットデータを処理し、スペースがあれば、自分のhashmapに保存し、keyを2つのzsetに保存する.スペースがない場合はclick_zsetではクリック回数が一番前の1 w位の後ろにあるキーを取り出し、対応するhashデータを削除します.そしてこの1 w個のscoreの値を見て、keyを2つのzsetに入れればいいです.

リファレンス
https://blog.csdn.net/u013679744/article/details/79203933
https://www.cnblogs.com/chenpingzhao/p/5022467.html
http://blog.720ui.com/2016/redis_action_02_maxmemory_policy/
http://ifeve.com/redis-lru/