著者: ヒマラヤ東道光
宣言:キャッシュは万能薬でもゴミ箱でもありません。！！
Ximalaya の最も重要な基本コンポーネントの 1 つであるキャッシュは、毎日大量のビジネス リクエストを運びます。キャッシュに障害が発生すると、ビジネスへの影響は非常に深刻になります。したがって、キャッシュ サービスの安定的かつ効率的な運用を確保することは、当社にとって常に重要な目標です。
以下は、Xima キャッシュ障害の履歴を確認した後にまとめた一連のキャッシュ使用仕様です。これを皆さんと共有したいと思います。友人がキャッシュの選択と使用のプロセスで落とし穴を回避できることを願っています。
1. キャッシュの選択
1.1 キャッシュタイプの概要
Xima オンライン キャッシュには主に 4 つのタイプがあります。
1. Redis マスタースレーブモード：公式オリジナルバージョン
2. codis -redis : Wandoujia オープンソース、redis クラスター ソリューション
3. クラウド データベース Redis : redis-cluster コンテナーのデプロイメント
4.xcache : codis、pika、redis に基づく自社開発の大規模 KV ストレージ ソリューションのセット
1.2キャッシュ使用モデルの概要
主な使用モードは 2 つあります。
1. キャッシュ モード: データを永続化する必要がなく、インスタンスの回復でデータをロードする必要がなく、拡張と縮小でデータの移行が必要ありません。
2. ストア モード: データは永続化する必要があり、インスタンスの回復ではデータをロードする必要があり、拡張と縮小ではデータを移行する必要があります。
以下は、さまざまなタイプのキャッシュの簡単な比較です。
2. キャッシュの使用ルール
2.1 キャッシュタイプの使用仕様
1) Redis クラスター モードにはクラウド データベース Redis が推奨され、大規模な KV ストレージには xcache が推奨されます。
クラウド データベース Redis は、公式 Redis クラスター モード、コンテナー化されたデプロイメントを採用し、自動障害回復とエラスティック スケーリングをサポートし、現在の Redis クラスターの主要なソリューションです。ただし、データの永続化はサポートされていません。データの永続化が必要な場合、遅延が発生します。要件が非常に高い 高い場合は、codis redis を使用できます。データ量が非常に多く、レイテンシ要件が特に高くないため、xcache を選択できます。
2) Redis を db として使用しないでください。データを永続化する必要がある場合は、xcache を選択できます。
Redis を DB として使用すると、障害後のデータ回復が非常に遅くなり、SLA に重大な影響を及ぼします。また、マスターとスレーブがすべてハングアップしてスレーブ マシンが復元できない場合、データは完全に失われます。xcache はデータの永続化を自然にサポートします
3)クライアント側シャーディング モードを使用しないでください。
クライアント シャーディング モードには、高可用性と柔軟なスケーリング機能がありません。codis-redis、クラウド データベース Redis、xcache などのリアル クラスター モードを使用することをお勧めします。
4) クラスター モードは lua および redisson クライアントをサポートしていないため、ビジネスでクラスター モードを使用する必要がある場合は、redis マスター/スレーブ モードのみを選択できます。
5) Redis の単一ノードの容量は 10GB を超えてはならず、xcache の単一ノードの容量は 200GB を超えてはなりません。
単一の Redis ノードの容量が大きすぎる場合、インスタンスの再起動が遅くなり、回復時間に影響します。
2.2 Key Value の設計仕様
1) キーはできる限りシンプルで、読みやすく、管理しやすいものにする必要があります。
セマンティクスを確保することを前提として、キーの長さを制御します。ビジネス名 (またはデータベース名) をプレフィックスとして使用し (キーの競合を防ぐため)、ビジネス名: テーブル名: ID のようにコロンで区切ります。含めないでください。特殊文字
2) bigkey を拒否して、過剰なネットワーク カード トラフィックとクエリの遅延を防止します。
文字列タイプは 10KB 以内に制御され、hash、list、set、zset 要素の数は5000 を超えてはなりません。
3) ホットキーを避ける
ホット キーを使用すると、データ スキューが発生し、単一ノードに過剰な圧力がかかります。ビジネス側はホットキーを分散することをお勧めします。
4) 制御キーのライフサイクル
キャッシュはゴミ箱ではありません。キーの有効期限が集中的に失われるのを避けるために、すべてのキーに ttl を設定し、キーの ttl を分割することが最善です。
2.3 コマンド使用仕様
1) 完全な操作コマンドは慎重に使用してください
「keys *」コマンドを無効にし、hgetall、smembers、およびその他のコマンドを使用しないようにしてください。キーの下にある複数の要素を取得する場合は、対応するスキャン コマンドを使用して、一度に少数の要素を取得し、複数回に分けて取得します。一度にスキャンする要素は 200 個以下にすることをお勧めします。
2) mset、mget、hmset、hmget、*scan、*range などのコマンドの 1 回の操作で要素の数を制御します。200 を超えないようにすることをお勧めします。
3) パイプライン内のコマンドの数を制御します。100 を超えないようにすることをお勧めします。
4) redis でキーを削除する場合は、del コマンドを使用せず、unlink コマンドを使用してください。
大きなキーを削除すると、redis がスタックする直接的な原因となります。キーは unlink コマンドを使用して非同期的に削除できます。これはメインの Redis スレッドに影響を与えないため、ビジネス トラフィックには影響しません。
5) サーバーへの書き込み負荷を軽減するために、set コマンドとexpir コマンドが setex コマンドにマージされます。
6) eval の代わりに evalsha
redis-cluster クラスターで eval の代わりに evalsha を使用すると、ネットワーク IO が削減され、同時に Redis ネットワーク IO の 負荷も軽減され、パフォーマンスが向上します。
2.4 ビジネスキャッシュアーキテクチャの仕様
1) Redis には論理データベースを使用せず、デフォルトの db 0 のみを使用します。
インスタンスを介して分離することができ、異なる業務のデータを異なるインスタンスに保存することができます。(論理データベースを選択できるのは Redis マスターとスレーブのみです。クラスター モードはデフォルトで db0 を使用します)
2) 複数のサービスが同じキャッシュ リソースを再利用することを避ける
異なるサービスのデータには異なるクラスターを使用します。S レベルのアプリケーションと B レベルのアプリケーションを混合しないでください。同じリソースを再利用するサービスが多すぎる場合は、分割する必要があります。企業は、他の企業がデータ ソースに直接アクセスできるようにするのではなく (ある業務で書き込みと別の業務での読み取りなど)、他の企業が呼び出すための RPC インターフェイスを提供するよう最善を尽くす必要があります。
3) xcache は文字列型を使用しようとします
xcache は、string、hash、ehash、list、set、zset の 6 つのデータ型をサポートします。ehash データ型はハッシュ データ型の拡張であり、フィールドの有効期限の設定をサポートします。xcache の文字列型が最も高速ですが、その他のデータ型は文字列の組み合わせ変換によって実現され、6 種類のデータのパフォーマンスは次のとおりです。
文字列 > ハッシュ > セット > eハッシュ > リスト > zset
提案: 文字列型を使用してみてください
4) lua スクリプトの使用を減らす
クラスター モードには Lua サポートに関する制限があり、Lua で操作されるキーが同じノードにシャーディングされることを確認する必要があります。したがって、lua の使用をできるだけ減らすようにしてください。
5) Lua スクリプトでは複雑なロジックは実行されません
Lua スクリプトの代わりに複雑なロジックをビジネス コードに組み込む
6) 効率的なシリアル化方法と圧縮方法を使用する
メモリを節約するために、値が大きい場合は、圧縮ツール (snappy や gzip など) を使用してデータを圧縮し、それを Redis に書き込むことができます。
7) トラフィックが多すぎてオンライン ビジネスに影響を与えるバッチ タスク、スケジュールされたタスク、定期的なタスクを避ける
バッチタスク、スケジュールされたタスク、定期的なタスクには速度制限が必要です。
8) ビジネスの変更とストレージ トラフィック モデルの変更を最初に評価する必要がある
ビジネス モデルの変更、QPS、容量の増加、O (N) コマンドの増加などには、まず現在のキャッシュがそれに耐えられるかどうかを評価し、グレースケールでオンラインにし、監視を続ける必要があります (特にピーク トラフィック期間中) 。
9) 未利用資源のリサイクル申請は早めに行ってください。
休眠資源のリサイクルは、企業の保管コストを削減できるだけでなく、本当に必要な企業にリソースを割り当てることができるため、Win-Winの状況と言えます。
補足: OpenAtom オープンソース コンペティション Pika コンペティションの質問が公開されました。賞金 500,000 が付いています。 登録するには、次の QR コードをスキャンしてください。
また、 Pika アシスタントを追加して Pika WeChat グループに参加して、よりダイナミックなニュースを学ぶこともできます。
