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

概要: NoSQL の KV データベースの王様である Redis は、その高いパフォーマンス、低レイテンシ、豊富なデータ構造により開発者に好まれています。しかし、Redis の水平スケーラビリティは限られているため、ビジネスに支障をきたすことなく水平拡張を実現する方法は、Redis を使用する多くの開発者が直面する問題です。 Redis 分散ソリューション [codis] のオープンソース製品がこの弱点を補います。

この記事では主に、Codis がビジネス非依存、スムーズな移行、高い移行パフォーマンス、移行例外処理、高可用性を実現する方法と、Redis の一般的な落とし穴を回避するためのガイドについて説明します。 Codis は、同社の NoSQL 製品がますます成熟するにつれてライフサイクルを終了しようとしていますが、多くの学生が依然として Codis の原理に興味を持っていることを考慮して、以前に共有されたコンテンツが再編成されています。もちろん、Codis は社外でも比較的広く使用されています。

1. 背景

生放送元年を迎え、春雨後の竹の子のように生放送作品が次々と登場しています。製品は収益を上げる過程で、ユーザーの消費欲求を刺激するためのさまざまな活動を考えようと全力を尽くしてきましたが、そのような活動の基本的な形はリストです。 2016 年には、cmem とスキャンフローテーブルに基づくリストランキングを実装しました。 2017 年から、元のシステムを再構築し、リストの基本的なストレージとして Redis を使用するようになりました。再構築の過程で、私たちはRedis分散ソリューションを調査するという任務を受け、業界のさまざまなオープンソース製品を比較し、最終的にCodisに決定し、詳細について調査を行いました。

Codis の作者とのコミュニケーションの中で、付加価値製品部門の Simotang が 2 年近くにわたって部門に Codis を導入していたことを知り、Codis の運用と保守に加わりました。現在、部門内には 2T 容量の Codis クラスターが 15 セット導入・保守されており、1 日の総訪問数は 100 億を超えています。インタラクティブビデオ製品部門の基盤ストレージ、運用活動、リスト関連業務を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の特徴

シングルスレッドの非同期アーキテクチャ (シングルスレッド、パケットの受信、パケットの送信、解析、実行、ファイルイベントを受信するための IO の多重化)
kv 構造、値は豊富なデータ構造 (文字列、ハッシュ、リスト、セット、ソートセット) をサポートします。
高性能、低レイテンシ、メモリベースの操作、Get/Set10w+、高性能、RDB ベース、データの信頼性を確保するための AOF 実装
豊富な機能、キャッシュ、メッセージキュー、TTL有効期限に使用可能
トランザクションをサポートし、操作はアトミックであり、すべてがコミットされるか、まったくコミットされないかのいずれかになります。

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

2.4 序文: codis と redis の関係

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

2.5 Redis学習教材

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

Redisの開発と運用と保守（Fu Lei）
Redis の設計と実践 (Huang Jianhong) (2 回読む価値あり)

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

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

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

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

【外部部品の比較】

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

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

4. Codisのアーキテクチャ設計

4.1 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 : プロキシはどのようにしてリクエストを特定の 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 構造を移行するには、元のモードでは 50 秒以上かかりますが、このモードでは 10 秒以上しかかかりません。具体的な理由は

6.2 移行例外処理

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

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

分散シナリオにおけるネットワーク呼び出しには、成功、失敗、タイムアウトの 3 つの状態があることがわかっています。失敗は大したことではありませんが、タイムアウトの場合は盲目的に再試行できますか?明らかにそうではありません。通常、データレベルでの再試行では、非常に重要な原則であるべき等性を確保する必要があります。ただし、zset、set、hash、および文字列構造を除く Redis 構造では、再試行理論は影響を受けません。リストはどうですか?そのため、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 "Generatedby CONFIG REWRITE" -C 10 {redis_conf路径}/*.conf

8.2 データの移行

重要な操作を実行する前に、データをバックアップしてください。スライス情報が関係する場合は、スライス情報をバックアップします。

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

8.3 例外処理

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

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

ネットワークの理由: NOC スマートアシスタントに連絡して、リンクネットワークが混雑していないかどうかを確認します。
ビューを観察して、リスニングキューがオーバーフローしていないか確認します。
完全な接続キューのサイズは、 min(backlog, somaxconn) によって決まります。バックログはソケットの作成時に渡されます。 Somaxconn は OS レベルのシステムパラメーターです。コマンド ss -lnt に基づいて、リスニングキューの現在の長さが予想と一致しているかどうかを確認します。
パラメータを調整します: vim /etc/sysctl.conf net.core.somaxconn=1024 sysctl -p
低速クエリ slowlogget は、時間のかかる操作を実行する必要があるかどうかを確認します。現在のネットワークのデフォルト値は10msです

slowlog-log-slower-than と slowlog-max-len

注: 遅いクエリには、リクエストのキューイング時間は含まれず、リクエストの実行時間のみが含まれます。したがって、問題は Redis 自体のキューイングによって発生している可能性がありますが、遅いクエリでは検出されない可能性があります。

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

理由：
1) Redis が RDB または AOF を書き換える場合、重要な操作はフォーク操作を実行して子プロセスを作成することです。 fork によって作成された子プロセスは親プロセスの物理メモリ空間をコピーする必要はありませんが、親プロセスの空間メモリページテーブルをコピーします。 info stats 統計の latest_fork_usec インジケーターをチェックすると、最新のフォーク操作にかかった時間をマイクロ秒単位で取得できます。

改善する：

フォーク操作を効率的にサポートする物理マシンまたは仮想化テクノロジの使用を優先します。
単一の Redis インスタンスのメモリサイズを制御します。
フォーク時間はメモリの量に比例します。各 Redis インスタンスのメモリを 10 GB 以内に制御することをお勧めします。
AOF 書き換えトリガーのタイミングを適度に緩和します。現在のオンライン構成は次のとおりです。
自動 aof 書き換え率が 100% 増加しました

サブプロセスのオーバーヘッドと監視および最適化

CPU

過度の CPU 競合を避けるため、他の CPU を集中的に使用するサービスと一緒に展開しないでください。
複数の Redis インスタンスをデプロイする場合は、同時に 1 つの子プロセスのみが書き換え作業を実行するようにしてください。
1Gメモリのフォーク時間は約20ms

メモリ
背景: 子プロセスはフォーク操作によって生成され、親プロセスと同じメモリサイズを占有します。理論上は、永続化操作を完了するには 2 倍のメモリが必要になりますが、Linux にはコピーオンライトメカニズムがあります。親プロセスと子プロセスは同じ物理メモリページを共有します。親プロセスが書き込み要求を処理すると、変更するページのコピーが作成され、子プロセスはフォーク操作中に親プロセスのメモリスナップショット全体を共有します。

フォークメモリ消費関連のログ: AOF 書き換え: コピーオンライトで 53 MB のメモリが使用、RDB: コピーオンライトで 5 MB のメモリが使用

巨大ページをオフにしてからオンにすると、コピーページ単位が4KBから2MBに変わり、フォークの負担が増加し、書き込み操作の実行時間が遅くなり、書き込み操作の数が多くなり、クエリが遅くなります。

"sudo echo never>/sys/kernel/mm/transparent_hugepage/enabled

ハードディスク
ディスク負荷が高い他のサービスと一緒に展開しないでください。例: ストレージサービス、メッセージキュー

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 コマンドを削除してから復元します。復元が不可能な場合は、コールドバックアップを使用します。