redisのメカニズム(2)

4412 ワード
redis
redis持続化メカニズム
redisのデータはすべてメモリに格納され、永続化メカニズムが構成されていないと、再起動後に完全に失われます.永続化メカニズムを開き、データをディスクに保存し、redisを再起動するとディスクからリカバリできます.
2つの永続化方式RDBとAOF
RDB
指定した時間内にデータの記憶スナップショットを保存すると、データの一部が失われます.
リカバリ方法:
     1.Client側は直接コマンドBGSAVEまたはSAVEでメモリスナップショットを作成する
BGSAVEはforkを呼び出してサブプロセスを作成し、サブプロセスはスナップショットディスクに書き込まれ、親プロセスはコマンドを処理します.
SAVE実行命令中、他の命令に応答しない
プロファイルredis.conf,デフォルト条件を満たすトリガ
# 900          
save 900 1
# 300       10    
save 300 10
# 60       10000 
save 60 1000

長所と短所
  
メリット
欠点
パフォーマンスへの影響を最小限に抑える
同期ロストデータ
AOFより回復が早い
データセットが非常に大きく、CPUが十分でない場合(例えば、シングルコアCPU)、Redisはforkサブプロセスで比較的長い時間を消費し、Redisが対外的にサービスを提供する能力に影響を与える可能性があります.
 
AOF
サーバデータの読み書き操作コマンドを記録するたびに、サーバが再起動すると、これらのコマンドを実行して元のデータを復元します.
方法:
BGREWRITEAOFコマンドは、ログの書き換えまたは自動書き換えをトリガーし、同じKey履歴に対する不要なコマンドを廃止し、現在のデータセットを再構築するために必要な最短コマンドシーケンスを再構築します.予期せぬ割り込みで、最後のコマンドが一部しか書かれていない場合は、リカバリ時にスキップされ、後続の完全なコマンドが実行されます.
プロファイルredis.cof 
  AOF   
appendonly yes
 
AOF    
#              AOF  ，       
appendfsync always
#       ，    AOF     ，       1    
appendfsync everysec
#   fsync,       ，  ，       
appendfsync no

長所と短所
 
メリット
欠点
安全
ファイル容量が大きい
災害をしのぐ
IO消費が高い
読みやすい
RDBより遅い
redis紛失の可能性のある原因
永続化損失の可能性:RDB方式のスナップショットによって生成されたポリシーは、生まれつきデータセキュリティAOF永続化ポリシーを保証していない.デフォルトでは毎秒1回ディスクを同期し、1秒のデータ損失がある可能性がある.変更するたびに同期し、データセキュリティを保証することができるが、Redis高性能の特性はすべて複製から損失する可能性がない:非同期複製、一定のタイムウィンドウデータ損失ネットワーク、サーバの問題があり、一定のデータの損失がある
淘汰策
まず、メモリの割り当てについて理解します.
メモリ割当て
 Strings  ：  String   value      512M。
Lists  ：list        2^32-1 ，   4294967295 。
Sets  ：       2^32-1 ，   4294967295 。
Hashes  ：        2^32-1 ，   4294967295 


#       
maxmemory       
maxmemory-policy

メモリ圧縮
#      512 
hash-max-zipmap-entries 512
#  value   64  
hash-max-zipmap-value 64
#        512 
list-max-ziplist-entries 512
#  value   64  
list-max-ziplist-value 64


#        512 
set-max-intset-entries 512
#        128 
zset-max-ziplist-entries 128
#  value   64  
zset-max-ziplist-value 64

#      ，redis

期限切れデータの処理ポリシー
    
（ redis       key    ）    10 。
    ：
1.               20     
2.             
3.     25％      ，    1    

    ：
1.     key   ，         ，

データ・リカバリ・フェーズの期限切れデータの処理ポリシー
 RDB  
   key          。
      key，   redis           。
AOF  
  redis    AOF       ，        key redis   
    DEL      AOF   ，
               AOF             。

LRUアルゴリズム
Least recently used     
                    
    ：          ，             。
  ：Redis LRU         ，   LRU             。
  ：     keys    (50%)，           key。
    ： maxmemory-samples 5

LFUアルゴリズム
  
Least Frequently Used 
                   
    ：           ，             。
Redis         ，   key     ，              
    ，                 。
Morris counter    ：
   https://en.wikipedia.org/wiki/Approximate_counting_algorithm
  LFU   ，            。（ redis-cli --hotkeys ）

メモリ回収ポリシー
プロファイル:maxmemory-policy noeviction
動的設定:maxmemory-policy noeviction
回収ポリシー
コメント
noeviction
クライアントが実行しようとすると、より多くのメモリが使用されるコマンドが直接エラーになります.
allkeys-lru
すべてのkeyでLRUアルゴリズムを実行
volatile-lru
すべての期限切れのkeyでLRUアルゴリズムを実行
volatile-lfu
期限切れセットを使用して鍵に近似LFUを使用して駆逐
allkeys-lfu
近似LFUを使用して任意のキーを絞り出す
allkeys-random
すべてのキーでランダムに回収
volatile-random
期限切れのkeyでランダムに回収
volatile-ttl
期限切れのkeyを回収し、生存時間(TTL)の短いキーを優先的に回収する
 
キャッシュブレーク、キャッシュスルー、キャッシュ雪崩
キャッシュブレークダウン
あるホットスポットkey、ピーク期に突然キャッシュkeyが失効し、直撃データベースをもたらす
ソリューション:
 1.ホットスポットkeyが期限切れにならないように設定します.反発ロックを追加(ロックを取得してこそデータベースをクエリーする資格がある)
キャッシュの透過
保存されていないkeyをクエリーすると、redisが使用できなくなり、データベースの圧力が発生します.
ソリューション:
1.検査パラメータを増やす
2.nigixからコンフィギュレーションアイテムを追加し、単一keyに対して毎秒アクセス回数がバルブ値を超えた場合、IPリストをブラックアウトする
3.ブロンフィルター、事前判断値が存在しない、誤差率がある
4.key値が存在しないことを設定し、期限切れの時間を設定します.
キャッシュ雪崩
洪水ピーク期の大面積キャッシュkeyが失効したり、データベースが停止したりして、大量のデータがクエリールームデータベースに要求されます.
ソリューション:
1.redisに一括してデータを格納する場合、keyの失効時間にランダム値を設定し、同じ時間に大面積で失効しないことを保証する
2.クラスタ配置、異なるredisライブラリに均一に分布することも避けられる
3.ホットスポットデータがいつまでも期限切れにならないように設定し、更新操作があればキャッシュを更新すればよい
4.キャッシュスルーとキャッシュブレークは雪崩の前提
5.キャッシュのダウングレード
[TIL 2021.06.08]会議&API作成時に学ぶ様々な概念
ASPについてNET検証コード