Redis のキーと値の設計ではどのような方法が使用されますか?

Redis の使用における不規則な現象

• Redis に保存されるキー名は標準化されておらず、より恣意的です。

• Redis はリポジトリとして使用され、データ損失のリスクがあり、リロード計画はありません。

• Redis キャッシュ キー、有効期限なし時間が設定され、キャッシュが低頻度のデータを消費する 大量のメモリが使用されるため、サービスがクラッシュする;

• Redis は多数の大きなキーをキャッシュするため、アプリケーションの取得時に大量のネットワーク帯域幅を占有し、削除によっても簡単に輻輳が発生する可能性があります。

• Redis クライアントを不適切に使用すると、他のクライアントの接続タイムアウトが発生します。その理由としては、次のことが考えられます。クライアントのパスワードが正しくなく、接続プールが使用されていないこと。多数の接続再試行により、システム ポート リソースが枯渇してしまいます。

• Redis クライアント コマンドを不適切に使用すると、大量の遅いクエリが発生し、ビジネスのピーク時にキー* やフラッシュオール コマンドを使用するなど、他のアプリケーション サービスに影響を与える;

Redis 使用ビジネス シナリオの推奨事項と提案

• 高同時実行性のシナリオ: ホットスポット データ キャッシュにより、システム全体の応答速度が向上し、データベース IO の負荷が軽減されます。

• ##期間限定のシナリオ: Redis のexpired コマンドを使用してセッションの有効期限を設定します。

• Redis のリストと順序付きセットのデータ構造を使用すると、さまざまな複雑なランキング アプリケーションを実装できます

• データ セット操作: Redis リスト、セット、ソート セットを使用して、交差、和集合、差分などのデータ計算を容易にします;

• 継続的サインイン:サインイン関連サービスを実装するための Redis のビットマップ データ構造;

• Counter: Redis incr および incrby コマンドを使用して、API 呼び出し数統計、API 電流制限、およびその他のシナリオを実装します。

分散ロック: Redis の setnx 関数を使用して、分散ロック (redisson などの典型的なオープン ソース コンポーネント) を作成します。
エレガントなキーを設計する方法

オンラインでの Redis パフォーマンスの最適化に関しては、不合理なキー設計が問題の根本原因であることが多いと言えます。本質的に、私が個人的に見た限りでは、ほとんどの学生が Redis を使用する場合、ほとんどの場合、ほとんどの学生が使用するシナリオは key/val であり、対応するデータ構造は string key/string val であるため、キー設計の概念はありません。

Redis についてより深く理解している学生は、キー設計が次のとおりであることを知っているかもしれません。格納するときはできるだけ短くし、途中で階層感を持たせるのがベストです。...

それでは、どうすればよりエレガントなキーを設計できるでしょうか?エディターの実際の使用経験と遭遇した落とし穴に基づいて詳しく説明します。

1. 次のベスト プラクティス規則に従ってください。

次のベスト プラクティスに従ってください。基本形式: [ビジネス名]:[データ名]:[id];
キーの長さは 44 バイトを超えてはなりません;
いいえ 特殊文字が含まれています;
上記の提案に関して、これには次の利点があります:

次のような場合に可読性が高くなります。 order:user:10 というようなキー構造を設計します。一目でユーザーの注文に関係するキーであることが分かりますが、
は保守管理に便利ですが、異なるプレフィックスを使用すると、ビジュアル クライアント ツールやコマンド ラインでキーを簡単に見つけて見つけることができます;
キーの競合を回避し、使用中に複数のユーザーが userId を使用することを回避します。キーとしての値によって引き起こされる競合;
文字列型をキーとして使用し、基になるエンコーディングに int、embstr、および raw が含まれるため、メモリ使用量を効果的に削減できます。 embstr を使用すると、連続メモリ空間を使用するため、より少ないメモリ使用量で 44 バイト未満の文字列を処理できます。

推奨値:

単一キーの値は 10KB 未満です;
コレクション型キーの場合、要素の数は 1000 未満であることをお勧めします;
2. bigkey は避けるようにしてください

1. bigkey とは

BigKey は通常、Key のサイズとキーの数に基づいて総合的に判断されます。キー内のメンバー、例:

キー自体のデータ量が大きすぎます: 文字列型のキー、その値は 5 MB;
Members in Key 数が多すぎます: ZSET タイプのキー、メンバー数は 10,000 です;
キーのメンバー数が多すぎます: ハッシュ タイプのキー、メンバーの数は 1,000 しかありませんが、これらのメンバーの値の合計サイズは 100 MB です;

2. BigKey の危険性

ネットワーク ブロッキング

BigKey の読み取りリクエストを実行すると、少量の QPS によって帯域幅の使用量がいっぱいになり、Redis インスタンスと物理マシンが配置されている場合でも速度が低下します。

データ スキュー

#Redis のメモリ使用量BigKey が配置されているインスタンスは他のインスタンスよりもはるかに高いため、データ シャーディングのメモリ リソースに到達できません。バランス;
#Redis ブロッキング

• 多くの要素を含むハッシュ、リスト、zset などの計算には時間がかかり、メイン スレッドがブロックされる原因になります;

CPU プレッシャー

• #BigKey のデータのシリアル化と逆シリアル化により CPU 使用率が急増し、Redis インスタンスやその他のローカル アプリケーションに影響を及ぼします。

##3. BigKey を検出する方法

インストールされたマシンで redis-cli --bigkeys コマンドを実行します

使用方法redis-cli によって提供される --bigkeys パラメーターを使用すると、すべてのキーを走査して分析し、キーの全体的な統計情報と各データの上位 1 つの大きなキーを返すことができます。
• scan によるスキャン

プログラムを作成し、scan を使用して Redis 内のすべてのキーをスキャンし、strlen、hlen およびその他のコマンドを使用してキーの長さを決定します ( MEMORY USAGE はここでは推奨されません) );

• サードパーティ ツールを使用します

サードパーティ ツールを使用します。 RDB スナップショット ファイルを分析してメモリ使用量を包括的に分析する Redis-Rdb-Tools など。

• #ネットワーク監視を使用する

# #Redis Data の内外のネットワークを監視するカスタム ツールは、警告値を超えた場合に積極的に警告します;

3. 適切なデータ型を使用します

• 前述のとおり初めて Redis を使用する多くの学生は、多くのビジネス シナリオを抱えています。すべてが key/val の単純な構造で行われ、そうすることが合理的かどうか、または関連するパフォーマンス上の問題が発生するかどうかについて深く考える必要はありません。将来;
  この問題については、基本的に、一般的に使用される Redis のデータ型を深く理解し、習得する必要があり、これに基づいて、さまざまなビジネス シナリオに合わせて効率的なストレージ構造データを設計できます。
#キャッシュする方法を考えてみましょう。ユーザー オブジェクトのリストなどのデータはどうでしょうか。

オプション 1: キーは usrId、値はオブジェクトのシリアル化された文字列で、データ構造は次のようになります;

• 利点: アクセスが便利、シンプルかつ大まか、アクセス時に json とオブジェクトを変換するだけで済みます;
  欠点: データ結合、オブジェクトが新しいフィールドを追加すると柔軟性が不十分またはフィールドが削除され、キャッシュ再構築のコストが非常に高くなります;

オプション 2: リスト構造を使用してユーザー ID リストをキャッシュします。データ構造は次のとおりです。

• 利点: メモリ使用量が少なく、効率的な操作;
  欠点: val を取得した後、完全なデータを取得するにはさらにデータベースを検索する必要があります。オブジェクト;

オプション 3: ハッシュ構造を使用し、オブジェクトをキャッシュし、データは次のとおりです;

利点: 最下層は ziplist を使用します。スペースがほとんどなく、オブジェクトの任意のフィールドに柔軟にアクセスできます。;

欠点: コーディングが比較的複雑;

#実際のアプリケーションで Redis キャッシュを使用するための推奨事項

[推奨] キャッシュをウォームアップします。データにアクセスする前に、大量のリクエストがデータ ストレージ レイヤーに直接入るのを避けるためにキャッシュを予熱する必要があります。ビジネス状況に応じて適切なホット データとコールド データを分割し、ホット データを予熱する必要があります。認可情報やAPIKEYなど;

[推奨]ローカルキャッシュを併用する。分散アーキテクチャでは、ローカル キャッシュによりデータ アクセスの安定性と速度が向上しますが、ステートフル サーバー ノードの導入を避けるために注意して使用する必要があります。ローカル キャッシュがアプリケーション サーバーのリソースを過度に占有し、アプリケーション ノードのクラッシュを引き起こすことを回避します。

• [推奨] キャッシュ変更戦略。最初にデータベースを更新し、次にキャッシュを更新する必要があります。

• [推奨事項] ビジネス コールでは複数の Redis サーバーにアクセスする必要があり、パイプラインまたはその他のバッチ操作方法を使用できます。

• [推奨事項] 大きなリスト、セット、ハッシュ、ストレージ量が膨大です。多数の要素をフェッチすると、大きな遅延が発生し、他のコマンドの実行がブロックされます。複数の小さなリスト、セット、またはハッシュ テーブルに分割することをお勧めします。

• ビジネス仕様を使用します。
  開発で使用されるのが Redis であっても、その他の中間物であっても、開発および使用するときは、ソフトウェアを使用する場合、事前に一連の合理的な仕様を策定することが最善です。この仕様はほとんどの開発者によって認識され、実際にテストされるべきであり、いくつかの問題を効果的に回避できます。仕様として指定されたら、社内の指針となる日常的なルールになるはずです。

• Redis はキャッシュ データとして位置付けられるべきであり、大規模なデータの保存には使用できません (データベースを置き換えることはできません);

Redis は、読み取りが多く書き込みが少ないシナリオに適しています。書き込み頻度が高く、クエリ頻度が低い場合は、お勧めできません。

• キーが不明な場合 存続期間に関しては、有効期限を設定してキーのライフサイクルを制御するのが最善です;

• ホット データとコールド データの分離を考慮する必要があります。クエリについては、高頻度のビジネス クエリには Redis を使用し、低頻度のクエリにはデータベースの使用を検討してください。

• プログラムがデータを処理する場合、Redis にはデータ損失のリスクがあることを考慮する必要があるため、失われたデータをデータベースから Redis に自動的にロードしてキャッシュする必要があります。 #list、set、hash データなどの O(N) コマンドは注意して使用してください 構造体演算を行う場合、hgetall、lrange、smembers、zrange などが使用できないわけではありませんが、hscan、sscan、zscan の使用が優先されます。

以上がRedis のキーと値の設計ではどのような方法が使用されますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。