#キャッシュ ブレークダウン

本當(dāng)の問題は、キーが存在してもキャッシュに存在しないため、データベース操作が発生することです。

解決策:

プログラム分析:

• ミューテックス ロックにより、データベースに送信されるリクエストが 1 つだけになることが保証されるため、これは利點です。しかし、分散システムでは、分散ロックを?qū)g裝するために分散ロックが使用されるため、分散ロックの実裝自體に一定の困難があり、システムの複雑さが増大します。

• 2 番目のソリューションは、Redis の有効期限が切れず、ビジネスが期限切れになるソリューションを使用して実裝されます。これにより、リクエストごとにデータを確実に取得でき、バックグラウンド スレッドを使用してデータを更新することもできます。欠點は、バックグラウンド スレッドがデータの更新を完了していないことです?，F(xiàn)時點では、要求されたデータは古いデータであるため、リアルタイム性の要件が高いビジネス シナリオでは不利になる可能性があります。

• 3 番目の解決策は、キャッシュの予熱を使用し、ロードされるたびにキャッシュすることであり、2 番目の解決策と似ています。ただし、ホットデータ更新の問題もあるため、このソリューションは高いリアルタイム性を必要としないデータに適しています。

• 4 番目のソリューションは 2 番目と 3 番目のソリューションに似ており、これに基づいて、バックグラウンドの非同期スレッドを使用してキャッシュされたデータをアクティブに更新するという特定の最適化が行われています。難しいのは、更新の頻度を制御することです。

スキームの概要:

• リアルタイム要件が高いデータの場合は、最初のスキームを使用することをお勧めします。技術(shù)的には難しいですが、リアルタイムにデータを処理できます。一部のリクエストが長時間待機する場合、例外が返され、クライアントはリクエストを再送信できます。

• 高いリアルタイム パフォーマンスを必要としないデータの場合は、4 番目のソリューションを使用できます。

#キャッシュ雪崩定義: 前述のキャッシュの故障は、キャッシュ內(nèi)の特定のホット スポットが原因です。キーが失敗すると、大量のリクエストがデータベースに送信されます。ただし、キャッシュ雪崩は実際には同じですが、こちらの方が深刻で、1 つまたは 2 つのキーではなく、キャッシュされたキーのほとんどが無効です。

例: 電子商取引システムでは、特定のカテゴリの商品データがキャッシュ內(nèi)で無効です。ただし、現(xiàn)在のシステムからのリクエストの多くは、このカテゴリの製品データに対するものです。これにより、すべてのリクエストがデータベース クエリを通過するようになります。

危険性: 瞬時に大量のリクエストが殺到するため、各リクエストをデータベース內(nèi)でクエリする必要があります。データベースへのトラフィックの瞬間的な流入は、データベースへの負(fù)擔(dān)を大幅に増大させ、直接的なデータベース麻痺を容易に引き起こす可能性があります。

1. キャッシュ時間はランダムです。特定の時刻に多數(shù)のキャッシュが期限切れになるため、キャッシュの期限切れ時間が比較的集中していることを意味します。有効期限を焦點を當(dāng)てずにランダムに直接設(shè)定します。この方法では、キャッシュの有効期限があまり集中せず、データベースに対するクエリ操作のリクエストが同時に大量に発生することもありません。

2. マルチレベルキャッシュ。単に Redis に依存してキャッシュするのではなく、memcached をキャッシュに使用することもできます (これは単なる例であり、他のキャッシュ サービスも使用できます)。データをキャッシュする場合は、Redis 用のキャッシュと memcached 用のキャッシュを作成します。 Redis が失敗した場合は、memcached を使用できます。

3. ミューテックス ロック。キャッシュの內(nèi)訳でミューテックス ロックの使用について説明しましたが、アバランシェの場合にもミューテックス ロックを使用できます。

4. 有効期限フラグを設(shè)定します。実際、キャッシュの內(nèi)訳で説明した永久的な無期限を使用することもできます。リクエスト時に有効期限が決定され、有効期限が近づくと有効期限フラグが設(shè)定され、獨立したスレッドがトリガーされてキャッシュが更新されます。

スキーム分析:

• 最初のスキームでは亂數(shù)のキャッシュ時間を使用し、キーの有効期限を確実に分散させます。難しいのはキャッシュ時間をどのように設(shè)定するかですが、キャッシュ時間が短く、データ量が非常に多い一部のデータの場合、このソリューションでは適切な時間制御が必要です。

• 2 番目のソリューションでは、マルチレベル キャッシュを使用して、すべてのリクエストがキャッシュされるようにします。ただし、これにより、システムのアーキテクチャの難しさが増し、マルチレベルの更新のキャッシュなど、その他のさまざまな問題が発生します。

• 3 番目のオプションはミューテックス ロックを使用します。ミューテックス ロックについてはキャッシュ ブレークダウンで説明しました。雪崩シナリオで使用できますが、これにより大量の配布が生成されます。スタイル ロック。

• 4 番目のソリューションでは、論理キャッシュ時間を使用します。これにより、システムのキャッシュ圧力が十分に保証されます。

計畫の概要:

実際のプロジェクトでは、1 番目、2 番目、4 番目のオプションを使用して試してみることをお勧めします。どちらが良いでしょう。

#概要

• キャッシュの侵入は、データベース自體にデータがないことが原因です。

• キャッシュの故障とキャッシュなだれは、データはデータベースに存在するが、キャッシュ內(nèi)のデータが無効であるため、データベースが再度クエリされてからキャッシュに追加されることを意味します。

• キャッシュの故障は一部のホット キーを?qū)澫螭趣筏皮い蓼工?、キャッシュなだれは大?guī)模なキャッシュ障害です。キャッシュ キーの分割が異なることを除いて、2 つの原則は実際には同じです。

プログラミング入門をご覧ください。 ！