Redis キャッシュの故障が発生した場合の対処方法

分散キャッシュは、Web サイト サーバーでよく使用されるテクノロジです。読み取りが多く、書き込みがほとんどないビジネス シナリオでは、キャッシュを使用すると、大量の同時アクセスを効果的にサポートできます。次のようなデータ ソースバックエンドデータベースは十分に保護されています。現在、Redis、Memcached、Alibaba の Tair など、多くの分散キャッシュが市場に出回っていますが、どのキャッシュ製品を使用しても、基本的にはキャッシュの故障、キャッシュの無効化、ホット キーの問題が発生します。こうした問題をいかに効果的に防ぐかは、キャッシングによってもたらされる配当を楽しみながら解決しなければならない難しい問題でもあります。

通常、キャッシュを使用するときは、まずキャッシュに存在するかどうかを確認します。存在する場合は、キャッシュの内容を直接返します。存在しない場合は、データベースに直接クエリしてからキャッシュします。たとえば、次の図に示すように、

キャッシュの内訳:

Description

商品詳細などデータベースに存在しないデータをクエリしたり、IDが存在しないデータをクエリしたりすると毎回DBにアクセスすることになり、何者かが悪意を持って破壊した場合、直接DBに過剰な負荷がかかる可能性があります。

解決策:

特定のキーを使用してデータをクエリするとき、データベース内に対応するデータが存在しない場合は、このキーに対応する値を「NULL」などのデフォルト値に設定します。 」を選択し、キャッシュの有効期限を設定します。この時点で、このキーを介したすべてのアクセスは、キャッシュの有効期限が切れる前にキャッシュによってブロックされます。このキーに対応するデータがDB内に存在する場合は、キャッシュを無効にした後、再度このキーを介してデータにアクセスすることで新しい値を取得できます。

キャッシュの無効化:

説明

高同時実行環境では、この時点でキーに対応するキャッシュに障害が発生すると、複数のプロセスが同時にクエリを実行します。 .DBを作成し、同時にキャッシュを設定します。このとき、キーがシステム内のホットスポットキーだったり、同時に多数のキーが故障したりすると、DBアクセス量が瞬時に増加し過大な負荷がかかります。

解決策:

システム内のキーのキャッシュ有効期限を均等にずらして、同時に多数のキーに対応するキャッシュ障害を防ぎます。
キャッシュの使用方法を再設計します。キーがデータのクエリに使用されるとき、最初にキャッシュがクエリされます。この時点でキャッシュをクエリできない場合、ロックは分散ロックによってロックされます。ロックを取得するプロセスは DB をチェックし、キャッシュを設定します。ロックが解除されると、他のプロセスは待機し、ロックが解除されるまでキャッシュされたデータが返されるか、DB に再度クエリを実行します。

ホットスポット キー:

説明

キャッシュ内の特定のキー (おそらくアプリケーションおよび特定のプロモーション製品用) に対応する値は、クラスター内のマシンに保存されます。すべてのトラフィックが同じマシンに流れ、システムのボトルネックになるこの問題の課題は、マシンの容量を増やしても解決できないことです。

解決策:

クライアント ホットスポット キー キャッシュ: 値に対応するホットスポット キーをクライアント上でローカルにキャッシュし、有効期限を設定します。読み取りリクエストごとに、まずローカル キャッシュにキーが存在するかどうかを確認し、存在する場合は直接返し、存在しない場合は分散キャッシュ マシンにアクセスします。
ホットスポット キーを複数のサブキーに分散し、キャッシュ クラスター内の異なるマシンに保存します。これらのサブキーに対応する値はホットスポット キーと同じです。ホットスポット キーを介してデータをクエリする場合、何らかのハッシュ アルゴリズムを通じてサブキーがランダムに選択され、キャッシュ マシンにアクセスしてホットスポットを複数のサブキーに分散します。

Redis 関連の技術記事の詳細については、Redis チュートリアルをご覧ください。 勉強になるコラム！

以上がRedis キャッシュの故障が発生した場合の対処方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。