Redisのキャッシュの問題と解決策

キャッシュの浸透

説明:高い並行性の場合には、データに存在しないデータベースを照会は、圧力は、データベースに集中している
溶液。

  • 1)ヌル値ヌルも短い有効期限を設け、データベース内に配置されます。
  • 2)ブルームフィルタ

キャッシュの雪崩

説明:キーの数が多いが、直接データベースへのリクエストで、その結果、有効期限が切れ同時にキャッシュ。
ソリューション:

  • 1)時間の独立したキャッシュは、キーの多数を回避しながらすることは有効期限が切れています。

キャッシュの内訳

説明:多数の要求への鍵は、データベースに直接キャッシュすることにより、すべての要求、キーの有効期限が切れたときに期限切れになる
解決策:

  • キーがロックに存在し、データベースを照会していない場合1)キャッシュがロックされ、他の要求と同様に、ロック待ちがある場合、クエリデータをアンロックで待機します。

データベースとキャッシュ・コヒーレンシ

説明:シーンの一つは:そのような商品の在庫を更新するなど、データを更新する場合、商品在庫は、現在100ある今最初の99にデータベースの変更を更新し、キャッシュを削除し、キャッシュを意味し、失敗した削除、99に更新しますインベントリデータは99で、キャッシュは、データベースとキャッシュ内の矛盾につながる、100です。
ソリューション:

  • 1)まず、キャッシュを削除し、正常キャッシュを削除し、データベースのデータを削除します。キャッシュの削除に失敗しました、データベースが削除されません。

説明:シーン2:変更されたデータは、データベースに送信されていないが、キャッシュデータが削除されています。古いデータに対してクエリがある場合は、この時間は、キャッシュに追加されました。このキャッシュの有効期限が切れる前に、要求は、古いデータである
ソリューション:ソリューションは、オンライン:::これは、あなたが、これを解決するためにキューを使用するなど20のように複数のキューを作成することができそうである与えられた、商品によってはデータ更新要求は、行くように最初のキューにスローされたときにIDは、更新処理が発生した場合、キューから削除、更新した後、ハッシュ値、撮影したキュータッチのその後数を、行いますシナリオは、上記の、あなたはどこへ行くキューにクエリを送信するための要求もある場合は、更新を行うことで同じ製品IDは、その後、完全な同期キャッシュの更新を待つかどうかを確認するためにキューに行くことができない場合は、データ・キャッシュはありません見に行きます。
最適点があり、新しいクエリが200MS周りキャッシュ、ループを照会しながら、(真の)ループで行く入れないで、クエリ要求をキューイングし、することが分かった場合、キャッシュが直接されていない場合データベースは古いデータを取り、一般的であると解釈されます。

おすすめ

転載: blog.51cto.com/12332955/2415978