Redis の基本構成と永続性

title: redisの基礎知識
date: 2023-03-21 22:10:15
tags: [redis]

シングルスレッドと Redis の高いパフォーマンス

Redis はシングルスレッドですか?

Redis のシングルスレッドは主に、ネットワーク IO とキーと値のペアの読み取りと書き込みが 1 つのスレッドで完了することを意味します。これは、Redis がキーと値のストレージサービスを外部に提供するための主要なプロセスでもあります。ただし、永続化、非同期削除、クラスターデータの同期などの Redis の他の機能は、実際には追加のスレッドによって実行されます。

Redis シングルスレッドがこれほど高速なのはなぜですか?

すべてのデータはメモリ内にあるため、すべての操作はメモリレベルの操作であり、マルチスレッドコンテキストスイッチングの損失が回避されます。
Redis はシングルスレッドであるため、使用中に操作をブロックしないように注意する必要があります。たとえば、キーの数が非常に多いときに使用すると、keys *キーに対する後続の Redis 操作がすべてブロックされます。

Redis シングルスレッドはマルチクライアントの同時接続をどのように処理しますか

Redis IO 多重化。Redis は epoll を使用して IO 多重化を実現し、接続情報とイベントをキューに入れ、ファイルイベントディスパッチャーに順番に入れます。イベントディスパッチャーはイベントをイベントプロセッサーに配布します。
図に示すように:

Redis によってサポートされる接続の最大数

設定ファイル内redis.conf:

maxlients 6000

これは redis-cli でも表示できます。

127.0.0.1:6379> CONFIG GET maxclients
"maxclients"
"6000"

サービス実行情報の表示

info コマンドは、redis サービスの実行情報を表示できます。情報は次の 9 つのブロックに分割されています。

サーバーサーバーの動作パラメータ
クライアントクライアント関連情報
メモリサーバーの実行メモリ統計
永続化永続的な情報
統計一般的な統計
レプリケーションマスター/スレーブレプリケーション関連情報
CPU CPU使用率
クラスタクラスタ情報
KeySpace のキーと値のペアの統計

以下に簡単な情報を示します。

connected_clients:2                  # 正在连接的客户端数量

instantaneous_ops_per_sec:789        # 每秒执行多少次指令

used_memory:929864                   # Redis 分配的内存总量 (byte)，包含 redis 进程内部的开销和数据占用的内存
used_memory_human:908.07K            # Redis 分配的内存总量 (Kb，human 会展示出单位）
used_memory_rss_human:2.28M          # 向操作系统申请的内存大小 (Mb)（这个值一般是大于 used_memory 的，因为 Redis 的内存分配策略会产生内存碎片）
used_memory_peak:929864              # redis 的内存消耗峰值 (byte)
used_memory_peak_human:908.07K       # redis 的内存消耗峰值 (KB)

maxmemory:0                         # 配置中设置的最大可使用内存值 (byte), 默认 0, 不限制，一般配置为机器物理内存的百分之七八十，需要留一部分给操作系统
maxmemory_human:0B                  # 配置中设置的最大可使用内存值
maxmemory_policy:noeviction         # 当达到 maxmemory 时的淘汰策略

Redis パイプライン

クライアントは、サーバーの応答を待たずに、複数のリクエストを一度に送信できます。すべてのコマンドを送信した後、サービスの応答結果を一度に読み取ることで、複数のコマンドを実行するネットワーク伝送のオーバーヘッドを大幅に削減できます。パイプラインで複数のコマンドを実行する場合のネットワーク伝送のオーバーヘッドは、1 つのコマンドを実行するネットワークに相当します。コマンドのオーバーヘッド。このように、redis はすべてのコマンドを処理する前に、すべてのコマンドの実行結果をキャッシュします。コマンドがパックされると、キャッシュが消費するメモリも多くなります。したがって、詰め込むコマンドが多ければ多いほど良いというわけではありません。パイプラインで送信されたすべてのコマンドはすぐに実行されます。実行が失敗した場合は、後の応答に記録されます。前のコマンドの失敗は実行には影響しません。後続のコマンドの。

Redis lua スクリプト

Redis はバージョン 2.6 でスクリプト機能を導入し、開発者が lua 言語でスクリプトを作成し、それを Redis に渡して実行できるようにしました。スクリプトを使用する利点は次のとおりです。

ネットワークオーバーヘッドの削減: 本来、複数のネットワークリクエストの操作は 1 つのリクエストで完了できます。複数のリクエストのロジックは lua スクリプトにカプセル化され、redis 上で 1 回実行されるため、ネットワークのラウンドトリップオーバーヘッドが削減されます。これはパイプラインに似ています。
アトミック操作: redis は、lua スクリプト全体をアトミックに実行します。パイプラインはアトミックではありませんが、一括操作の一部のコマンドはアトミックです。mget
redis のトランザクション関数を置き換える: 今のところ、redis のトランザクション関数は依然として非常に無味乾燥で、ほとんど使用されていません。redis の lua スクリプトは従来のトランザクション機能をほぼ実現しており、トランザクション機能の実現には redis 独自の代わりに lua を使用することが redis から公式に推奨されています。

使用方法は次のとおりです。

EVAL script numkeys key [key ...] arg [arg ...]

scriptパラメータは lua スクリプトであり、numkeysキー名パラメータの数を指定するために使用されます。キー名パラメータ key は 3 番目のパラメータから数えられ、スクリプトで使用されるキーを示します。これらのキー名パラメータは Lua スクリプトのグローバルに渡されます。変数KEYS配列アクセスでは、アクセスするベースアドレスとして 1 を使用します。たとえばKEYS[1] KEYS[2]、numkeysキー、最後の追加パラメーター arg [arg ...] は、Lua スクリプトのグローバル変数 ARGV 配列を通じてアクセスできます。ARGV[1] ARGV[2]

例えば：

127.0.0.1:6379> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"

Redis での Lua スクリプトの使用に関する詳細情報は、ブログの別の面に書かれます。

Redis の永続性

RDBスナップショット

デフォルトでは、redis はメモリデータベースのスナップショットを dump.rbd という名前のバイナリファイルに保存します。

「N 秒以内に少なくとも M 回の変更」という条件が発生したときに、データを 1 回だけ自動的に保存するように設定ファイルを設定できます。設定項目は、たとえば次のとおりですsave。

save 60 1000

この構成により、「60 秒以内に少なくとも 1000 回のキー変更」の条件が満たされた場合に、Redis がデータセットを 1 回自動的に保存できます。

コマンドを手動で実行して RDB スナップショットを生成したり、reids クライアントコマンドを実行しsaveたり、bgsavedump.rbd ファイルを生成したりすることもできます。コマンドが実行されるたびに、メモリ内のデータが新しい rdb ファイルに保存され、元の RDB スナップショットファイルは上書きされます

RDBスナップショット機能をオフにしたい場合は、この設定を直接コメントしてください

bgsave のコピーオンライトメカニズム (COW)

Reid は、オペレーティングシステムが提供するコピーオンライトテクノロジを利用して、スナップショットを生成しながら書き込みコマンドを実行できます。実装メカニズムは次のとおりです: bgsave はメインスレッドのフォークによって生成されたサブプロセスによって操作され、メインスレッドのすべてのメモリデータを共有できます bgsave サブプロセスが生成された後、メインスレッドのメモリデータの読み取りを開始しますスレッドを作成し、RDB ファイルに書き込みます。このとき、メインスレッドがデータを読み取っていれば、メインスレッドとサブプロセスは相互に影響を与えませんが、メインスレッドがデータを変更したい場合は、そのデータをコピーしてコピーを生成します。 bgsave サブプロセスは、このコピーデータを RDB ファイルに書き込みます。このプロセス中、メインプロセスは元のデータを直接変更できます。

save 60 1000basave メソッドを使用するように設定ファイルで指定します

セーブ vs bgsave

	保存	bgs保存
I/Oタイプ	同期する	非同期
Redis の他のコマンドをブロックするかどうか	はい	いいえ
複雑さ	の上）	の上）
アドバンテージ	追加のメモリを消費しません	クライアントコマンドをブロックしません
欠点がある	クライアントコマンドのブロック	子プロセスをフォークする必要があるため、メモリを消費します

AOF(追加専用ファイル)

スナップショット機能は耐久性があまり高くありません。何らかの理由で Redis が失敗すると、サーバーはスナップショットにまだ保存されていない最近書き込まれたデータを失います。**バージョン 1.1 以降、Redis は完全に耐久性のある永続化メソッドであるAOF 永続化メソッドを追加しました。これは、変更された各命令をファイル appendonly.aof に記録します (最初に OS キャッシュに書き込み、時々 fsync をディスクに書き込みます)。

たとえば、コマンドを実行するとset dc 666、aofファイルに次のようなデータが記録されます。

1 *3
2 $3
3 set
4 $5 
5 dc
6 $3 
7 666

これは、各プロトコル形式のデータです。アスタリスクの後の数字は、コマンドに含まれるパラメーターの数を示し、$ 記号の後の数字は、パラメーターに含まれる文字数を示します。注: 有効期限を指定して set コマンドを実行する場合、 aof ファイルには「はい、これは実行された元のコマンドではなく、キーの有効期限が切れたときのタイムスタンプが記録されます」

構成ファイルを変更して、AOF 機能を有効にすることができます。

appendonly yes

Redis が再起動すると、AOF ファイル内のコマンドを再実行することで、プログラムはデータセットを再構築する目的を達成できます。これは、Redis がコマンドをディスクに直接書き込むのではなく、最初に OS キャッシュに書き込み、永続化するためです。ディスクに保存されるため、Redis がデータをディスクに fsync する時間を構成できます。オプションは 3 つあります。

appenfsync always # 新しいコマンドが AOF ファイルに追加されるたびに、fsync を 1 回実行します。これは非常に遅く、非常に安全です
appenfsync Everysec # fsnc は 1 秒に 1 回、十分な速度で、1 秒でデータを失うコマンドです。
appenfsync no # fsync はオペレーティングシステムの処理に依存しないため、十分高速ですが安全性が十分ではありません

速度とセキュリティを考慮して、1 秒に 1 回が推奨されます。これはデフォルト設定でもあります。

AOFリライト

キーに N 回の累積を追加すると、incr viewCntこのコマンドは AOF ファイルに N 回記録されます。実際には、記録する必要incr ViewCnt Nが。そのため、将来データをより速く復元できるように、reid は AOF 内のコマンドを定期的に書き換えます。
書き換えの頻度を制御する構成は 2 つあります。

auto‐aof‐rewrite‐min‐size 64mb # aof 文件至少要达到 64M 才会自动重写，文件太小恢复速度本来就 很快，重写的意义不大 
auto‐aof‐rewrite‐percentage 100 # aof 文件自上一次重写后文件大小增长了 100%则再次触发重写

AOF 書き換えアクションを redis-cli で手動でトリガーして実行することもできる場合bgrewriteaof、AOF 書き換えは bgsave と同様にサブプロセスをフォークアウトして実行し、redis コマンドの通常の実行には大きな影響を与えません。

RDBとAOFの比較

	RDB	AOF
ブート優先度	低い	高い
ファイルサイズ	小さい	大きい
回復速度	素早い	遅い
データセキュリティ	データを失いやすい	政策決定によると

RBD ファイルと AOF ファイルの両方がある場合は、データが比較的安全であるため、AOF ファイルの方がデータの復元に優先されます。

Redis 4.0 ハイブリッド永続性

Redis が再起動されると、大量のデータが失われ、通常は AOF ログを通じて再生されるため、rdb ファイルがデータの復元に使用されることはほとんどありません。ただし、AOF ログの再生パフォーマンスは、特に Redis の場合、RDB のパフォーマンスよりも大幅に遅くなります。データが非常に大きい場合、起動に時間がかかるこの問題を解決するために、redis には新しい永続化オプションであるハイブリッド永続化が導入されました。ハイブリッド永続性は、次の構成を通じて有効にできます。注: 最初に aof 永続性を有効にする必要があります。

aof-use-rdb-premable yes

ハイブリッド永続性が有効になっている場合、AOF が書き換える際に、単にメモリデータを RESP コマンドに変換して AOF ファイルに書き込むのではなく、この時点より前のメモリを RDB スナップショットとして書き換え、RDB スナップショットの内容を変換し、メモリデータを変更するための増分 AOF コマンドが一緒に存在し、それらはすべて新しい AOF ファイルに書き込まれます。新しいファイルは最初は appendonly.aof という名前ではなく、新しい AOF ファイルが書き換えられて元のファイルが上書きされるまで名前は変更されませんAOF ファイル、古い AOF ファイルと新しい AOF ファイルの置き換えを完了します。そのため、Redis を再起動するときに、最初に RDB コンテンツをロードし、次に増分 AOF ログを再生して、以前の AOF 完全ファイルの再生を完全に置き換えることができるため、再起動の効率が大幅に向上します。

ハイブリッド永続 AOF ファイル構造は次のとおりです。

Redis データのバックアップ戦略

crontab タイミングスケジュールスクリプトを作成し、rdb または aof のバックアップを 1 時間ごとにディレクトリにコピーし、過去 48 時間のバックアップのみを保持します。
その日のデータバックアップのコピーを毎日ディレクトリに保存し、先月のバックアップも保存できます
バックアップがコピーされるたびに、古いバックアップは削除されます
マシンの損傷を防ぐために、現在のマシンのバックアップを別のマシンに毎晩コピーします。