Redis の古典的な手法の永続化原理の詳細な説明

この記事では、Redis に関する関連知識を提供します。主に永続化関連の問題を紹介します。Redis 永続化のメカニズムと原理をさまざまな側面から紹介できます。皆様のお役に立てれば幸いです。 。

#推奨される学習:

Redis チュートリアル

この記事では、次の側面から Redis 永続化メカニズムを紹介します。

この記事では、Redis の 2 つの永続化メソッド全体について、動作原理、永続化プロセス、実践的な戦略、およびその背後にある理論的知識を含めて詳しく紹介します。前回の記事ではRDBの永続化についてのみ紹介しましたが、Redisの永続化は全体であり個別に紹介できないため再整理しました。

Redis はインメモリ データベースであり、すべてのデータはメモリに保存されます。データをハードディスクに直接保存する MySQL、Oracle、SqlServer などの従来のリレーショナル データベースと比較して、Redis の読み書きは非常に効率的です。ただし、メモリへの保存には大きな欠点があり、電源が切れたり、コンピュータがダウンしたりすると、メモリ データベースの内容はすべて失われます。この欠点を補うために、Redis では、メモリ データをハードディスク ファイルに永続化し、バックアップ ファイルを通じてデータを復元する機能 (Redis 永続化メカニズム) を提供します。

Redis は、RDB スナップショットと AOF という 2 つの永続化方法をサポートしています。

RDB 永続性

RDB スナップショット 正式な言葉: RDB 永続性ソリューションは、指定された時間間隔でデータ セットに対して生成されるポイントツータイム スナップショットです。特定の時点での Redis データベース内のすべてのデータ オブジェクトのメモリ スナップショットを圧縮バイナリ ファイルに保存します。これは、Redis データのバックアップ、転送、リカバリに使用できます。これまでのところ、これはまだ公式のデフォルトのサポート ソリューションです。

RDB の動作原理

RDB は Redis 内のデータセットの特定時点のスナップショットであるため、まず Redis 内のデータ オブジェクトがどのようにメモリ内に保存され編成されるかを簡単に理解しましょう。

デフォルトでは、Redis には 16 のデータベースがあり、0 ～ 15 の番号が付けられています。各 Redis データベースは

redisDb オブジェクトによって表され、redisDb はハッシュテーブル ストレージ K-V オブジェクトを使用します。理解を容易にするために、データベースの 1 つを例として、Redis の内部データのストレージ構造の概略図を描きました。 ポイントインタイム スナップショットは、特定の瞬間における Redis の各 DB 内の各データ オブジェクトのステータスです。 現時点ではすべてのデータ オブジェクトが変化しないと仮定します。、次の図に従うことができます。上記のファイル内のデータ構造関係に基づいて、これらのデータ オブジェクトは Redis の永続性を実現するために読み取られ、ファイルに書き込まれます。その後、Redis が再起動すると、このファイルの内容がルールに従って読み取られ、Redis メモリに書き込まれて永続的な状態に復元されます。

もちろん、上記の仮定が正しい場合、この前提は当てはまります。そうでない場合、常に変化するデータセットに直面して開始する方法はありません。 Redis でのクライアント コマンド処理はシングルスレッド モデルであることがわかっていますが、永続化がコマンドとして処理される場合、データ セットは間違いなく静的な状態になります。さらに、オペレーティング システムが提供する fork() 関数によって作成された子プロセスは、親プロセスと同じメモリ データを取得できます。これはメモリ データのコピーを取得することと同等であり、フォークが完了した後、次のことを行う必要があります。親プロセスが行うと、状態を永続化する作業が引き継がれるので、それを子プロセスに渡すだけです。

明らかに、最初の状況はお勧めできません。永続的なバックアップにより、Redis サービスが短期間利用できなくなりますが、これは高 HA システムでは耐えられません。したがって、2 番目の方法が RDB 永続化の主な実用的な方法になります。子プロセスをフォークした後も親プロセスのデータは変化し続け、子プロセスは親プロセスと同期していないため、RDB 永続化はリアルタイム性を保証できず、RDB 永続化完了後に停電やダウンタイムが発生すると、部分的なデータ損失、バックアップ 頻度によって失われたデータの量が決まります。バックアップ頻度を増やすと、フォーク プロセスがより多くの CPU リソースを消費し、ディスク I/O も大きくなります。

永続化プロセス

Redis で RDB 永続化を完了するには、rdbSave と rdbSaveBackground (ソース コード ファイル rdb.c 内) の 2 つの方法があります。この 2 つの違いについて簡単に説明します。

• rdbSave: 同期的に実行され、メソッド呼び出し直後に永続化処理が開始されます。 Redis はシングルスレッド モデルであるため、永続化プロセス中にブロックされ、Redis は外部サービスを提供できません。

• rdbSaveBackground: はバックグラウンド (非同期) で実行され、これはメソッドは子プロセスをフォークアウトします。実際の永続化プロセスは子プロセス (rdbSave の呼び出し) で実行され、メイン プロセスは引き続きサービスを提供します。

RDB 永続化のトリガーは上記 2 つの方法から切り離すことができず、トリガー方法は手動と自動に分けられます。手動トリガーは理解しやすいです。これは、Redis クライアントを通じて Redis サーバーへの永続化バックアップ命令を手動で開始し、Redis サーバーが永続化プロセスの実行を開始することを意味します。ここでの命令には、save と bgsave が含まれます。自動トリガーは、独自の動作要件に基づいて事前設定された条件が満たされたときに Redis が自動的にトリガーする永続化プロセスです。自動トリガーされるシナリオは次のとおりです (この記事から抜粋):

• serverCron Medium save m n構成ルールは自動的にトリガーされます;

• スレーブ ノードが完全にコピーされると、マスター ノードは rdb ファイルをスレーブ ノードに送信してコピーを完了します操作を実行すると、マスター ノードが bgsave を開始します;

• debug reload コマンドを実行して redis をリロードするとき;

• デフォルト (AOF は有効になっていません) では、shutdown コマンドが実行されます。このとき、bgsave が自動的に実行されます。

ソース コードと参考記事を組み合わせて、RDB 永続化プロセスを整理しました。誰もが全体的な理解を持っており、それからいくつかの詳細を説明します。 上の図から次のことがわかります:

• 自動的にトリガーされる RDB 永続化は、rdbSaveBackground を通じてサブプロセスで実行される永続化戦略です。

  手動トリガーは、save コマンドや bgsave コマンドなどのクライアント コマンドによってトリガーされます。保存コマンドは、Redis コマンド処理スレッドの
rdbSave
• メソッドをブロック的に呼び出すことで完了します。
  自動トリガー プロセスは、rdbSaveBackground、rdbSave などをカバーする完全なリンクです。次に、プロセス全体を分析するための例として、serverCron を使用します。

保存ルールとチェック

serverCron は Redis の定期関数であり、100 ミリ秒ごとに実行されます。そのジョブの 1 つは、構成ファイル内の保存ルールに基づいて現在の状況を判断することです。自動永続化プロセスが必要であり、条件が満たされると永続化の開始が試行されます。この部分の実装について学習します。

redisServer

には RDB の永続化に関連するフィールドがいくつかあります。コードからそれらを抽出し、中国語と英語で調べました:

struct redisServer {
 /* 省略其他字段 */ 
    /* RDB persistence */
    long long dirty;                /* Changes to DB from the last save
             * 上次持久化后修改key的次数 */
    struct saveparam *saveparams;   /* Save points array for RDB，
             * 对应配置文件多个save参数 */
    int saveparamslen;              /* Number of saving points，
             * save参数的数量 */
    time_t lastsave;                /* Unix time of last successful save 
             * 上次持久化时间*/
    /* 省略其他字段 */
}

/* 对应redis.conf中的save参数 */
struct saveparam {
    time_t seconds;     /* 统计时间范围 */   
    int changes;     /* 数据修改次数 */
};

saveparams は、

redis.conf

の保存ルールに対応します。保存パラメータは、Redis が自動バックアップをトリガーするためのトリガー戦略です。秒は統計時間 (単位: 秒)、changes は、統計時間内に発生した書き込みの数です。 save m n は、m 秒以内に n 回の書き込みがある場合、スナップショット、つまりバックアップがトリガーされることを意味します。保存パラメータの複数のグループを構成して、さまざまな条件下でのバックアップ要件を満たすことができます。 RDB の自動バックアップ ポリシーをオフにする必要がある場合は、save "" を使用できます。以下に、いくつかの構成について説明します。 <pre class="brush:php;toolbar:false"># 表示900秒（15分钟）内至少有1个key的值发生变化，则执行 save 900 1 # 表示300秒（5分钟）内至少有1个key的值发生变化，则执行 save 300 10 # 表示60秒（1分钟）内至少有10000个key的值发生变化，则执行 save 60 10000 # 该配置将会关闭RDB方式的持久化 save &quot;&quot;</pre>serverCronRDB 保存ルールの検出コードは次のとおりです。

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
    /* 省略其他逻辑 */
    
    /* 如果用户请求进行AOF文件重写时，Redis正在执行RDB持久化，Redis会安排在RDB持久化完成后执行AOF文件重写，
     * 如果aof_rewrite_scheduled为true，说明需要执行用户的请求 */
    /* Check if a background saving or AOF rewrite in progress terminated. */
    if (hasActiveChildProcess() || ldbPendingChildren())
    {
        run_with_period(1000) receiveChildInfo();
        checkChildrenDone();
    } else {
        /* 后台无 saving/rewrite 子进程才会进行，逐个检查每个save规则*/
        for (j = 0; j = sp->changes 
                && server.unixtime-server.lastsave > sp->seconds 
                &&(server.unixtime-server.lastbgsave_try > CONFIG_BGSAVE_RETRY_DELAY || server.lastbgsave_status == C_OK))
            {
                serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...", sp->changes, (int)sp->seconds);
                rdbSaveInfo rsi, *rsiptr;
                rsiptr = rdbPopulateSaveInfo(&rsi);
                /* 执行bgsave过程 */
                rdbSaveBackground(server.rdb_filename,rsiptr);
                break;
            }
        }

        /* 省略：Trigger an AOF rewrite if needed. */
    }
 /* 省略其他逻辑 */
}

バックグラウンドでの RDB 永続性または AOF がない場合replication プロセスを作成する際、serverCron は上記の設定とステータスに基づいて永続化操作を実行する必要があるかどうかを判断します。判断基準は、lastsave と Dirty が saveparams 配列の条件のいずれかを満たしているかどうかです。条件が一致すると、rdbSaveBackground メソッドが呼び出され、非同期永続化処理が実行されます。 rdbSaveBackground

rdbSaveBackground は RDB 永続化のための補助メソッドです。その主な仕事は子プロセスをフォークすることであり、呼び出し元 (親プロセスまたは子プロセス) に応じて 2 つの異なる実行ロジックがあります。 ）。

呼び出し元が親プロセスの場合は、子プロセスをフォークアウトし、子プロセスの情報を保存して、直接戻ります。

• 呼び出し元が子プロセスの場合は、rdbSave を呼び出して RDB 永続化ロジックを実行し、永続化が完了したら子プロセスを終了します。

• int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
      pid_t childpid;
  
      if (hasActiveChildProcess()) return C_ERR;
  
      server.dirty_before_bgsave = server.dirty;
      server.lastbgsave_try = time(NULL);
  
      // fork子进程
      if ((childpid = redisFork(CHILD_TYPE_RDB)) == 0) {
          int retval;
  
          /* Child 子进程：修改进程标题 */
          redisSetProcTitle("redis-rdb-bgsave");
          redisSetCpuAffinity(server.bgsave_cpulist);
          // 执行rdb持久化
          retval = rdbSave(filename,rsi);
          if (retval == C_OK) {
              sendChildCOWInfo(CHILD_TYPE_RDB, 1, "RDB");
          }
          // 持久化完成后，退出子进程
          exitFromChild((retval == C_OK) ? 0 : 1);
      } else {
          /* Parent 父进程：记录fork子进程的时间等信息*/
          if (childpid == -1) {
              server.lastbgsave_status = C_ERR;
              serverLog(LL_WARNING,"Can't save in background: fork: %s",
                  strerror(errno));
              return C_ERR;
          }
          serverLog(LL_NOTICE,"Background saving started by pid %ld",(long) childpid);
          // 记录子进程开始的时间、类型等。
          server.rdb_save_time_start = time(NULL);
          server.rdb_child_type = RDB_CHILD_TYPE_DISK;
          return C_OK;
      }
      return C_OK; /* unreached */
  }

  rdbSave は永続化を真に実行するメソッドであり、実行中に大量の I/O と計算操作が含まれるため、時間がかかり、大量の CPU を消費します。 Redis のシングルスレッド モデルでは、中程度の永続性プロセスがスレッド リソースを占有し続けるため、Redis は他のサービスを提供できなくなります。この問題を解決するために、Redis は rdbSaveBackground で子プロセスをフォークアウトし、子プロセスは永続化作業を完了して、親プロセスのリソースを過剰に占有することを回避します。

親プロセスのメモリ使用量が大きすぎる場合、フォーク処理に時間がかかることに注意してください。この処理中、親プロセスは外部サービスを提供できません。また、コンピュータは子プロセスをフォークする前にメモリ使用量を総合的に考慮する必要があり、メモリ リソースが 2 倍占有されるため、十分なメモリを確保する必要があります。 info stats コマンドでlatest_fork_usec オプションを確認し、最新のフォーク操作にかかった時間を取得します。

rdb保存

Redis的rdbSave函数是真正进行RDB持久化的函数，流程、细节贼多，整体流程可以总结为：创建并打开临时文件、Redis内存数据写入临时文件、临时文件写入磁盘、临时文件重命名为正式RDB文件、更新持久化状态信息（dirty、lastsave）。其中“Redis内存数据写入临时文件”最为核心和复杂，写入过程直接体现了RDB文件的文件格式，本着一图胜千言的理念，我按照源码流程绘制了下图。 补充说明一下，上图右下角“遍历当前数据库的键值对并写入”这个环节会根据不同类型的Redis数据类型及底层数据结构采用不同的格式写入到RDB文件中，不再展开了。我觉得大家对整个过程有个直观的理解就好，这对于我们理解Redis内部的运作机制大有裨益。

AOF持久化

上一节我们知道RDB是一种时间点（point-to-time）快照，适合数据备份及灾难恢复，由于工作原理的“先天性缺陷”无法保证实时性持久化，这对于缓存丢失零容忍的系统来说是个硬伤，于是就有了AOF。

AOF工作原理

AOF是Append Only File的缩写，它是Redis的完全持久化策略，从1.1版本开始支持；这里的file存储的是引起Redis数据修改的命令集合（比如：set/hset/del等），这些集合按照Redis Server的处理顺序追加到文件中。当重启Redis时，Redis就可以从头读取AOF中的指令并重放，进而恢复关闭前的数据状态。

AOF持久化默认是关闭的，修改redis.conf以下信息并重启，即可开启AOF持久化功能。

# no-关闭，yes-开启，默认no
appendonly yes
appendfilename appendonly.aof

AOF本质是为了持久化，持久化对象是Redis内每一个key的状态，持久化的目的是为了在Reids发生故障重启后能够恢复至重启前或故障前的状态。相比于RDB，AOF采取的策略是按照执行顺序持久化每一条能够引起Redis中对象状态变更的命令，命令是有序的、有选择的。把aof文件转移至任何一台Redis Server，从头到尾按序重放这些命令即可恢复如初。举个例子：

首先执行指令set number 0，然后随机调用incr number、get number 各5次，最后再执行一次get number ，我们得到的结果肯定是5。

因为在这个过程中，能够引起number状态变更的只有set/incr类型的指令，并且它们执行的先后顺序是已知的，无论执行多少次get都不会影响number的状态。所以，保留所有set/incr命令并持久化至aof文件即可。按照aof的设计原理，aof文件中的内容应该是这样的（这里是假设，实际为RESP协议）：

set number 0
incr number
incr number
incr number
incr number
incr number

最本质的原理用“命令重放”四个字就可以概括。但是，考虑实际生产环境的复杂性及操作系统等方面的限制，Redis所要考虑的工作要比这个例子复杂的多：

• Redis Server启动后，aof文件一直在追加命令，文件会越来越大。文件越大，Redis重启后恢复耗时越久；文件太大，转移工作就越难；不加管理，可能撑爆硬盘。很显然，需要在合适的时机对文件进行精简。例子中的5条incr指令很明显的可以替换为为一条set命令，存在很大的压缩空间。

• 众所周知，文件I/O是操作系统性能的短板，为了提高效率，文件系统设计了一套复杂的缓存机制，Redis操作命令的追加操作只是把数据写入了缓冲区（aof_buf），从缓冲区到写入物理文件在性能与安全之间权衡会有不同的选择。

• 文件压缩即意味着重写，重写时即可依据已有的aof文件做命令整合，也可以先根据当前Redis内数据的状态做快照，再把存储快照过程中的新增的命令做追加。

• aof备份后的文件是为了恢复数据，结合aof文件的格式、完整性等因素，Redis也要设计一套完整的方案做支持。

持久化流程

从流程上来看，AOF的工作原理可以概括为几个步骤：命令追加（append）、文件写入与同步（fsync）、文件重写（rewrite）、重启加载（load），接下来依次了解每个步骤的细节及背后的设计哲学。

命令追加

AOF 永続化機能がオンになっている場合、Redis は書き込みコマンドを実行した後、実行された書き込みコマンドを Redis サーバーが保持する AOF バッファーの末尾に追加します。 AOF ファイルの追加操作はシングルスレッドのみであり、シークなどの複雑な操作はなく、停電やダウンタイムが発生してもファイルが破損する心配はありません。さらに、テキスト プロトコルを使用することには多くの利点があります:

• テキスト プロトコルには優れた互換性があります;

• テキスト プロトコルはクライアントのrequest コマンドではなく、二次処理が必要なため、保存およびロード中の処理オーバーヘッドが節約されます。

• テキスト プロトコルは読みやすく、表示、変更、その他の処理に便利です。

AOF バッファ タイプは、Redis sds によって独自に設計されたデータ構造です。Redis はコマンドの種類 (catAppendOnlyGenericCommand##) に応じて異なるメソッドを使用します。 #、catAppendOnlyExpireAtCommand など) コマンドの内容を処理し、最終的にバッファーに書き込みます。

コマンドを追加するときに AOF 書き換えが進行中の場合、これらのコマンドは書き換えバッファ (

aof_rewrite_buffer) にも追加されることに注意してください。

ファイルの書き込みと同期

AOF ファイルの書き込みと同期は、オペレーティング システムのサポートから切り離すことはできません。導入を開始する前に、Linux I/O に関する知識を追加する必要があります。バッファー。ハードディスクのI/O性能が悪く、ファイルの読み書き速度がCPUの処理速度に比べてはるかに劣るため、ファイルを書き込むたびにハードディスクへのデータの書き込みを待っていると、オペレーティング システムの全体的なパフォーマンスが低下します。この問題を解決するために、オペレーティング システムは、ハード ディスクの I/O パフォーマンスを向上させる遅延書き込みメカニズムを提供します。

従来の UNIX 実装では、カーネル内にバッファ キャッシュまたはページ キャッシュがあり、ほとんどのディスク I/O はバッファリングを通じて実行されます。ファイルにデータを書き込むとき、カーネルは通常、最初にデータをバッファの 1 つにコピーします。バッファがまだいっぱいでない場合は、出力キューにキューに入れず、バッファがいっぱいになるまで、またはカーネルが必要とするときに待ちます。バッファが他のディスク ブロック データを格納するために再利用される場合、バッファは出力キューに入れられ、実際の I/O 操作はキューの先頭に達したときにのみ実行されます。この出力方法を遅延書き込みと呼びます。

書き込みを遅延すると、ディスクの読み取りと書き込みの回数が減りますが、ファイルの内容の更新速度も低下するため、ファイルに書き込まれるデータが一定期間ディスクに書き込まれなくなります。時間の。システム障害が発生すると、この遅延によりファイルの更新が失われる可能性があります。ディスク上の実際のファイル システムとバッファ キャッシュ内のコンテンツの一貫性を確保するために、UNIX システムは 3 つの関数 (sync、fsync、および fdatasync) を提供し、ハード ディスクへの強制書き込みをサポートします。

Redis は、各イベントのローテーションが終了する前 (

beforeSleep) に関数 flushAppendOnlyFile を呼び出し、flushAppendOnlyFile が AOF バッファー (aof_buf) をフラッシュします。 ) はカーネル バッファに書き込まれ、カーネル バッファ内のデータをディスクに書き込むために使用される戦略は、appendfsync 構成に基づいて決定されます。つまり、fsync()# を呼び出します。 ＃＃。この構成には 3 つのオプション オプション always、no、everysec があります。詳細は次のとおりです。

always:毎回
• fsync()

  を呼び出すのは、セキュリティが最も高く、パフォーマンスが最悪の戦略です。

いいえ:
• fsync()

  は呼び出されません。最高のパフォーマンス、最悪のセキュリティ。

毎秒: 同期条件が満たされた場合にのみ
• fsync()

  を呼び出します。これは公式に推奨される同期戦略であり、デフォルトの構成でもあります。パフォーマンスとデータ セキュリティの両方が考慮されています。理論的には、突然のシステム シャットダウンが発生した場合でも、データが失われるのは 1 秒だけです。

注: 上記で紹介した戦略は、設定項目

no-appendfsync-on-rewrite の影響を受けます。その機能は、Redis に次の AOF ファイルを通知することです。 rewrite 書き込み中の fsync() の呼び出しを無効にするかどうか。デフォルトは no です。

appendfsync

が always または everysec に設定されている場合、BGSAVE または は進行中です。バックグラウンドの BGREWRITEAOF はディスク I/O を大量に消費します。特定の Linux システム構成では、Redis による fsync() の呼び出しが長時間ブロックされる可能性があります。ただし、fsync() が別のスレッドで実行された場合でも同期書き込み操作はブロックされるため、この問題はまだ修正されていません。 この問題を軽減するには、このオプションを使用して、

BGSAVE

または BGREWRITEAOF の実行中にメイン プロセスで fsync() が呼び出されないようにすることができます。

• yes

  に設定すると、子プロセスが BGSAVE または BGREWRITEAOF を実行している場合、AOF 永続化機能が有効になります。 appendfsync を no に設定するのと同じ効果があります。最悪の場合、キャッシュされたデータが 30 秒間失われる可能性があります。

システムに上記の遅延の問題がある場合は、このオプションを
• yes

  に設定し、それ以外の場合は no のままにしてください。

ファイルの書き換え

如前面提到的，Redis长时间运行，命令不断写入AOF，文件会越来越大，不加控制可能影响宿主机的安全。

为了解决AOF文件体积问题，Redis引入了AOF文件重写功能，它会根据Redis内数据对象的最新状态生成新的AOF文件，新旧文件对应的数据状态一致，但是新文件会具有较小的体积。重写既减少了AOF文件对磁盘空间的占用，又可以提高Redis重启时数据恢复的速度。还是下面这个例子，旧文件中的6条命令等同于新文件中的1条命令，压缩效果显而易见。 我们说，AOF文件太大时会触发AOF文件重写，那到底是多大呢？有哪些情况会触发重写操作呢？ ** 与RDB方式一样，AOF文件重写既可以手动触发，也会自动触发。手动触发直接调用bgrewriteaof命令，如果当时无子进程执行会立刻执行，否则安排在子进程结束后执行。自动触发由Redis的周期性方法serverCron检查在满足一定条件时触发。先了解两个配置项：

• auto-aof-rewrite-percentage：代表当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）相比，增长的比例。

• auto-aof-rewrite-min-size：表示运行BGREWRITEAOF时AOF文件占用空间最小值，默认为64MB；

Redis启动时把aof_base_size初始化为当时aof文件的大小，Redis运行过程中，当AOF文件重写操作完成时，会对其进行更新；aof_current_size为serverCron执行时AOF文件的实时大小。当满足以下两个条件时，AOF文件重写就会触发：

增长比例：(aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage
文件大小：aof_current_size > auto-aof-rewrite-min-size

手动触发与自动触发的代码如下，同样在周期性方法serverCron中：

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
    /* 省略其他逻辑 */
    
    /* 如果用户请求进行AOF文件重写时，Redis正在执行RDB持久化，Redis会安排在RDB持久化完成后执行AOF文件重写，
     * 如果aof_rewrite_scheduled为true，说明需要执行用户的请求 */
    if (!hasActiveChildProcess() &&
        server.aof_rewrite_scheduled)
    {
        rewriteAppendOnlyFileBackground();
    }

    /* Check if a background saving or AOF rewrite in progress terminated. */
    if (hasActiveChildProcess() || ldbPendingChildren())
    {
        run_with_period(1000) receiveChildInfo();
        checkChildrenDone();
    } else {
        /* 省略rdb持久化条件检查 */

        /* AOF重写条件检查：aof开启、无子进程运行、增长百分比已设置、当前文件大小超过阈值 */
        if (server.aof_state == AOF_ON &&
            !hasActiveChildProcess() &&
            server.aof_rewrite_perc &&
            server.aof_current_size > server.aof_rewrite_min_size)
        {
            long long base = server.aof_rewrite_base_size ?
                server.aof_rewrite_base_size : 1;
            /* 计算增长百分比 */
            long long growth = (server.aof_current_size*100/base) - 100;
            if (growth >= server.aof_rewrite_perc) {
                serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);
                rewriteAppendOnlyFileBackground();
            }
        }
    }
    /**/
}

AOF文件重写的流程是什么？听说Redis支持混合持久化，对AOF文件重写有什么影响？

从4.0版本开始，Redis在AOF模式中引入了混合持久化方案，即：纯AOF方式、RDB+AOF方式，这一策略由配置参数aof-use-rdb-preamble（使用RDB作为AOF文件的前半段）控制，默认关闭(no)，设置为yes可开启。所以，在AOF重写过程中文件的写入会有两种不同的方式。当aof-use-rdb-preamble的值是：

• no：按照AOF格式写入命令，与4.0前版本无差别；

• yes：先按照RDB格式写入数据状态，然后把重写期间AOF缓冲区的内容以AOF格式写入，文件前半部分为RDB格式，后半部分为AOF格式。

结合源码（6.0版本，源码太多这里不贴出，可参考aof.c）及参考资料，绘制AOF重写（BGREWRITEAOF）流程图： 结合上图，总结一下AOF文件重写的流程：

• rewriteAppendOnlyFileBackground开始执行，检查是否有正在进行的AOF重写或RDB持久化子进程：如果有，则退出该流程；如果没有，则继续创建接下来父子进程间数据传输的通信管道。执行fork()操作，成功后父子进程分别执行不同的流程。

• 父进程：

  • 记录子进程信息（pid）、时间戳等；

  • 继续响应其他客户端请求；

  • 收集AOF重写期间的命令，追加至aof_rewrite_buffer；

  • 等待并向子进程同步aof_rewrite_buffer的内容；

• 子进程：

  • 修改当前进程名称，创建重写所需的临时文件，调用rewriteAppendOnlyFile函数；

  • 根据aof-use-rdb-preamble配置，以RDB或AOF方式写入前半部分，并同步至硬盘；

  • 从父进程接收增量AOF命令，以AOF方式写入后半部分，并同步至硬盘；

  • 重命名AOF文件，子进程退出。

数据加载

Redis启动后通过loadDataFromDisk函数执行数据加载工作。这里需要注意，虽然持久化方式可以选择AOF、RDB或者两者兼用，但是数据加载时必须做出选择，两种方式各自加载一遍就乱套了。

理論的には、AOF 永続性は RDB よりも優れたリアルタイム パフォーマンスを備えています。AOF 永続性が有効になっている場合、Redis はデータのロード時に AOF を優先します。さらに、Redis 4.0 バージョン以降、AOF はハイブリッド永続性をサポートするため、AOF ファイルをロードするときにバージョンの互換性を考慮する必要があります。 Redis のデータ読み込みプロセスを以下の図に示します: AOF モードでは、ハイブリッド永続化機構をオンにすることで生成されるファイルは「RDB ヘッダーと AOF テール」ですが、オンにしていない場合は、生成されるファイルはすべてAOF形式で。 2 つのファイル形式の互換性を考慮して、AOF ファイルが RDB ヘッダーであると Redis が検出した場合、RDB データ ロード メソッドを使用して前半を読み取り、復元し、次に AOF メソッドを使用して後半を読み取り、復元します。 。 AOF 形式で保存されたデータは RESP プロトコル コマンドであるため、Redis は擬似クライアントを使用してコマンドを実行し、データを回復します。

AOF コマンドの追加プロセス中にダウンタイムが発生した場合、遅延書き込みの技術的特性により、AOF の RESP コマンドが不完全 (切り捨て) になる可能性があります。この状況が発生した場合、Redis は構成項目 aof-load-truncated に従ってさまざまな処理戦略を実行します。この構成は、Redis に起動時に aof ファイルを読み取るように指示し、ファイルが切り詰められている (不完全である) ことが判明した場合にどうするかを指示します:

• #yes: できるだけ多くのデータをロードします。ログの形式でユーザーに通知します;

• no: システム エラーでクラッシュし、起動が禁止されます。ユーザーは再起動する前にファイルを修復する必要があります。

概要

Redis は 2 つの永続化オプションを提供します: RDB は、特定の実用的な間隔でデータ セットのポイントインタイム スナップショットの生成をサポートします; AOF は Redis サーバーを受け取ります 各書き込み命令はデータはログに永続化され、Redis の再起動時に再生コマンドを通じて復元されます。ログ形式は RESP プロトコルであり、ログ ファイルに対して追加操作のみが実行されるため、破損の危険はありません。また、AOF ファイルが大きすぎる場合、圧縮ファイルを自動的に書き換えることができます。

もちろん、データを永続化する必要がない場合は、Redis の永続化機能を無効にすることもできますが、これはほとんどの場合には当てはまりません。実際、RDB と AOF を同時に使用することがありますが、最も重要なことは、RDB と AOF を合理的に使用するために 2 つの違いを理解することです。

RDB と AOF

RDB の利点

• RDB は、特定の時点の Redis を表すコンパクトな圧縮バイナリ ファイルです。ポイント上のスナップショットは、バックアップや完全レプリケーションなどのシナリオに非常に適しています。

• RDB は災害復旧やデータ移行に非常に適しており、RDB ファイルを必要な場所に移動して再ロードできます。

• RDB は Redis データのメモリ スナップショットであり、AOF コマンドの再生よりもデータの回復速度が速く、パフォーマンスが優れています。

RDB の欠点

• RDB メソッドは、リアルタイムまたは第 2 レベルの永続性を実現できません。永続化プロセスは子プロセスをフォークした後に子プロセスによって完了するため、子プロセスのメモリはフォーク操作の時点での親プロセスのデータのスナップショットにすぎず、フォーク操作後も親プロセスは続行されます。内部データは常に変化しており、データは更新されず、両者の間には常に差異が存在するため、リアルタイムのパフォーマンスを実現できません。

• RDB 永続化プロセス中のフォーク操作ではメモリ使用量が 2 倍になり、親プロセスのデータが増えるほどフォーク プロセスに時間がかかります。

• Redis リクエストの同時実行性が高いと、保存ルールに頻繁にヒットし、フォーク操作と永続的なバックアップの頻度が制御不能になる可能性があります。

• RDBファイルにはファイル形式の要件があり、Redis のバージョンが異なるとファイル形式が調整され、古いバージョンは新しいバージョンと互換性がないという問題があります。

AOF の利点

• AOF 永続性はリアルタイム パフォーマンスが優れており、3 つの異なる方法 (appendfsync) を選択できます: いいえ、毎秒、デフォルトの戦略として常に、毎秒が最高のパフォーマンスを発揮しますが、極端な場合には 1 秒間のデータが失われる可能性があります。

• AOF ファイルには追加操作のみがあり、複雑なシークやその他のファイル操作はなく、損傷の危険はありません。最後に書き込まれたデータが切り詰められている場合でも、redis-check-aof ツールを使用して簡単に修復できます。

• AOF ファイルが大きくなった場合、Redis は自動的に書き換えられます。書き換え処理中は古いファイルの書き込みが継続されますが、書き換えが完了すると新しいファイルは小さくなり、書き換え処理中の増分コマンドも新しいファイルに追加されます。

• AOF ファイルには、Redis 内のデータに対するすべての操作コマンドが、理解しやすく解析しやすい方法で含まれています。たとえ誤って全データを消去してしまったとしても、AOFファイルを書き換えない限り、最後のコマンドを削除することで全データを取り戻すことができます。

• AOF はすでにハイブリッド永続性をサポートしており、ファイル サイズを効果的に制御でき、データ読み込みの効率が向上しています。

AOF の欠点

• 同じデータ収集の場合、AOF ファイルは通常、RDB ファイルよりも大きくなります;

• 特定の fsync 戦略では、AOF は RDB よりもわずかに遅くなります。一般的に言えば、fsync_every_sec のパフォーマンスは依然として非常に高く、fsync_no のパフォーマンスは RDB に匹敵します。ただし、書き込みプレッシャーが非常に大きい場合、RDB は最大の低レイテンシ保証を提供できます。

• AOF で、Redis はかつて、RDB ではほとんど遭遇することが不可能ないくつかのまれなバグに遭遇しました。一部の特別な命令 (BRPOPLPUSH など) により、リロードされたデータが永続化前のデータと不一致になることがあり、Redis 担当者はかつて同じ条件でテストしましたが、問題は再現できませんでした。

使用上の提案

RDB と AOF の 2 つの永続化方式の動作原理、実行プロセス、利点と欠点を理解した後、考えてみましょう次に、実際のシナリオで長所と短所を比較検討し、2 つの永続化メソッドを合理的に使用する方法について説明します。 Redis をキャッシュツールとしてのみ使用する場合は、永続化データベースに基づいてすべてのデータを再構築することができ、永続化機能をオフにして、予熱、キャッシュの侵入、ブレークダウン、アバランチなどの保護作業を行うことができます。

通常の状況では、Redis は分散ロック、ランキング、登録センターなど、より多くの作業を引き受けます。永続化機能は、災害復旧やデータ移行においてより大きな役割を果たします。

• Redis をデータベースとして使用しないでください。すべてのデータは、可能な限りアプリケーション サービスによって自動的に再構築されます。

• Redis バージョン 4.0 以降を使用し、AOF RDB ハイブリッド永続化機能を使用します。

• AOF の書き換えや保存プロセス中のリソース不足を防ぐために、Redis が占有する最大メモリを合理的に計画します。

• 単一マシンに複数のインスタンスをデプロイすることは避けてください。

• ほとんどの実稼働環境はクラスターにデプロイされており、スレーブで永続化機能を有効にすると、マスターが外部書き込みサービスをより適切に提供できるようになります。

• #災害時バックアップに備えて、バックアップ ファイルをオフサイトのコンピューター室またはクラウド ストレージに自動的にアップロードする必要があります。

fork()について

上記の分析を通じて、RDB スナップショットと AOF の書き換えには fork が必要であることがわかりました。重量のある操作であり、Redis に対するブロックが発生します。したがって、Redis メインプロセスの応答に影響を与えないように、ブロッキングを可能な限り減らす必要があります。

• フォークの頻度を減らします。たとえば、手動で RDB をトリガーしてスナップショットと AOF 書き換えを生成できます。

• 最大メモリ使用量を制御します。フォークに時間がかかりすぎるのを防ぐために Redis を使用する;

• より高性能のハードウェアを使用する;

• 物理メモリ不足を避けるために Linux メモリ割り当て戦略を適切に構成するフォークが失敗する原因

推奨学習: Redis 学習チュートリアル

以上がRedis の古典的な手法の永続化原理の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。