同時実行性が高いシナリオでは、キャッシュまたはデータベースを最初に更新する必要がありますか?

##キャッシュを脇に置く
キャッシュを脇に置くつまり、キャッシュをバイパス
、はいさらに表示一般的に使用されるキャッシュ戦略。
読み取りリクエスト共通プロセス アプリケーションはまずキャッシュにデータがあるかどうかを判断します。キャッシュがヒットした場合は、データが直接返されます。キャッシュがミスした場合は、データが直接返されます。 、キャッシュはデータベースに侵入し、データベースからデータを取得します。データをクエリしてからキャッシュに書き戻し、最後にデータをクライアントに返します。 (2) まずデータベースを更新してから、キャッシュからデータを削除します。 書き込みリクエストの画像を見た生徒の中には、「なぜキャッシュを削除する必要があるのですか?直接更新することはできないのですか?」と疑問に思う人もいるかもしれません。ここにはいくつかの落とし穴があるので、順を追って見ていきましょう。 キャッシュ アサイド戦略を誤って使用すると、深い落とし穴に遭遇することになります。1 つずつ踏み込んでいきましょう。 落とし穴 1: 最初にデータベースを更新してからキャッシュを更新する 同時に 2 つの 上記の実行プロセス: (1) (2) (3) (4) 実行後に期待される結果は、データベースの年齢が 20、キャッシュの年齢が 20、結果のキャッシュの年齢が 18 であることです。これにより、キャッシュ データが最新ではなくなり、ダーティ データが表示されます。 。 トラップ 2: 最初にキャッシュを削除してからデータベースを更新する If 上記の実行プロセス: (1) (2) (3) プロセス全体の後、 トラップ 3: 最初にデータベースを更新し、次にキャッシュを削除します。 実際のシステムでは、 Read request リクエストを書き込みます 読み取りリクエスト データベースの年齢は 20 この極端なシナリオが起こったらどうなるでしょうか?解決策を考えなければなりません: キャッシュ アサイド更新モードでは、アプリケーション コードは 2 つのデータ ソースを維持する必要があります。1 つはキャッシュ、もう 1 つはデータベースです。 上記のように、アプリケーションは 大量の読み取りを実行する場合、 キャッシュはデータ ソースとの一貫性を保ち、書き込みは常に 上記のように、アプリケーションが 2 つのデータを更新すると、キャッシュ プロバイダーはそのデータをすぐにキャッシュに書き込みますが、そのデータは一定期間後にデータベースをバッチで作成します。 この方法には利点と欠点があります。 多くのことを学んだので、誰もがキャッシュ更新戦略を明確に理解していると思います。最後に少しまとめを。 キャッシュ更新には主に 3 つの戦略があります: キャッシュの確保 通常、最初にデータベースが更新され、その後キャッシュが削除されます。データを保護するために、通常はキャッシュ時間が設定されます。 読み取り/書き込みスルーは通常、キャッシュ プロバイダーによる読み取りおよび書き込み操作を提供し、アプリケーションはキャッシュが操作されているかデータベースが操作されているかを知る必要はありません。 Write Behind は、書き込みが遅延していることを単に理解しています。キャッシュ プロバイダーはデータベースに時々バッチ入力を行います。利点は、アプリケーションの書き込みが非常に速いことです。 さて、今日はここに来ました。学習しましたか? 書き込みリクエスト
共通プロセス
キャッシュ アサイドの落とし穴
書き込みリクエストがある場合、
データは更新されると、各書き込みリクエストが実行されます。最初にデータベースが更新され、次にキャッシュが更新されます。同時シナリオではデータの不整合が発生する可能性があります。 Write request 1
データベースを更新し、年齢フィールドを 18 に更新します; リクエスト 2 を書き込みます
データベースを更新し、年齢フィールドを 20 に更新します;書き込みリクエスト 2
キャッシュの更新、キャッシュ期間は 20 に設定されます;書き込みリクエスト 1
キャッシュの更新、キャッシュ期間は設定されますto 18 ;write request
処理フローは最初にキャッシュを削除しますその後データベース
を更新すると、読み取りリクエスト
と 書き込みリクエスト
が同時に実行されるシナリオでは、データの不整合が発生する可能性があります。 Write request
キャッシュされたデータを削除; リクエストを読み取り
キャッシュ ミス (ヒット ミス) をクエリし、データベースにクエリを実行して、返されたデータをキャッシュに書き込みます;リクエストの書き込み
データベースを更新します。 database
の年齢は 20 で、cache
の年齢は 18 であることがわかりました。キャッシュとデータベースのデータは一貫性がなく、データがダーティでした。キャッシュに現れました。 書き込みリクエストの場合は、引き続き推奨されます
to update first その後、データベースはキャッシュ を削除しますが、次の例に示すように、理論上はまだ問題があります。
最初にデータベースを更新してからキャッシュを削除します
最初にキャッシュをクエリし、キャッシュがヒットしない場合はデータベースにクエリを実行してデータを返します;
データベースを更新してキャッシュを削除します;
ライトバック キャッシュ;
、
キャッシュの年齢であることがわかりました。は 18、つまりデータベースとキャッシュに不整合があり、アプリケーションが発生します。プログラムによってキャッシュから読み取られたデータは古いデータです。
キャッシュデータの有効期限を設定する
。通常、システムでは、少量のデータが短期間不整合になることが許容されます。
最後まで読んでください
Read-Through
戦略では、アプリケーションはキャッシュとデータベースを管理する必要がなく、データベースの同期をキャッシュ プロバイダー Cache Provider
に委託するだけで済みます。すべてのデータ対話は、抽象キャッシュ層
を通じて完了します。 キャッシュ プロバイダー
と対話するだけでよく、他の操作を行う必要はありません。キャッシュからフェッチされるかデータベースからフェッチされるかは重要です。 リードスルー
はデータ ソースの負荷を軽減でき、キャッシュ サービスの障害に対する回復力も備えています。キャッシュ サービスがダウンした場合でも、キャッシュ プロバイダーはデータ ソースに直接アクセスして動作できます。 リードスルーは、同じデータが複数回要求されるシナリオに適しています
。これはキャッシュ アサイド戦略とよく似ていますが、この 2 つの間にはまだいくつかの違いがあります。もう一度強調します:
ライトスルー
ライトスルー
戦略、データ更新 (書き込み) が発生すると、キャッシュ プロバイダー キャッシュ プロバイダー
基盤となるデータ ソースとキャッシュの更新を担当します。 抽象キャッシュ レイヤー
を介してデータ ソースに到達します。 キャッシュ プロバイダー
プロキシのように機能します。
ライト ビハインド
ライト ビハインド
一部の場所ライトバック
とも呼ばれますが、簡単に理解すると、アプリケーションがデータを更新するときはキャッシュのみが更新され、キャッシュプロバイダ
は定期的にデータをデータベースに更新します。はっきり言って、遅筆
です。
利点
は、データの書き込み速度が非常に速く、頻繁な書き込みに適していることです。シナリオ。 欠点
は、キャッシュとデータベースの一貫性が強くないため、高い一貫性が要求されるシステムでは注意して使用してください。
要約すると、
以上が同時実行性が高いシナリオでは、キャッシュまたはデータベースを最初に更新する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











一部のアプリケーションが適切に機能しないようにする会社のセキュリティソフトウェアのトラブルシューティングとソリューション。多くの企業は、内部ネットワークセキュリティを確保するためにセキュリティソフトウェアを展開します。 ...

システムドッキングでのフィールドマッピング処理は、システムドッキングを実行する際に難しい問題に遭遇することがよくあります。システムのインターフェイスフィールドを効果的にマッピングする方法A ...

データベース操作にMyBatis-Plusまたはその他のORMフレームワークを使用する場合、エンティティクラスの属性名に基づいてクエリ条件を構築する必要があることがよくあります。あなたが毎回手動で...

intellijideaultimatiateバージョンを使用してスプリングを開始します...

Javaオブジェクトと配列の変換:リスクの詳細な議論と鋳造タイプ変換の正しい方法多くのJava初心者は、オブジェクトのアレイへの変換に遭遇します...

データベースクエリにTKMYBATISを使用する場合、クエリ条件を構築するためにエンティティクラスの変数名を優雅に取得する方法は一般的な問題です。この記事はピン留めします...

多くのアプリケーションシナリオでソートを実装するために名前を数値に変換するソリューションでは、ユーザーはグループ、特に1つでソートする必要がある場合があります...

eコマースプラットフォーム上のSKUおよびSPUテーブルの設計の詳細な説明この記事では、eコマースプラットフォームでのSKUとSPUのデータベース設計の問題、特にユーザー定義の販売を扱う方法について説明します。
