Redis が永続化ソリューションを実装する方法 (RDB および AOF で使用)

1. 永続性の役割

1. 永続性とは

Redis によって保存されるすべてのデータ

#2. 永続性の実装方法

スナップショット: 特定の時点でのデータの完了バックアップ - mysql のダンプ - redis の RDB ログの書き込み: あらゆる操作がログに記録されます。データを復元するには、ログを再度確認するだけです - mysql の Binlog - Hhase の HLog - Redis の AOF

2. RDB

1. RDBとは

2. トリガーの仕組み～主な3つの方法

#1 つ目: 保存 (同期)

##1 クライアントが保存コマンドを入力します----》redis サーバー----》同期作成 RDB バイナリ ファイル

2 (データ量が非常に大きい場合) Redis ブロックが発生します。

3 ファイル戦略: 古い RDB が存在する場合は、古い RDB を置き換えます

4 複雑さ o(n )

2 番目のタイプ: bgsave (非同期、バックグラウド保存開始)

1 クライアントが保存コマンドを入力します----「redis サーバー----」非同期 RDB バイナリ ファイルを作成します ( fork 関数は子プロセスを生成し (fork は reids をブロックします)、createRDB を実行します。実行は成功し、reids メッセージが返されます)

2 この時点で redis にアクセスすると、クライアントは正常に応答します

3 ファイル戦略: 保存と同様、古い RDB が存在する場合は、古い RDB を置き換えます

4 複雑さ o(n)

3 番目の方法: (一般的な方法) (** ****) 自動 (設定ファイル経由)

設定秒変更

save 900 1save 300 10save 60 100001w 個のデータが 60 秒以内に変更された場合、自動的に rdb を生成します

If 10 個のデータ300 秒以内にデータが変更された場合、rdb を自動生成
900 秒以内に 1 つのデータが変更された場合、rdb を自動生成

# 上記 3 つの条件のいずれかを満たした場合、rdb が自動生成されます。 bgsave は内部的に使用されます

#構成:

save 900 1 #1 つを構成

save 300 10 #1 つを構成

save 60 10000 #1 つを構成します

dbfilename dump.rdb #rdb ファイルの名前、デフォルトは dump.rdb

dir ./ #rdb ファイルは現在のディレクトリに存在します

stop-writes-on-bgsave-error yes #bgsave でエラーが発生した場合、書き込みを停止するかどうか、デフォルトは yesです

rdbcompression yes #圧縮形式を使用します

rdbchecksum yes #かどうかrdb ファイルのチェックサム

#ベスト構成

save 900 1

save 300 10

save 60 10000 dbfilename dump- ${port}.rdb

#ポート付き ファイル名として、1 台のマシン上に多くの reid が存在する可能性があるため、乱雑になりません

dir /bigdiskpath #大きなハードディスクの場所ディレクトリへのパスを保存します。

stop-writes-on-bgsave-error yes

#Error stop

rdbcompression yes #Compression

rdbchecksum はい #Verification

RDB トリガー メカニズムは通常、最初の 3 つの方法を使用しますが、この方法にも欠点があります。変更された項目の数が設定範囲内にない場合、トリガーされず、多くのデータが永続化されません。したがって、通常は次の方法を使用します: AOF。

重要でないデータを保存したい場合は RDB (キャッシュ データなど) を使用し、非常に重要なデータを保存したい場合は AOF を使用しますが、両方の方法を使用することもできます。同じ時間です。

3. AOF

1. RDB の問題 は時間とパフォーマンスを消費します。制御不能になり、データが失われる可能性があります。

2. AOF の概要

クライアントがコマンドを記述するたびに、ログが記録され、ログ ファイルに保存されます。ダウンタイムが発生した場合でも、データを完全に復元できます。

3. AOF の 3 つの戦略

ログはハードディスクに直接書き込まれず、最初にバッファに配置されます。バッファは次に従ってハードディスクに書き込まれます。いくつかの戦略

#最初のタイプ: always: redis--》コマンド更新バッファーの書き込み---》各コマンドをハードディスクに Fsync ---》AOF ファイル

#2 番目のタイプ:everysec (デフォルト値):redis——>>書き込みコマンドによって更新されるバッファ--->>fsync バッファをハードディスクに毎秒 -->>AOF ファイル

##3 番目のタイプ: no:redis——>>バッファコマンドの書き込みにより更新 バッファ--->>オペレーティング システムが決定し、バッファはハードディスクに fsync されます-->>AOF ファイル

##no利点欠点 4.AOF rewriting

#コマンド	常に	毎秒
データ損失なし	1 秒ごとに fsync を実行すると、1 秒間のデータが失われます	心配しないでください
IO オーバーヘッドが大きく、平均的な SATA ディスクには数百しかありませんTPS	lost 1 Second data	Uncontrollable

コマンドが徐々に書かれていくと、同時実行の量が増加すると、AOF ファイルはますます大きくなります。この問題は、AOF の書き換えによって解決します

ネイティブ AOF##set hello world
set hello java
実装方法

##AOF Rewrite
setこんにちは、へへ incrカウンター ncrカウンター rプッシュマイリストa rpush mylist b rpush mylist c 期限切れのデータ ##set hello hehe カウンター 2 を設定	rpush mylist a b c # #本質は、期限切れの、役に立たない、繰り返される、最適化可能なコマンドを最適化することです。これにより、ディスク使用量が削減され、回復速度が向上します。

bgrewriteaof: クライアントは、bgrewriteaof コマンドを送信します。をサーバーに送信すると、サーバーはフォーク プロセスを開始して AOF 書き換えを完了します

AOF 書き換え構成:

書き換えプロセス

AOF 構成ファイル (******)

appendonly yes #このオプションを yes に設定して開きます appendfilename "appendonly-${port}.aof " #ファイルの名前Saved appendfsync eachsec #2 番目の戦略を採用します dir /bigdiskpath #ストレージ パス no-appendfsync-on-rewrite yes #aof を書き換えるときに、aof の追加操作を実行するかどうか。aof の書き換えはパフォーマンス、ディスク消費量、通常の AOF 書き込みを消費するためです。ディスクに特定の競合があるため、この期間中のデータは失われる可能性があります

4. RDB と AOF

の選択 1. rdb と aof# の比較

##コマンド

rdb起動優先順位高 (ハングして再起動すると、aof データがロードされます) 大遅い戦略に従って決定 軽い

aof		低
	サイズ	小型
	回復速度	速い
	データセキュリティ	データ損失
	軽いと重い	重い
	2.rdb の最適な戦略 Rdb はオフ、マスター/スレーブ操作 一元管理: 日別、時間ごとにデータをバックアップ マスター/スレーブ構成、スレーブ ノードはオン 3.aof の最適な戦略 オープン: キャッシュとストレージ、ほとんどの場合オープン、 aof 書き換え集中管理 everysec: 戦略は毎秒更新 4. 最適な戦略 小規模シャーディング: 各 Redis の最大メモリは 4g キャッシュまたはストレージ: 特性に応じて異なる戦略を使用する ハードディスクを常に監視する、メモリ、ネットワークの負荷など。 メモリが十分であること 上記は、Redis (4)-永続化ソリューション (RDB および AOF で使用) の全内容です。 関連資料:PHP 中国語 Web サイト

以上がRedis が永続化ソリューションを実装する方法 (RDB および AOF で使用)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。