現象記述
現象1：出流量指標が上限に達しました。ユーザーは出流量の制限によってトリガーされたアラートのメッセージを受信しました。
現象2：応答遅延が大きくなります。
考えられる原因
大きなKeyによって引き起こされます。
リクエストされたKeyのValue値が大きい場合、出流量が高くなりやすい問題が発生します。
pipelinesリクエスト。
Pipeline技術は、複数回のリクエストを1回のリクエストにまとめてデータベースサーバーに送信して処理し、すべてのコマンド実行結果を受信した後に上位ビジネスに返します。1回のリクエストが多い場合、出流量が高くなります。詳細については、Redis pipelineを参照してください。 バッチクエリ、例えば：mget、hmget、またはhgetallなど。
1回のバッチクエリで取得するKeyの数が多いと、出流量が高くなります。
インスタンス設定のスペックが不足しています。
ビジネス量が増加し、データ量が大きくなり、インスタンスのクォータ出流量が上限に達したため、現在のビジネストラフィック要件を満たせません。
解決方法
ステップ1：大きいKey問題の調査
2. 大Keyが存在する場合、業務に影響を与えないことを前提に、大Keyへのアクセスを減らします。valueが大きすぎる場合は、オブジェクトを複数のkey-valueに分割し、操作の負荷を複数のRedisインスタンスに分散できます。Keyが多すぎる場合は、hash構造を参考に保存し、複数のKeyを1つのhash構造に保存できます。
説明：
大Keyの発生を防ぐために、Valueを設計する際は、以下の推奨事項を参考にすることをお勧めします。
String型は10KB以内に制御し、hash、list、set、zsetの要素数は5000を超えないようにすることをお勧めします。
非文字列の大Keyについては、hscan、sscan、zscanを使用した段階的な削除をお勧めします。
ステップ2：ビジネスでのpipelines使用有無の確認
業務コードのロジックを調査し、pipelineを使用しないか、毎回のpipelinesにおけるコマンドリクエスト数を減らすことをお勧めします。確認できない場合は、チケットを発行してTencent Cloud Assistantに連絡し、調査を依頼してください。 ステップ3：単一クエリにおけるKey数の調査
通常、1回の操作におけるKeyの数または要素数のサイズは50個を超えないことをお勧めします。valueが大きい場合は、さらに減らす必要があります。
ステップ4：インスタンス规格のアップグレード
1. レプリカ数を増やし、レプリカ読み取り専用を有効にして、読み取り負荷を分散し、現在のインスタンスの読み取りリクエストをレプリカ読み取り専用ノードに移行することで、読み取り能力の弾力的な拡張を実現し、ネットワークトラフィック性能の問題を改善します。具体的な操作については、読み書き分離の切り替えを参照してください。 ステップ5：帯域幅の調整
インスタンスの仕様をアップグレードした後も、出力トラフィックが依然として高い場合は、帯域幅を最大に調整します。帯域幅の増加は現在無料です。具体的な操作については、帯域幅調整を参照してください。