Java 分散キャッシュ システムが解決する必要がある 4 つの主要な問題は何ですか?

分散キャッシュ システムは 3 層アーキテクチャに不可欠な部分であり、プロジェクト全体の同時実行性と応答速度を大幅に向上させますが、解決すべき新たな問題ももたらします。つまり、キャッシュの侵入、キャッシュの破壊です。 、キャッシュなだれとキャッシュの一貫性の問題。

キャッシュの侵入

最初の大きな問題はキャッシュの侵入です。この概念は理解しやすく、ヒット率に関連しています。ヒット率が低い場合、データベース永続層に負荷が集中します。

関連するデータが見つかった場合は、それをキャッシュできます。しかし問題は、このリクエストがキャッシュ層または永続化層にヒットしなかったことであり、この状況はキャッシュ侵入と呼ばれます。

たとえば、上の図に示すように、ログイン システムでは外部からの攻撃があり、存在しないユーザーを使用してログインを試行し続けます。ユーザーは仮想であるため、事実上キャッシュされ、毎回データベース内でクエリが実行されるため、最終的にはサービスのパフォーマンス障害が発生します。

この問題には多くの解決策がありますので、簡単に紹介しましょう。

1 つ目は、空のオブジェクトをキャッシュすることです。永続層がデータを見つけられないということではないでしょうか？次に、このリクエストの結果を null に設定し、キャッシュに入れることができます。適切な有効期限を設定することで、バックエンド データベースのセキュリティを確保できます。

空のオブジェクトをキャッシュすると追加のキャッシュ スペースが占有され、データの不整合が発生する時間枠も発生するため、2 番目の方法は、ブルーム フィルターを使用して大量の通常のキー値を処理することです。

レコードの有無はブール値であり、1 ビットのみを使用して格納できます。ブルーム フィルターは、この「はい」と「いいえ」の操作をデータ構造に圧縮できます。たとえば、携帯電話番号やユーザーの性別などのデータは、ブルーム フィルターの使用に非常に適しています。

キャッシュの故障

キャッシュの故障とは、ユーザー リクエストがデータベースに到達する状況を指します。ほとんどの場合、キャッシュ時間のバッチの有効期限が切れることが原因です。

通常、キャッシュ内のデータには有効期限が設定されています。あるタイミングでデータベースから大量のデータを取得し、同じ有効期限を設定すると、同時に有効期限が切れてしまい、キャッシュが壊れてしまいます。

ホット データの場合は、有効期限が切れないように設定したり、アクセス時に有効期限を更新したりできます。バッチに保存されたキャッシュされたアイテムの場合は、同時に無効になることを避けるために、比較的平均的な有効期限を割り当てるようにしてください。

キャッシュ雪崩

雪崩と聞くと怖そうですが、実際の状況はもっと深刻です。キャッシュはシステムを高速化するために使用され、バックエンド データベースはデータのバックアップにすぎず、高可用性の代替手段ではありません。

キャッシュ システムに障害が発生すると、トラフィックは即座にバックエンド データベースに転送されます。やがて、データベースは大量のトラフィックによって圧倒されてハングアップし、この連鎖的なサービス障害はまさに雪崩と呼ぶことができます。

高可用性キャッシュの構築は非常に重要です。 Redis はマスター/スレーブ モードとクラスター モードを提供します。クラスター モードは使いやすく、各シャードは独立してマスター/スレーブとしても機能するため、非常に高い可用性が保証されます。

さらに、データベースのパフォーマンスのボトルネックについての一般的な評価も行っています。キャッシュ システムがクラッシュした場合は、電流制限コンポーネントを使用して、データベースに流れるリクエストを遮断できます。

キャッシュの一貫性

キャッシュ コンポーネントの導入後の別の困難な問題は、キャッシュの一貫性です。

まず、問題がどのように発生したかを見てみましょう。キャッシュ項目の場合、書き込み、更新、読み取り、削除という 4 つの一般的な操作があります。

• 書き込み: キャッシュとデータベースは 2 つの異なるコンポーネントであるため、二重書き込みが行われると、どちらか一方の書き込みのみが成功し、データの不整合が発生する可能性があります。

• 更新: 更新状況は似ており、2 つの異なるコンポーネントを更新する必要があります。

• 読み取り: キャッシュから読み取られた情報が最新であり、データベース内の情報と一致していることを確認するために読み取ります。

• 削除: データベース レコードを削除する場合、キャッシュ内のデータを削除するにはどうすればよいですか?

ビジネス ロジックは、ほとんどの場合、比較的複雑であるためです。更新操作には非常にコストがかかります。たとえば、ユーザーの残高は一連の資産を計算して計算される数値です。これらの関連アセットが変更されるたびにキャッシュを更新する必要がある場合、コード構造は非常に混乱し、保守が不可能になります。

キャッシュ同期を非常に簡単にできる遅延読み込みメソッドを使用して、トリガーされたキャッシュ整合性メソッドを使用することをお勧めします。

• キャッシュを読み取るとき、キャッシュ内に関連するデータがない場合、関連するビジネス ロジックが実行され、キャッシュ データが構築され、キャッシュ システムに保存されます。

• キャッシュ アイテムに関連するリソースが変更されると、まず対応するキャッシュ アイテムが削除され、次にデータベース内のリソースが更新され、最後に対応するキャッシュ アイテムが削除されます。

単純なプログラミング モデルに加えて、この操作には明らかな利点があります。このキャッシュは使用するときにのみキャッシュ システムにロードされます。変更が行われるたびにリソースが作成および更新される場合、キャッシュ システムには大量のコールド データが存在します。これは実際には、オンデマンドでデータ ストレージからキャッシュにデータをロードするキャッシュ アサイド パターンを実装しており、最大の効果はパフォーマンスの向上と不要なクエリの削減です。

しかし、これにはまだ問題があります。次に紹介するシナリオも面接でよく聞かれる質問です。

前述のデータベース更新アクションとキャッシュ削除アクションは、明らかに同じトランザクション内にありません。これにより、更新プロセス中にデータベースの内容とキャッシュ内の内容が不一致になる可能性があります。

面接では、この質問を指摘する限り、面接官は親指を立てます。

分散ロックを使用すると、この問題を解決できます。ロックを使用すると、データベース操作とキャッシュ操作を他のキャッシュ読み取り操作から分離できます。一般に、読み取り操作にはロックは必要ありませんが、ロックが発生すると再試行し、タイムアウトになるまで待機します。

以上がJava 分散キャッシュ システムが解決する必要がある 4 つの主要な問題は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。