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