Redisの持続化メカニズム

Redisのデータはどのように永続化されていますか?
Redisは2つの方式の持続化をサポートし,1つはRDB方式であり,もう1つはAOF(append-only-零le)方式である.前者は、指定されたルール「タイミング」に従ってメモリ内のデータをハードディスク(HDD)に格納し、後者はコマンドを実行するたびにコマンド自体を記録します.2つの永続化方式は、1つを単独で使用してもよいし、2つの方式を組み合わせて使用してもよい.
RDB
一定の条件を満たすと、Redisは単独でサブプロセスを作成して永続化し、永続化プロセスが終了するまでデータを一時ファイルに書き込み、最後に永続化されたファイルをこの一時ファイルに置き換えます.プロセス全体で、プライマリ・プロセスはIO操作を一切行わず、極めて高いパフォーマンスを確保します.大規模なデータのリカバリが必要であり、データリカバリの完全性に非常に敏感でない場合、RDB方式はAOF方式よりも効率的である.RDBの欠点は、後の永続化後のデータが失われる可能性があることである
RDB条件のトリガ

構成規則に従って自動スナップショット

を行う.
構成の詳細

#     ，  900s    1      ，         ，             
save 900 1 
#   300s  10   ，      
save 300 10  
save 60 10000 

#      
dbfilename dump.rdb 
 
#        ，          
stop-writes-on-bgsave-error yes 
 
#      
rdbcompression yes 
 
#         
rdbchecksum yes 
 
#        
dir /usr/local/redis-4.0.6 

ユーザがSAVEまたはBGSAVEコマンドsaveコマンドsaveコマンドsaveコマンドsaveコマンドsaveコマンドを実行すると、Redisは同期してスナップショット操作を行い、スナップショット実行中にクライアントからの要求をすべてブロックする.redisメモリのデータが多い場合、このコマンドによってRedisが長時間応答しないことになります.したがって、本番環境でこのコマンドを使用することを推奨するのではなく、bgsaveコマンドbgsaveコマンドbgsaveコマンドを使用してバックグラウンドで非同期でスナップショット操作を行うことを推奨し、スナップショットと同時にサーバはクライアントからの要求に応答し続けることができる.BGSAVEを実行すると、Redisはすぐにokに戻ってスナップショットの実行を開始することを示し、LASTSAVEコマンドによってスナップショットが正常に実行された時間の

を取得することができる.

FLUSHALLコマンドを実行する前に説明したように、メモリ内のredisのすべてのデータが消去されます.このコマンドを実行すると、redisで構成されているスナップショットルールが空でない限り、saveのルールが存在します.redisはスナップショット操作を1回実行します.ルールがどうであれ実行されます.スナップショットルールが定義されていない場合、スナップショット操作

は実行されません.

がレプリケーションを実行する場合、redisは、マスタスレーブモードでレプリケーション初期化時に自動スナップショット

を行う.
AOF
Redisを使用して一時的でないデータを格納する場合、プロセス終了によるデータ損失を低減するためにAOF永続化を開く必要があるのが一般的である.AOFは、Redisが実行する書き込みコマンドをハードディスクファイルに追加することで、Redisのパフォーマンスを低下させることができますが、ほとんどの場合、この影響は許容できます.また、より速いハードディスクを使用すると、AOFのパフォーマンスを向上させることができます.

AOF永続化構成

#     aof 
appendonly yes 
 
#      
appendfilename "appendonly.aof" 
 
#      
#always：            aof，  ，      
#everysec：      ，      no：
#redis     OS   ，   ，      
appendfsync everysec 
 
# aof         
no-appendfsync-on-rewrite no 
 
#        
#auto-aof-rewrite-percentage         AOF             AOF                   
#auto-aof-rewrite-min-size          aof    ，                        
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 
 
#   aof         ，yes    aof       ， log       。no               
aof-load-truncated yes 
 
#        
aof-rewrite-incremental-fsync yes 

AOFの書き換え原理AOF書き換えの流れは、メインプロセスが1つのサブプロセスをforkしてAOF書き換えを行うことである.この書き換えプロセスは、元のaofファイルに基づいて行われるのではなく、スナップショットに似た方法で、メモリ内のデータを全量遍歴し、aofファイルにシーケンスごとに含まれる.forkサブプロセスのこの過程で、サービス側は依然として対外的にサービスを提供することができますが、この時に書き換えたaofファイルのデータとredisメモリのデータが一致しなくなったらどうしますか?心配しないでください.この過程で、メインプロセスのデータ更新操作はaof_にキャッシュされます.rewrite_bufでは,書き換え中に受信したコマンドを格納するために1つのキャッシュを単独で開き,サブプロセスが書き直した後にキャッシュ中のデータを新しいaofファイルに追加する.すべてのデータが新しいaofファイルに追加されると、新しいaofファイルの名前を変更し、その後、すべての操作が新しいaofファイルに書き込まれます.rewrite中に障害が発生した場合、元のaofファイルの正常な動作には影響しません.rewriteが完了した場合にのみファイルが切り替えられます.従って、このrewriteプロセスは比較的信頼できる

である.