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

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

Java学习指南
Java学习指南転載
2023-07-26 14:53:291716ブラウズ

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


大規模なシステムでは、データベースの負荷を軽減するために、通常、キャッシュ メカニズムを導入すると、キャッシュ データとデータベース データ間の不一致が容易に発生し、ユーザーに古いデータが表示される可能性があります。
データの不整合を軽減するには、キャッシュとデータベースを更新するメカニズムが特に重要です。次に、落とし穴について説明します。

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

##キャッシュを脇に置く

キャッシュを脇に置く

つまり、キャッシュをバイパス、はいさらに表示一般的に使用されるキャッシュ戦略。

(1)

読み取りリクエスト共通プロセス

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

アプリケーションはまずキャッシュにデータがあるかどうかを判断します。キャッシュがヒットした場合は、データが直接返されます。キャッシュがミスした場合は、データが直接返されます。 、キャッシュはデータベースに侵入し、データベースからデータを取得します。データをクエリしてからキャッシュに書き戻し、最後にデータをクライアントに返します。

(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 は、書き込みが遅延していることを単に理解しています。キャッシュ プロバイダーはデータベースに時々バッチ入力を行います。利点は、アプリケーションの書き込みが非常に速いことです。

さて、今日はここに来ました。学習しましたか?

#

以上が同時実行性が高いシナリオでは、キャッシュまたはデータベースを最初に更新する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はJava学习指南で複製されています。侵害がある場合は、admin@php.cn までご連絡ください。