十一、aofログの持続化

AOFログ持続化
rdbはスナップショットで、メモリ全体のスナップショットです(欠点は数分で1回しか撮れませんが、次のショットの前に突然ダウンタイムした場合、前回のスナップショットから次のスナップショットまでのデータが失われます).aofはログです.
aof(append of file)の構成
appendonly no#aofログ機能appendfsync always*#各コマンドを開くかどうかは、すぐにaofに同期します.安全で、redis操作の速度が遅いappendfsync everysec#トレードオフスキームは、appendfsync no#ログを1秒に1回書きディスクに書き込む作業をオペレーティングシステムに渡し、オペレーティングシステムによってバッファサイズを判断し、aofログに統一的に書き(オペレーティングシステムのルールに基づいて)、redis操作の速度が速い.しかし、同期効率が低い**no-appendfsync-no-rewrite yes**rdbスナップショットをエクスポートする過程で、同期aofを停止するかどうか(aofは一般的に毎秒1回、rdbがスナップショットを生成するように設定されている場合、数分に1回しか実行されないため、データ量が大きいため、実行時間は1秒以上になるに違いないが、この過程ではaofが必ず実行されるのがデフォルトである.ただしこの場合はrdbの1つのプロセスに実行させておけばよいので、ディスクに対するIOを軽減する)**auto-aof-rewrite-percentage 100**aofファイルサイズは前回の書き換え時のサイズより成長率100%の場合、書き換えます.appendfilename appendonly.aof#これはaofログファイル名を構成するために使用され、デフォルトはappendonlyです.aof**aofログファイルに保存されているディレクトリは、dirで設定されているため、以前rdbで設定されたディレクトリと同じです.
aofの動作原理
クライアントはサービス側のメインプロセスに対してコマンドを送信し続け、サービス側のaofサブプロセスはあなたが実行した各コマンドをすぐにテキストファイルに書きます.メリット:そのテキストファイルに書かれたログでデータをリカバリできる欠点:redis図はメモリの速さですが、コマンドをテキストファイルに書くたびにディスクのIOに対してメモリの効率が低下します.したがって、ディスクをIOにするには、ディスクIOを一定時間設定し、ディスクIOによる効率の損失を低減することが一般的です.
に質問
同じkeyで100回しか操作されず、redis(内蔵)には特定の値が1つしかありません.aofは100回の操作があり、afoファイルが大きすぎたり、aofからデータを復元したりするのが遅すぎたりするのが欠点です.100回も操作するからです.解決:すべてのkeyはメモリに特定のステータスが1つしかありません.メモリのkey/valueを関連するコマンドに逆化します.例:

set age=0
incr age
……
……incr age
age=100
set age 100

これが書き直しです.書き直しは何ですか.書き換えとは、メモリ内の現在のデータの具体的な値をaofログに書き込んで、aofログが大きすぎる問題を解決することです.aof書き換えは、前回の書き換えから増加した内容を削除します.
aof関連構成の書き換え
Autoaof-aof-rewrite-percentage 100#aofファイルサイズが前回の書き換え時のサイズより100%大きくなった場合、auto-aof-rewrite-min-size 64 mbを書き換える最初はaofファイルが小さいため、2つのコマンドを1つ書いて書き換える可能性があり、前期の書き換え密度が大きすぎるため、最小値を設定します.この値を超えてから書き換えを開始します.
注意:一般的にaofをオンにすると、redisコマンドの実行効率が低下します.
rdbとaofファイルが存在する場合、データのリカバリを優先するのは誰ですか?
答え:aof
rdbとaofは同時に有効にできますか?
はい、いいです.
リカバリ時rdbとaofのどちらがリカバリが速いですか?
答え:rdbは速い.rdbはデータのメモリマッピングであるためです.メモリに直接ロードされますが、aofはコマンドで、1つずつ実行する必要があります.
bgrewriteaof
それらの条件を満たさないと書き換えられます