Redis で高可用性と永続性を構成する方法-Redis-php.cn

Redis で高可用性と永続性を構成する方法

1. Redis 高可用性

1. Redis 高可用性の概要

Web サーバーでは、高可用性とはサーバーが稼働している時間を指します。正常にアクセスできる状態であり、正常なサービス（99.9％、99.99％、99.999％など）を提供できる時間を測定基準とします。 [関連する推奨事項: Redis ビデオチュートリアル]

ただし、Redis の文脈では、高可用性の意味はさらに広いようです。通常のサービス (マスターとスレーブの分離など) の提供を確保することに加えて、高速災害復旧技術）、データ容量の拡張、データのセキュリティが失われないことなども考慮する必要があります。

2. Redis の高可用性戦略

Redis では、高可用性を実現するためのテクノロジーには、主に永続化、マスター/スレーブ分離、センチネル、クラスターが含まれます。

#高可用性戦略説明永続性マスタースレーブレプリケーションSentinelクラスター

2. Redis の永続化

1. Redis の永続化機能

Redis はインメモリデータベースであり、データはメモリ上に保存されます。サーバーの停電やその他の理由による異常終了後のデータの永久的な損失に備えて、Redis 内のデータを何らかの形式 (データまたはコマンド) でメモリからハードディスクに定期的に保存する必要があります。次回 Redis を再起動すると、永続ファイルが保存されます。データの回復を実現するために使用されます。さらに、災害時バックアップに備えるために、永続ファイルをリモートの場所にコピーできます。

2. Redis 永続化の 2 つの方法

RDB 永続化
原理は、メモリ内の Redis のデータベースレコードを定期的にディスクに保存することです。
AOF 永続性 (ファイルの追加のみ)
原則は、MySQL のバイナリログと同様に、Redis 操作ログを追加方式でファイルに書き込むことです。
AOF 永続性はリアルタイムパフォーマンスが優れているため、つまり、プロセスが予期せず終了した場合に失われるデータが少ないため、現在 AOF が主流の永続化方法ですが、RDB 永続性も依然としてその地位を占めています。

3. RDB 永続性

RDB 永続性とは、現在のプロセスのデータのスナップショットをメモリ上に生成し、指定された時間内にハードディスクに保存することを指します。間隔 (したがって、スナップショット永続性とも呼ばれます)、バイナリ圧縮を使用して保存され、保存されたファイルのサフィックスは rdb です。Redis が再起動されると、スナップショットファイルを読み取ってデータを復元できます。

3.1 トリガー条件

RDB 永続化のトリガーは、手動トリガーと自動トリガーの 2 種類に分かれます。

3.1.1 手動トリガー

save コマンドと bgsave コマンドの両方で RDB ファイルを生成できます。
save コマンドは、RDB ファイルが作成されるまで Redis サーバープロセスをブロックします。Redis サーバーがブロックされている間、サーバーはコマンドリクエストを処理できません。
bgsave コマンドは子プロセスを fork() します。子プロセスは RDB ファイルの作成を担当し、親プロセス (つまり、Redis メインプロセス) は処理を続行します。リクエスト。
bgsave コマンドの実行中、fork 子プロセスのみがサーバーをブロックしますが、save コマンドの場合、プロセス全体がサーバーをブロックします。そのため、save は基本的に放棄されています。オンライン環境では削除する必要があります。

3.1.2 自動トリガー

#RDB 永続化が自動的にトリガーされると、Redis は永続化のために保存する代わりに bgsave を選択します。

#3.2 設定方法

設定ファイルの変更による設定: save m n
Automatically最も一般的なトリガーは、構成ファイルで save m n を渡すことです。これは、m 秒以内に n 個の変更が発生したときに bgsave がトリガーされるように指定します。

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三个save条件满足任意一个时，都会引起bgsave的调用save 900 1	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsavesave 300 10	##当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsavesave 60 10000	##当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目录dir /var/lib/redis/6379##242行，是否开启RDB文件压缩rdbcompression yes

ログイン後にコピー

3.3 その他の自動トリガーメカニズム

save m n に加えて、bgsave:

Redis で高可用性と永続性を構成する方法

#親プロセスがフォークすると、bgsave コマンドは「バックグラウンド保存が開始されました」というメッセージを返し、親プロセスをブロックしなくなり、他のコマンドに応答できるようになります
子プロセスは RDB ファイルを作成し、親プロセスのメモリスナップショットに基づいて一時スナップショットファイルを生成します。完了後、元のファイルはアトミックに置き換えられます。子プロセスは親プロセスに完了を示すシグナルを送信し、親プロセスは統計情報を更新します。
3.5 起動時のロード
RDBファイルのロードが自動的に実行されます。サーバーの起動時に実行され、特別なコマンドはありません。ただし、AOF の優先順位が高いため、AOF がオンの場合、Redis は AOF ファイルのロードを優先してデータを復元します。AOF がオフの場合にのみ、Redis サーバーの起動時に RDB ファイルが検出され、自動的にロードされます。 RDB ファイルのロード中は、ロードが完了するまでサーバーがブロックされます。
Redis は RDB ファイルを読み込むときに RDB ファイルを検証しますが、ファイルが破損している場合はログにエラーが出力され、Redis は起動できません。

RDB 永続性はプロセスデータをファイルに書き込みますが、AOF 永続性は Redis によって実行された各書き込みおよび削除コマンドを別のログファイルに記録するため、クエリ操作は記録されません。 Redis が再起動したら、AOF ファイル内のコマンドを再度実行してデータを復元します。

AOF は RDB と比較してリアルタイム性が高いため、永続化ソリューションの主流となっています。

4.1 开启 AOF

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

ログイン後にコピー

4.2 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。

AOF的执行流程包括：

命令追加（append）：将Redis的写命令追加到缓冲区aof_buf；
根据不同的同步策略，把aof_buf中的内容写入硬盘，并实现文件同步
文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。

4.2.1 命令追加（append）

Redis先将命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO称为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单、避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

4.2.2 文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

4.2.3 三种同步方式

AOF缓存区的同步文件策略存在三种同步方式，通过对/etc/redis/6379.conf的729行的修改进行配置。

4.2.3.1 appendfsync always

将命令写入aof_buf后，立即进行系统fsync操作，将其同步到AOF文件，当fsync操作完成后，线程便会返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也就只能处理几万个命令，而且会大大降低SSD的寿命。

4.2.3.2 appendfsync no

命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负载，通常同步周期为30秒。文件同步时间不可预测，并且缓冲区中的数据会堆积很多，导致数据安全性无法保障。

4.2.3.3 appendfsync everysec（推荐）

命令写入aof_buf后调用系统write操作，write完成后线程返回：fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，一次是Redis的默认配置，也是我们推荐的配置。

4.2.4 文件重写（rewrite）

随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。
关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后定时任务在每天的某一时刻定时执行。

4.2.4.1 具有压缩功能的原因

文件重写之所以能够压缩AOF文件，原因在于：

过期的数据不再写入文件。
无效的命令不再写入文件：如有些数据被重复设置（set mykey v1,set mykey v2）、有些数据被删除了（set myset v1,del myset）等。
多条命令可以合并为一个：如sadd myset v1,sadd myset v2,sadd myset v3可以合并为sadd myset v1 v2 v3。

通过上述原因可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

4.2.4.2 文件重写的触发

文件重写分为手动触发和自动触发：

手動トリガー: bfrewriteaof コマンドを直接呼び出します。このコマンドの実行は、bgsave に似ています。どちらのフォークプロセスも特定の作業を実行し、フォーク時にのみブロックされます。
自動トリガー: auto-aof-rewrite-min-size オプションと auto-aof-rewrite-percentage オプションを設定して、bgrewriteaof を自動的に実行します。 auto-aof-rewrite-min-size と auto-aof-rewrite-percentage の 2 つのオプションが同時に満たされた場合にのみ、AOF の書き換え、つまり bgrewriteaof 操作が自動的にトリガーされます。

#自動的にトリガーされる構成は、/etc/redis/6379.conf

auto の 771 行目と 772 行目にあります。 -aof-rewrite-percentage 100
現在の AOF ファイルサイズ (つまり、aof_current_size) が最後のログ書き換え時に AOF ファイルサイズ (aof_base_size) の 2 倍になった場合、bgrewriteaof 操作が発生します
ファイルサイズが小さいために頻繁に bgrewriteaof

ファイルの書き換えプロセスは次のとおりです: Redis で高可用性と永続性を構成する方法

ファイルの書き換えプロセスに関しては、特別な注意が必要な 2 つの点があります。

RDB の永続性

利点: RDB ファイルはコンパクトでサイズが小さいネットワーク転送は高速でフルコピーに適しており、回復速度は AOF よりもはるかに高速です。もちろん、RDB の最も重要な利点の 1 つは、AOF に比べてパフォーマンスへの影響が比較的小さいことです。

欠点: RDB ファイルのよく知られた欠点は、データスナップショットの永続化方法により、リアルタイムの永続性が達成できないと判断されることです。データの重要性がますます高まっている今日、大量のデータが失われることがよくあります。したがって、AOF 永続化が主流になりました。さらに、RDB ファイルは特定の形式を満たす必要があり、互換性が低くなります (たとえば、古いバージョンの Redis は新しいバージョンの RDB ファイルと互換性がありません)。

RDB の永続化では、bgsave がフォーク操作を実行するときに Redis のメインプロセスがブロックされる一方で、ハードディスクにデータを書き込むサブプロセスも IO プレッシャーをもたらします。

AOF 永続性

RDB 永続性と同様に、AOF の優先順位は、第 2 レベルの永続性と良好な互換性をサポートすることです。欠点は、ファイルが大きく、回復速度が遅く、パフォーマンスに大きな影響を与えます。

AOF 永続性の場合、ハードディスクへのデータの書き込み頻度が大幅に増加し (everysec ポリシーの 2 番目のレベル)、IO プレッシャーが増大し、AOF で追加のブロッキング問題が発生する可能性もあります。

跟RDB的bgsave類似，AOF檔的重寫也會面臨fork阻塞和子程序IO負載的問題。 AOF向硬碟中寫入資料的頻率更高，相較之下，會對Redis主流程的效能產生更大的影響。

一般來說，建議關閉AOF的自動重寫功能，並在重寫操作設定計劃任務，放在凌晨業務量低的時候進行，以降低AOF對主進程性能的影響以及IO的讀寫壓力。


永続化は最も単純な高可用性方法です (高可用性方法として分類されない場合もあります)。その主な機能はデータのバックアップ、つまり、プロセスの終了によってデータが失われないようにデータをハードディスクに保存することです。。
マスタースレーブレプリケーションは高可用性 Redis の基礎であり、Sentinel と Cluster はどちらもマスタースレーブレプリケーションに基づいて高可用性を実現します。マスター/スレーブレプリケーションでは、主にデータのマルチマシンバックアップのほか、読み取り操作の負荷分散と単純な障害回復が実装されます。欠点: 障害回復は自動化できず、書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
Sentinel は、マスター/スレーブレプリケーションに基づいて、自動障害回復を実装します。欠点: 書き込み操作は負荷分散できず、ストレージ容量は 1 台のマシンによって制限されます。
Redis は、クラスター化を通じて、書き込み操作の負荷分散ができず、ストレージ容量が 1 台のマシンによって制限されるという問題を解決し、比較的完全な高パフォーマンスを実現します。可用性ソリューション。