数十億のリクエストと高可用性を備えた Redis (codis) 分散クラスターの秘密を簡単に紹介します。

[[262976]]

1. 背景

生放送元年を迎え、春雨後の竹の子のように生放送作品が次々と登場しています。製品は収益を上げる過程で、ユーザーの消費欲求を刺激するためのさまざまな活動を考えようと全力を尽くしてきましたが、そのような活動の基本的な形はリストです。 2016 年には、cmem とスキャンフローテーブルに基づくリストランキングを実装しました。 2017 年から、元のシステムを再構築し、リストの基本的なストレージとして Redis を使用するようになりました。再構築の過程で、Redis 分散ソリューションの調査というタスクを受け、業界のさまざまなオープンソース製品を比較し、最終的に Codis に決定し、詳細について調査を行いました。 Codisの作者とのやり取りの中で、付加価値製品部門のsimotangが2年近く前から部門内でcodisを導入していたことを幸運にも知り、codisの運用・保守に参加することになりました。現在、部門内には容量2T、1日の総訪問量が100億を超えるcodisクラスターが15セット配備されており、インタラクティブビデオ製品部門の基本的なストレージ、運用活動、リスト関連業務を2年以上サポートしており、合計100以上の活動と数千のリストがあります。同時に、codis への接続プロセスにおいてご指導とご協力をいただいた codis 作者 spinlock 氏に心から感謝の意を表したいと思います。 spinlock github および codis アドレスを参照してください。

2. Redis関連の基礎知識の概要

2.1 Redis の紹介

Redis は、メモリをベースとし、データ永続化機能を備えた、高性能で低レイテンシの KV データベースです。値のデータ構造は、文字列、ハッシュ テーブル、リスト、セット、ソートされたセットになります。

Redis (リモート辞書サーバー)

Redis は、データベース、キャッシュ、メッセージ ブローカーとして使用されるオープン ソース (BSD ライセンス) のインメモリ データ構造ストアです。文字列、ハッシュ、リスト、セット、範囲クエリによるソート済みセットなどのデータ構造をサポートします。実践: http://try.redis.io/

2.2 Redisの特徴

1. シングルスレッドの非同期アーキテクチャ（シングルスレッド、パケットの受信、パケットの送信、解析、実行、ファイルイベントを受信するためのIOの多重化）

2. kv構造、値は豊富なデータ構造（文字列、ハッシュ、リスト、セット、ソートセット）をサポートします。

3. 高性能、低レイテンシ、メモリベースの操作、Get/Set10w+、RDBとAOFに基づく高性能でデータの信頼性を確保

4. 豊富な機能、キャッシュ、メッセージキュー、TTL有効期限に使用可能

5. トランザクションをサポートします。操作はアトミックであり、すべてがコミットされるか、まったくコミットされないかのいずれかになります。

2.3 Redis アプリケーション シナリオ

2.4 序文: codis と redis の関係

codis と redis の関係は、codis が複数の redis インスタンスに基づくルーティング レイヤーを使用してデータをルーティングし、各 redis インスタンスが一定量のデータ シャーディングを担当することです。

2.5 Redis 学習教材

この記事はRedis分散ソリューションに焦点を当てているため、Redisに関連する基本的な部分については、2冊の本と関連するソースコード分析記事を参照してください。

1. Redisの開発と運用・保守（Fu Lei）

2. Redis の設計と実践 (Huang Jianhong) (2 回読む価値あり)

3. 社内外のRedis分散ソリューションの比較

ソリューションを比較する前に、まず、私たちの経験に基づいてソリューションに期待される機能を出力し、選択基準を測定します。

これを踏まえて社内と社外の比較を以下のように行いました。

【社内コンポーネントの比較】

【外部部品の比較】

上記の比較に基づくと、オープンソース製品である Codis は、運用・保守コストの低さとスムーズな容量拡張という中核的な利点を直感的に実証できます。

データのセキュリティのために、現在、マシンの 48 時間のローリング バックアップと、会社の Liu Bei バックアップ (毎日スケジュールされたディレクトリ バックアップを備えたシステム) に基づくバックアップを実行しています。監視については、現在、スタンドアロン バックアップと MiG 監視アラームを監視するアクセス権があります。

4. コーデスのアーキテクチャ設計

4.1 Codisの全体的なアーキテクチャ設計

codis公式サイト

[図 codis アーキテクチャ図]

上図に示すように、Codis はプロキシ + ストレージの 2 層アーキテクチャです。 CKV + プロキシなしの設計と比較すると、全体的な設計は比較的シンプルです。同時に、クライアント接続データが徐々に増加した場合、データ層のコピーを拡張する必要はなく、プロキシ層のみを拡張すればよいことになります。この観点から見ると、コストは低くなります。ただし、接続数が多くない場合は別途プロキシを導入する必要があります。この観点から見ると、コストは高くなります。

このうち、オープンソースの codisproxy サービスの登録と検出は zk を通じて実装されており、部門では現在 l5 をベースに行っています。

全体的なアーキテクチャ設計図から、codis の全体的なアーキテクチャは比較的明確です。その中でも、codisproxy は分散ソリューション設計の中核部分です。ストレージ ルーティングとシャード移行は、codisproxy と切り離せません。 codisproxy の設計と実装を見てみましょう。

4.2 Codisproxyのアーキテクチャ設計と実装

codisproxy のアーキテクチャ実装は、4.2.1 のルート マッピングの詳細と 4.2.2 のプロキシ要求処理の詳細の 2 つの部分に分かれています。

4.2.1 ルートマッピングの詳細

下の図に示すように、この部分は主に codis のルーティングの詳細に関係し、主にキーを特定の物理ノードにマップする方法に関係します。

[図] ルートマッピングの詳細

上の図に示すように、この部分には主に codis のルーティングの詳細が含まれます。

|関連語彙の説明

slot: シャード情報。Redis ではシャード インデックスを表す単なる数字です。各シャードは特定の Redis インスタンスに属します。

グループ: 主に仮想ノードであり、複数の Redis マシンで構成され、1 つのマスターと複数のスレーブのモデルを形成し、論理的な意味でのノードです。

プロキシ ルート マッピングの詳細をより深く理解できるように、ルート マッピングに関連する一般的な問題をいくつか整理しました。

質問 1: プロキシはどのようにしてリクエストを特定の Redis インスタンスにマッピングするのでしょうか?

Codis は、CRC32 アルゴリズムに基づいて対応するスロットを取得します。スロットはいわゆる論理シャードです。同時に、Codis は対応する論理シャードを対応する仮想ノードにマップします。各仮想ノードは、1 つのマスター Redis ノードと複数のスレーブ物理 Redis ノードで構成されます。 crc32 が使用される理由については、詳細には研究されていません。著者もredisclusterでの実装に基づいてこれを紹介しました。論理ストレージノードグループを導入することで、基盤となるホストマシンインスタンスが変更されても上位層マッピングデータはマッピングされないため、上位層マッピングが透過的になり、シャードの管理が容易になります。

質問 2: プロキシはどのようにして読み取りと書き込みの分離を実現するのでしょうか?

上図に示すように、キーを特定の仮想ノードにマッピングすると、その仮想ノードに対応するマスターインスタンスとスレーブインスタンスを感知することができます。このとき、redisproxy レイヤーは特定の redis コマンドを識別し、対応するコマンドを読み取りおよび書き込みとして取得できます。次に、クラスター構成が読み取り/書き込み分離機能をサポートしているかどうかに応じて、構成がサポートしている場合は、マスターインスタンスとスレーブインスタンスにランダムにルーティングします。構成がサポートしていない場合は、完了のためにホストにルーティングされます。

質問 3: プロキシは現在どのようなコマンドをサポートしていますか?バッチコマンドをサポートしていますか?アトミック性を確保するにはどうすればよいでしょうか?

コマンドサポートリンク

コマンドサポート部分: Proxoy でサポートされるコマンドには、サポートされていないコマンド、半サポートされているコマンド、サポートされているコマンドの 3 種類があります。上記の表に示されているコマンド以外にも、プロキシは他のコマンドをサポートしています。サポートされていないコマンドの主な原因は、コマンド パラメータにキーがないため、ルーティング情報を識別できず、どのインスタンスにルーティングするかが不明であることです。準サポートされているコマンドは通常、複数のキーを操作します。 Codis は、最初のキーのルーティングに基づいたシンプルな実装に基づいています。したがって、ビジネス側は複数のキーを同じスロットにルーティングしておく必要があります。もちろん、事業者側もそれを保証することはできず、具体的な結果は事業者側が負担することになります。これは弱い検証モードであり、企業レベルの製品であるckv+は、複数のキー操作に対する強力な検証です。複数のキーが同じスロットにない場合は、エラーの形で返されます。

マルチキー操作とアトミック性: Redis 自体は、mset やその他のコマンドなどの一部のマルチキー操作に対してアトミックです。ただし、分散操作では、複数のキーが複数の Redis インスタンスに分散され、分散トランザクションが発生するため、Codis では簡略化され、複数キー操作は複数の単一キー コマンド操作に分割されます。したがって、Codis の mset マルチキー操作にはアトミック セマンティクスがありません。

質問4: 複数のキーが1つのスロットにあることを確認する方法

シナリオによっては、操作のアトミック性を確保するために、Lua または一部の半サポートされているコマンドを使用する必要があります。したがって、ビジネス レベルで複数のキーが 1 つのスロットにあることを確認する必要があります。 Codis はハッシュタグに基づいて、RedisCluster と同じモデルを使用します。たとえば、7 日間のアンカー リストを同じスロットにルーティングする場合、{anchor_rank}day1、{anchor_rank}day2、{anchor_rank}day3 をサポートできます。つまり、中括弧モデルが使用されます。 Codis は中括弧を認識し、ハッシュ操作では中括弧内の文字列のみを取得します。

4.2.2 プロキシリクエスト処理の詳細

下の図に示すように、この部分は主にプロキシの処理の詳細に関係し、要求を受け入れて戻りパケットに応答する方法のプロセスに関係します。

[図] プロキシリクエスト処理の詳細

上の図に示すように、この部分は主にプロキシの処理の詳細に関係します。

Codisproxy は主に、言語レベルでコルーチンを自然にサポートする言語である Go 言語に基づいて実装されています。

1) プロキシはクライアントの接続を受信すると、新しいセッションを作成し、そのセッションでリーダー コルーチンとライター コルーチンを開始します。リーダーは主に、クライアントのリクエスト データを受信して​​解析し、マルチキー シナリオでコマンドを分割し、ルーターを介して特定の Redis インスタンスにリクエストを配布し、Redis によって処理されたデータをチャネルに書き込むために使用されます。ライターはチャネルから対応する結果を受信し、それをクライアントに書き戻します。

2) ルータ層は主にCRCコマンドを通じてキーに対応するルーティング情報を取得します。ソースコードから、codis が実際にサポートしているハッシュタグの特性を確認できます。

この時点で、プロキシ関連のルート マッピングと要求処理の詳細が完了しました。全体的にとてもシンプルですよね？

5. データの信頼性、高可用性、災害復旧、フェイルオーバー、スプリットブレイン処理

ストレージ層として、データの信頼性とサービスの高可用性は安定性の中核的な指標であり、上位層のコア サービスの安定性に直接影響します。このセクションでは主にこれら 2 つの指標について説明します。

5.1 データの信頼性

codis の実装に関しては、高いデータ信頼性は主に redis 自体の能力です。通常、ストレージ層の高いデータ信頼性は、主に単一マシンデータの高信頼性 + リモートデータのホットバックアップ + 定期的なコールドバックアップアーカイブによって実現されます。

単一マシン データの高い信頼性は、主に Redis 自体の永続性機能、RDB モード (定期的な DUM)、および AOF モード (実行ログ) に依存します。これを理解するには、前の記事で紹介した 2 冊の本を参照してください。 AOF モードはより安全です。現在、AOF スイッチもオンラインでオンにしていますが、これについては記事の最後で詳しく説明します。

リモート データのホット バックアップは主に、Redis 自体のマスター スレーブ同期機能、完全同期と増分同期の実装に依存しており、Redis はリモート ホット バックアップの機能を備えています。

定期的なコールド バックアップ アーカイブ。データ操作における人為的ミス、コンピュータ室のネットワーク障害、ストレージサービス運用中のハードウェア障害などによりデータ損失が発生する可能性があるため、何らかのバックアップ計画が必要です。現在、当社では主に単一マシンのローリング バックアップを使用して過去 48 時間のデータをバックアップし、SNG の Liu Bei システムを使用してコールド バックアップを行い、予期しない問題によるデータ損失を防ぎ、迅速な復旧を可能にしています。

5.2 高可用性、災害復旧、フェイルオーバー

Codis 自体のアーキテクチャは、プロキシ クラスター + Redis クラスターに分かれています。プロキシ クラスターの高可用性はフェイルオーバー用の ZK または L5 をベースにすることができますが、Redis クラスターの高可用性は Redis オープン ソース Sentinel クラスターの助けを借りて実現されます。 Codis は、Redis 以外のコンポーネントとして、Redis Sentinel クラスターをどのように統合するかという問題を解決する必要があります。このセクションでは、問題を 3 つの部分に分割し、Redis Sentinel クラスターが Redis の高可用性を保証する方法、CodisProxy が Redis Sentinel クラスターのフェイルオーバー アクションを認識する方法、および Redis クラスターが「ブレイン スプリット」の可能性を減らす方法について説明します。

5.2.1 Sentinel クラスターはどのようにして Redis の高可用性を確保するのでしょうか?

Sentinel は Redis の高可用性ソリューションです。1 つ以上の Sentinel インスタンスで構成される Sentinel システムは、任意の数のマスター サーバーとこれらのマスター サーバーの下にあるすべてのスレーブ サーバーを監視できます。監視対象のマスター サーバーがオフラインになると、オフラインのマスター サーバーの下にあるスレーブ サーバーが新しいマスター サーバーに自動的にアップグレードされ、その後、マスター サーバーがオフラインのマスター サーバーを置き換えてコマンド要求の処理を続行します。

一般的に、サービスの高可用性を実現するには、障害検出とフェイルオーバー（マスターの選択とマスターとスレーブの切り替え）という 2 つのことを行う必要があります。

5.2.2 Codis は Sentinel クラスターのフェイルオーバー アクションをどのように認識しますか?

Codis 自体のアーキテクチャは、プロキシ クラスター + Redis クラスターに分かれています。 Redis クラスターの高可用性は、Sentinel クラスターによって保証されます。では、プロキシはどのようにして Redis ホストの障害を認識し、新しいマスターに切り替えてサービスの高可用性を確保するのでしょうか?

上の図に示すように、プロキシ自体はセンチネル クラスターの +switch-master イベントをリッスンします。このイベントが発行された場合、Redis クラスター ホストに問題があることを意味します。センチネル クラスターはホストの選択と切り替えを開始します。プロキシは、センチネルのマスター/スレーブ切り替えイベントをリッスンします。マスター/スレーブ切り替えイベントを受信すると、プロキシは、すべてのセンチネル上のクラスターによって認識されている現在のホストを引き出し、センチネルの半数以上によって現在のクラスター ホストとして認識されているホストを選択するアクションを実行します。

この時点で、構成の保存という問題を見落とす可能性があります。構成センターのストレージは、まだ古いホストのままです。プロキシが再起動されると、障害が発生したホストは引き続きプルされます。実際、ダッシュボードとプロキシは同じことを行います。マスタースレーブ切り替えイベントを受信すると、新しいマスターがストレージ（現在はzk）に保存されます。

5.2.3 スプリットブレイン処理

スプリット ブレイン クラスターのスプリット ブレインは通常、クラスター内の一部のノードが到達不能なために発生します。次のような状況が発生すると、分割された異なる小規模クラスターが自律的にマスター ノードを選択し、元のクラスターに同時に複数のマスター ノードが存在することになります。その結果、システムの混乱やデータの破損が発生します。

この問題に関しては、Simotang 氏がすでに大規模 Codis クラスターのガバナンスと実践について非常に詳しく説明しています。ここで簡単にお話させていただきます。 Redis クラスターは単純に多数決モードに依存することはできず、RedisMaster 自体は自身のヘルス ステータスを検出してダウングレードのアクションを実行しないため、マスターのヘルス ステータスに基づいてダウングレードを判断するための支援方法が必要です。具体的な実装は

1) デュアルアクティブダウングレードの確率により、クォーラムの判断がより厳しくなり、ホストのオフライン判断時間もより厳しくなります。大手オペレータの IDC をカバーするために 5 台のセンチネル マシンを導入しましたが、そのうち 4 台だけが、ホストがオフラインであると主観的に判断した場合にホストをオフラインにします。

2) 分離されたマスターがダウングレードされます。共有リソース判定方式に基づき、Redis サーバー上のエージェントは zk が正常かどうかを定期的かつ継続的に検出します。接続できない場合は、ダウングレード コマンドが Redis に送信され、読み取りおよび書き込みが不可能になり、一貫性を確保するために可用性が犠牲になります。

6. Codis 水平展開の詳細と移行例外の取り扱い

Codis は Redis の分散ソリューションであるため、Redis 単一ポイントの容量が不十分な場合は必然的に水平拡張の問題に直面します。このセクションでは、主に Codis の水平拡張と移行例外の詳細について説明します。 2つの質問から始めましょう。質問 1: 移行プロセス中に、移行されるキーの読み取りおよび書き込み要求をどのように処理しますか?質問 2: 移行プロセス中に例外 (障害やタイムアウトなど) を処理する方法。

6.1 Codisの拡張と移行の詳細

【図】移行プロセス

インパクト：

最初の段階での影響: 通知から通知が正常に完了するまで、プロキシの読み取りおよび書き込み要求がブロックされ、損失は発生せず、レイテンシが増加する (時間が非常に短く、通知は並列に送信され、プロキシ内のスロットステータスを一致させるためにステータスのみが変更される)

移行プロセス: 読み取り可能、移行中のバッチは書き込み不可、移行済みのバッチには2つのネットワークIOが関与

上図に示すように、Redis スムーズ移行プロセスは、主に移行準備、移行アクション、移行パフォーマンス保証の 3 つのポイントを実装します。

移行準備

主に、移行アクションが実行される前に、すべてのリクエストがルーティングの変更を認識できるため、1 段階の処理フローが存在します。ここでの実装は、すべてのプロキシに並列に送信することです。プロキシは対応するスロットに書き込みロックを追加するため、すべてのプロキシがダッシュボードに通知するまで、すべてのリクエストはキューに入れられます。プロキシロックが解除されました。このとき、リクエストの遅延は若干増加しますが、並列応答であるため、影響時間は非常に短く、ビューが若干揺れます。

移行アクション

これは主に、すべてのキーが移行されるまで、ダッシュボードによってバッチでトリガーされます。移行プロセス中、スロットのキーについては 2 つの状況が発生する可能性があります。1 つは新しい Redis インスタンス上のキー A であり、もう 1 つは古い Redis インスタンス上のキー B です。そのため、移行状態のスロットの場合、このスロットに送信されたすべてのコマンドは、redis でカスタマイズされたコマンド SLOTSMGRT-EXEC-WRAPPER によって処理されます。このコマンドは、3.2 ブランチに基づいて新しく追加されました。このコマンドは主に次のことを行います: 1) キーが存在するかどうかを判断します。存在するが移行バッチにない場合は、キーの実際のメソッドを直接呼び出します。存在するが移行バッチ内にある場合、読み取り操作は許可されますが、書き込み操作は許可されません。 2) キーが存在しない場合は、キーが新しいインスタンスに移行されているか、キーが存在しない可能性があるため、操作のために新しいインスタンスに移動するようにプロキシに通知します。

移行パフォーマンス

実際、Codis 2.x 以前の移行パフォーマンスは高くありませんでした。 3.x 以前のパフォーマンスは大幅に改善されました。他の zset 構造の移行には 10 秒以上しかかかりませんでしたが、元のモードでは 50 秒以上かかりました。具体的な理由は

パフォーマンスデータの移行

6.2 移行例外処理

また、これを読んで何か疑問があるかどうかは分かりませんが、Codis がそれらにどのように対処するか、特に複雑で不安定なネットワーク環境でどのように動作するかを確認するために、ここでいくつか質問を用意しました。

質問 1: 移行のために大きなキーを小さなバッチに分割します。バッチ移行が失敗したりタイムアウトになったりした場合はどうすればいいですか?

分散シナリオにおけるネットワーク呼び出しには、成功、失敗、タイムアウトの 3 つの状態があることがわかっています。失敗は大したことではありません。タイムアウトの場合、盲目的に再試行できますか?明らかにそうではありません。通常、データ レベルでの再試行では、非常に重要な原則であるべき等性を確保する必要があります。ただし、Redis 構造では、zset、set、hash、および文字列構造を除き、再試行理論は影響を受けません。リストはどうですか?そのため、Codis はより暴力的な方法を使用します。バッチ移行が正常に再試行されると、再試行前にターゲット ノードがキーを削除できるように、最初に del コマンドが実行されます。

質問 2: 有効期限のあるキーの移行中、データを転送する前にターゲット ノードで有効期限を設定する必要がありますか、それとも最初にデータを転送してから有効期限を設定する必要がありますか?

まず、データを送信する前にターゲット ノードに有効期限を設定する問題を見てみましょう。マシン B のキーが送信の途中で期限切れになった場合、後続のキーには有効期限がありません。期待に応えられなかった

最初にデータを転送してから有効期限を設定するという問題を見てみましょう。Acrash が転送の途中で再起動し、この時点でキーの有効期限が切れると、データはマシン B に落ちてゾンビ データになり、期待どおりになりません。それで、Codis はそれをどのように行うのでしょうか?

移行例外が発生した場合に、移行プロセス中のシャードが自動的に破棄されるようにするために、シャードが転送されるたびにキーの有効期限が 90 秒 (タイムアウト時間の 30 秒より大きい) にリセットされ、キーの移行が完了した後に実際の有効期限にリセットされます。この方法では、移行プロセス中にクラッシュ、キーの有効期限切れ、またはその他の例外が発生した場合でも、シャード データはターゲット ノード上で 90 秒間のみ存続し、その後破棄されます。

質問 3: 移行プロセス中にクラッシュします。現時点では、対応するシャード データの半分が A にあり、残りの半分が B にあります。どうすればよいでしょうか?

川沿いを頻繁に歩くと、必ず怪我をします。有効期限移行の不適切な実装が原因で、Codis で悲惨な事件が発生しました。幸いなことに、それはテスト環境で発生しました。この時点では、A をプルアップしないでください。A に古いデータが存在する可能性があり、移行されたキーが再移行され、B のデータが失われる可能性があるためです。正しい方法は、A のバックアップ マシンを使用して移行を続行することです。 A のバックアップ マシンは非同期で複製されますが、基本的には A の完全なデータに近いため、問題はそれほど大きくありません。ただし、すべての移行プロセス中、データの損失を防ぐために、データとシャード情報をバックアップする必要があります。この時点では、B のデータを A に移行しないでください。移行されたデータの一部が B に残り、A の完全なデータが上書きされる可能性があるためです。

質問 4: パフォーマンス上の理由から、A をバックアップ マシンとして使用せず、AOF と RDB を有効にしないことはできませんか?

これも絶対に許可されていません。A がクラッシュして Zhiyun によって引き上げられた場合、空のインスタンスと同等になり、バックアップ マシンのデータがクリアされ、データ損失が発生するためです。

7. Codis関連データ

ストレステスト環境: ストレステストサーバー (v4-8-100) + プロキシ (v4-8-100) + redis (B5 (4 -32-100))

上の図からわかるように、一度に取得されるデータの量が増えると、プロキシのパフォーマンスは急速に低下します。たとえば、ZRANGE_500 の直接接続のパフォーマンスはプロキシの 2 倍です。

8. 操作・保守マニュアルと落とし穴回避ガイド

操作メモ:

8.1 マスターとスレーブの切り替え: マスターとスレーブを切り替えるたびに、切り替えたマスターまたはバックアップ マシン上の conf ファイルが書き換えられていることを確認します。

grep "CONFIG REWRITEによって生成された" -C 10 {redis_confパス}/*.conf

8.2 データの移行: 重要な操作を行う前に、データをバックアップします。スライス情報が関係する場合は、スライス情報をバックアップします。

A から B への移行時間が長すぎる場合は、コマンドを確認してください。Acodisserver に接続し、コマンドラインで slotsmgrt-async-status を実行して、移行中のシャードの情報 (特に大きなキー) を表示し、状況を明確に把握します。 ***その他のキーは約20秒で移行できます

8.3 例外処理: Redisがクラッシュして再起動した後、再起動後にキーがほぼロードされると、ページにエラーが報告されます。

8.4 クライアントのタイムアウトが多発する

8.5 フォークには長い時間がかかる

8.6 AOF永続性の詳細

一般的に使用されるハードディスク同期戦略は everysec であり、パフォーマンスとデータ セキュリティのバランスを取るために使用されます。この方法では、Redis は別のスレッドを使用して、ハードディスクとの fsync 同期を毎秒実行します。システムのハードディスク リソースがビジー状態の場合、Redis メイン スレッドはブロックされます。

8.7 誤ってflushdbを実行してしまった

appendonlyno が設定されている場合は、すぐに rdb トリガー パラメータを増やしてから、rdb ファイルをバックアップします。バックアップが失敗した場合は、すぐに逃げてください。 appedonlyyes が設定されている場合は、AOF 書き換えパラメータ auto-aof-rewrite-percentage および auto-aof-rewrite-minsize を増やすか、プロセスを直接強制終了して、Redis が AOF を自動的に書き換えないようにすることができます。 · 手動の bgrewriteaof を拒否します。 aof ファイルをバックアップし、バックアップした aof ファイルに記述されている flushdb コマンドを削除してから復元します。復元が不可能な場合は、コールド バックアップを使用します。

8.8 オンライン Redis は RDB モードを Aof モードに変更しようとします

confを直接変更せずに再起動してください

正しい方法: rdb ファイルをバックアップし、configset で aof を開き、configrewrite で構成を書き戻し、bgrewriteof を実行し、メモリ データをファイルにバックアップします。

IX.参考文献

Redisの開発と運用と保守（Fu Lei）

Redis の設計と実践 (Huang Jianhong)

大規模 Codis クラスターのガバナンスと実践

[この記事は51CTOコラムニスト「Tencent Technology Engineering」によるオリジナル記事です。転載については原作者（WeChat ID: Tencent_TEG）までご連絡ください。

この著者の他の記事を読むにはここをクリックしてください