【Redis】Redis持続化

Redis中国語ネットhttp://www.redis.cn/topics/persistence.htmlRedis英語ネットワークhttps://redis.io/topics/persistence
Redisは、データの永続化をサポートするキャッシュ・ミドルウェアであり、強力なパフォーマンスを提供するとともに、メモリへのデータの永続化をサポートします.人為的に再起動しても、サービスがダウンタイムで再起動しても、データのリカバリが保証されます.これにより、Redis自体が提供するデータ構造やApiに依存するアプリケーションシーンなど、Redisのアプリケーションシーンがより豊かになります.
Redis持続化
RedisにはRDBとAOFの2つの永続化方式がある.二つの方法にはそれぞれ特徴がある.Redisがインストールを初期化する際にデフォルトで使用するRDB永続化方式.
この2つの持続性についてご紹介します
RDB
まずRDBについて話しましょう.
RDB永続化方式は、指定された時間間隔でredisメモリ内のデータをスナップショット操作し、指定されたディスクパスに格納する.
Redisはデフォルトで採用するRDB持続化方式で、プロファイルredis.confのデフォルトの永続化構成は次のとおりです.

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

Q 1、rdb永続化ポリシーの構成はどのように行いますか?
saveポリシーを追加し、saveポリシーを変更し、saveポリシーを削除し、永続化ポリシー構成を行います.
Q 2、rdb持続化をどのようにオフにしますか?
注記、またはrdb永続化を閉じることに相当するsave構成をすべて削除します.
プロファイルに加えて、RDBの永続化が自動的にトリガーされます.
また、RDB永続化は、コマンドラインによって手動でトリガすることもできる.
クライアント実行コマンド、saveクライアント実行コマンド、bgsave
saveとbgsaveの比較
saveは実行中にRDBの永続化が完了するまでRedisをブロックする.この過程でRedisは対外的にサービスを提供できない.bgsaveは、実行中にメインプロセスfork操作によってサブプロセスを作成し、サブプロセスによって永続化操作を行う.forkでRedisがしばらくブロックされている以外は、他の操作はサブプロセスで実行され、Redisの正常なサービス提供に影響しません.
以上の2つのトリガ方式に加えて,RDB持続化のトリガ方式には受動トリガ方式がある.1.マスタースレーブアーキテクチャにおいて、ノードからフルコピーを行う場合、マスターノードはbgsaveを実行してRDB永続化を行う.2、クライアントはコマンドdebug reloadを実行し、save操作をトリガし、RDB持続化を行う.3、クライアントはコマンドshutdownを実行し、rediaがaofを開いていない場合、redis.confにはsave(rdb持続化をオンにすることに相当)が構成されており、bgsaveを実行してRDB持続化を行う
RDBワークフローまとめ

RDB永続化は、saveまたはbgsaveを用いて永続化動作を行う.一方,saveは一般にdebug reloadなどのシーンでのみ,Redisサービスをブロックして永続化を保証する必要がある場合,データが書き込まれないなどのシーンで使用される.ほとんどのシーンはRedisの高可用性を保証するためにbgsaveを使用している.以下、bgsaveを例に簡単にRDBワークフローを見てみましょう.
図:bgsaveコマンドがトリガーされ、Redisメインプロセスはfork操作を呼び出してサブプロセスを作成します.サブプロセスは、一時RDBファイルにデータを書き込みます.一時RDBファイルの書き込みが完了すると、一時RDBファイルはディスクの元のRDBファイルを上書きして削除します.
拡張:RDBのその他の構成

## bgsave         RDB    （yes   ，no   ）
stop-writes-on-bgsave-error yes
##              ，  ZLF  。（yes   ，no   ） 
rdbcompression yes
##   rdb  
rdbchecksum yes
## rdb     
dbfilename dump.rdb
## rdb     
dir ./

AOF
AOFをもう一度見てみましょう.
AOFフルネームappend only file.AOFの原理は彼の命名と同様に、Redisの各操作命令を指定したファイルに追加し、ディスクに保存する.
AOFのデフォルトはオンではなく、redisを構成することができる.confファイルを開く

 #    AOF   ：  
  appendonly yes

また、コマンドラインにより動的構成を行うことも可能である.confファイルの構成項目が主です.
AOFワークフロー
Redisクライアントは、AOFバッファに命令操作が書き込まれるデータ命令操作を行う.この時点で、データは、ローカルディスクのAOFファイルにバッファに書き込まれていません.AOFポリシーに従って、トリガポリシーは、AOFバッファのデータをローカルディスクAOFファイルにブラシして永続化します.永続化の際、AOFファイルが指定された条件に達すると、rewrite最適化AOFファイルが行われ、AOFファイルサイズが減少します.
このプロセスには2つの重要な点があります.1、AOFバッファがいつAOFディスクに永続化されるか2、AOFがrewriteを行う条件
この2点についてお話しします
AOFバッファデータをローカルディスクAOFファイルに書き込むポリシー
まず、この戦略がredisにあることを見てみましょう.confでどのように構成するか.

# appendfsync alway
# appendfsync no
appendfsync everysec

Redisは、AOFバッファデータがディスクにどのようにブラシされるかを永続化するための3つのポリシーを定義しています.

alway fsync after every write to the append only log. Slow,Safest Redisは、AOFバッファに一度データ操作すると、すぐにバッファデータをローカルディスクAOFファイルに同期します.利点:データ操作のたびにローカルディスクにすぐに同期し、データの整合性を保証します.欠点:このモードはRedisの性能を著しく低下させ、Redisを使用する初心を失った.推奨:このモードは推奨されず、Redisのパフォーマンスが大幅に低下します.Redisを使用して高同時性、高パフォーマンスを提供するという目的に反しています.

no don’t fsync, just let the OS flush the data when it wants. Faster. Redisインスタンスは、AOFバッファデータからローカルディスクへの同期動作を行わず、その動作をシステムに直接渡す.利点:Redisはfsyncの操作が少ないため、Redisの性能を一定の向上欠点を得ることができる:AOFバッファデータの持続化はオペレーティングシステムに完全に渡され、私たちはこの操作がいつ実行されるかを制御できない.推奨:このモードは、データの永続化に関係なく使用できます.ただし一般的には推奨されません.

everysec fsync only one time every second. Compromise. Redisインスタンスは、AOFバッファデータのAOFへの永続化動作を1秒間に1回実行する.Alwaysはデータの完全性を保証できるが,Redisの性能を著しく低下させる.NoはRedisの性能を向上させることができるが,データの完全性を保証することはできず,制御不能である.everysecは折衷策と言える.1秒間に1回の永続化を行い、Redisの一部のパフォーマンスを保証し、最大1 sのデータ損失を保証します.推奨:通常はこのモードをオンにします.性能を保証すると同時に、データの相対的な完全性を保証する.

AOFはrewriteを行い、AOFファイルサイズを最適化する
前述したAOFは、1つ1つの動作命令を記録することによって永続化される.一方、Redisデータ操作では、set name WTFなどがある.set name Where_the_food;同じキーに対して2回の操作を行ったが、AOFファイルには同じ2つの操作記録が記録されているが、rewriteはこのような文を最適化し、最後の有効な操作指令を保留すればよいので、AOFファイルのダイエットの目的を達成する.
AOFトリガrewriteには2つの方法があります.

プロファイルによるrewrite条件の設定

##    AOF           AOF         ， ：   100 ，      AOF        AOF          ，   rewrite。
auto-aof-rewrite-percentage 100
##   AOF        64mb      rewrite
auto-aof-rewrite-min-size 64mb

クライアントコマンドラインを介してBGREWRITEAOFコマンドを実行し、AOF rewrite操作をトリガする.

拡張:AOFその他の構成

## AOF       
appendfilename "appendonly.aof"

## AOF        ，    aof      （yes   ，no   ：   ：  ）
no-appendfsync-on-rewrite no

##      ，     log ，          
aof-load-truncated yes

## 4.0     ，aof rdb        
aof-use-rdb-preamble no

AOFとRDB

AOFおよびRDBデータ整合性の比較AOFがeverysecに構成されている場合、AOFデータ損失は1 sのみ失われる.データは比較的完全です.RDBデータの損失はsaveの構成に従って周期的に失われる.比較的データが不完全です.

AOFおよびRDBデータリカバリAOFデータリカバリと比較すると、AOFファイル内の命令を実行してデータリカバリを行うために1つのバーが必要であり、比較的遅い.RDBファイルにはRedisのデータスナップショットが格納されているため、データのリカバリ速度が速い.

AOFとRDBは同時に1をオンにし、AOFとRDBが同時にオンになった場合、データ復旧の再開はデフォルトでAOFを使用してデータ復旧を行う(AOFデータはRDBより完全である).2、AOFとRDBが同時にオンの場合、Redisがディスクに対して大量のI/O操作を行うことを防止するため、bgsaveとbagwriteaofは同時に実行できない.1つの時点で実行できるのは1つだけです.

AOFとRDBの選択方法
Redis持続化の選択も選択です.大人の世界では、2文字を選んだことがなく、すべてが必要です.これは私の浮気ではありません.Redisの公式サイトも提出しました.
The general indication is that you should use both persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you.
公式にはpostgreSQLのようなデータセキュリティを達成するには、両方の永続化をオンにすることが望ましいと述べています.

      ！