キャッシュスルー、雪崩、ホットスポットとRedis
この文章をお勧めします.Redisアーキテクチャの雪崩防止設計:サイトがダウンしない背後にある兵法
(また、昨年の短文を食前のお菓子としてお勧めします.サービス側のキャッシュデザインを少し話します)
「Redisアーキテクチャの雪崩防止設計」という文章(以下「原文」という)は非常によく書かれており、大規模なシステムが直面する可能性のあるキャッシュスルーやキャッシュ雪崩などの問題を全面的に要約している.
「原文」の版図をより完全にするために、もう少し情報を補足したいと思います.
キャッシュスルーについて
「原文」は、空のオブジェクトとブロンフィルタの2つのソリューションを示します.
空のオブジェクトは第一選択案で、簡単で直接で、クエリの結果が空のキーに出会って、1つの空の値をキャッシュの中に置いて、次回更にアクセスしてすぐにこのキーが無効であることを知って、SQLを出す必要はありません.しかし、「原文」も、次のような問題があると述べています.
第一に、空の値がキャッシュされていることは、キャッシュレイヤにより多くのキーが格納されていることを意味し、より多くのメモリ領域が必要である(攻撃であれば、問題がより深刻である)ことを意味し、このようなデータに対して短い期限切れ時間を設定し、自動的に削除するのが効果的です.
第二に、キャッシュ・レイヤとストレージ・レイヤのデータは、しばらくの間ウィンドウが一致せず、ビジネスに一定の影響を及ぼす可能性があります.たとえば、有効期限が5分に設定されている場合、ストレージ・レイヤにこのデータが追加されると、キャッシュ・レイヤとストレージ・レイヤのデータが一致しなくなり、メッセージ・システムまたは他の方法でキャッシュ・レイヤ内の空のオブジェクトを消去できます.
第1点については、空の値を別のキャッシュ空間に置くことをお勧めします.通常値と共有するのはよくありません.そうしないと、空間が不足している場合、キャッシュシステムのLRUアルゴリズムはまず正常値を除去し、空の値を除去する可能性があります.この脆弱性は攻撃される可能性があります.
第2のポイントについては、Redisキャッシュであれば、データを更新した後、直接Redisでクリアすればよい.ローカルキャッシュであれば、他のマシンにそれぞれのローカルキャッシュをクリアするようにメッセージを通知する必要があります.(業界はついにメッセージでキャッシュを同期させる設計思想を受け入れた、cheers!)「複数のマシンのキャッシュをメッセージで同期する」ことを簡単に実証する小さなプロジェクトjoint-cache-redisがあり、実際にはKafkaがRedis MQよりもこのシーンに適している可能性があることが分かった.
キャッシュ雪崩について
この要約はとても伝神的だ.
補足することはありませんが、NetflixオープンソースのHystrixに感謝しましょう.単なるライブラリですが、信頼性の高いストリーム制限アルゴリズムを実現するには、まだ道があります.
キャッシュホットスポットkeyの再構築について
「原文」は
反発ロック(Mutex):
「分散キャッシュ・ロック」は通常、ロックを保持するインスタンスが不安定で、ロックが期限切れになるまでロックを浪費する逆モードです(昨年の記事の大規模なサービス・エンドで開発された逆モード7条を参照).「原文」の著者は、デッドロックのリスクも指摘している.
実際には最適化できます.1、2回待ってから、再試行時に反発ロックを迂回することができます.反発ロックを迂回しても、キャッシュの更新はべき乗などの操作であるため、悪い結果は生じません.
ロックの有効期限を短く設定することもできます.
この例から,べき乗等操作は非べき乗等操作よりも最適化しやすいことが分かる.
いつまでも期限が切れません:
「原文」はRedisでの作り方をよく紹介しています.Guavaのローカルキャッシュは簡単です.
「原文」は最後まで読んで、「Redis開発と運維」という本の節選であることを知った.この本は国産技術書の逸品になると信じている.
(また、昨年の短文を食前のお菓子としてお勧めします.サービス側のキャッシュデザインを少し話します)
「Redisアーキテクチャの雪崩防止設計」という文章(以下「原文」という)は非常によく書かれており、大規模なシステムが直面する可能性のあるキャッシュスルーやキャッシュ雪崩などの問題を全面的に要約している.
「原文」の版図をより完全にするために、もう少し情報を補足したいと思います.
キャッシュスルーについて
「原文」は、空のオブジェクトとブロンフィルタの2つのソリューションを示します.
空のオブジェクトは第一選択案で、簡単で直接で、クエリの結果が空のキーに出会って、1つの空の値をキャッシュの中に置いて、次回更にアクセスしてすぐにこのキーが無効であることを知って、SQLを出す必要はありません.しかし、「原文」も、次のような問題があると述べています.
第一に、空の値がキャッシュされていることは、キャッシュレイヤにより多くのキーが格納されていることを意味し、より多くのメモリ領域が必要である(攻撃であれば、問題がより深刻である)ことを意味し、このようなデータに対して短い期限切れ時間を設定し、自動的に削除するのが効果的です.
第二に、キャッシュ・レイヤとストレージ・レイヤのデータは、しばらくの間ウィンドウが一致せず、ビジネスに一定の影響を及ぼす可能性があります.たとえば、有効期限が5分に設定されている場合、ストレージ・レイヤにこのデータが追加されると、キャッシュ・レイヤとストレージ・レイヤのデータが一致しなくなり、メッセージ・システムまたは他の方法でキャッシュ・レイヤ内の空のオブジェクトを消去できます.
第1点については、空の値を別のキャッシュ空間に置くことをお勧めします.通常値と共有するのはよくありません.そうしないと、空間が不足している場合、キャッシュシステムのLRUアルゴリズムはまず正常値を除去し、空の値を除去する可能性があります.この脆弱性は攻撃される可能性があります.
第2のポイントについては、Redisキャッシュであれば、データを更新した後、直接Redisでクリアすればよい.ローカルキャッシュであれば、他のマシンにそれぞれのローカルキャッシュをクリアするようにメッセージを通知する必要があります.(業界はついにメッセージでキャッシュを同期させる設計思想を受け入れた、cheers!)「複数のマシンのキャッシュをメッセージで同期する」ことを簡単に実証する小さなプロジェクトjoint-cache-redisがあり、実際にはKafkaがRedis MQよりもこのシーンに適している可能性があることが分かった.
キャッシュ雪崩について
この要約はとても伝神的だ.
， ， 補足することはありませんが、NetflixオープンソースのHystrixに感謝しましょう.単なるライブラリですが、信頼性の高いストリーム制限アルゴリズムを実現するには、まだ道があります.
キャッシュホットスポットkeyの再構築について
「原文」は
， ， ， と述べ、「反発ロック」と「いつまでも期限が切れない」の2つの候補案を与えた.反発ロック(Mutex):
「分散キャッシュ・ロック」は通常、ロックを保持するインスタンスが不安定で、ロックが期限切れになるまでロックを浪費する逆モードです(昨年の記事の大規模なサービス・エンドで開発された逆モード7条を参照).「原文」の著者は、デッドロックのリスクも指摘している.
実際には最適化できます.1、2回待ってから、再試行時に反発ロックを迂回することができます.反発ロックを迂回しても、キャッシュの更新はべき乗などの操作であるため、悪い結果は生じません.
ロックの有効期限を短く設定することもできます.
この例から,べき乗等操作は非べき乗等操作よりも最適化しやすいことが分かる.
いつまでも期限が切れません:
「原文」はRedisでの作り方をよく紹介しています.Guavaのローカルキャッシュは簡単です.
refreshAfterWriteを使用すればいいです.「原文」は最後まで読んで、「Redis開発と運維」という本の節選であることを知った.この本は国産技術書の逸品になると信じている.