著者: Xiaolin コーディング
コンピューター定型エッセイ ウェブサイト: https://xiaolincoding.com
皆さんこんにちは、シャオリンです。
今日は、一般的なキャッシュ更新戦略についてお話させてください。
- Cache Aside (バイパス キャッシング) 戦略。
- リード/ライトスルー (リードスルー/ライトスルー) 戦略;
- 書き戻し戦略;
実際の開発では、Redis と MySQL の更新戦略は Cache Aside を使用し、他の 2 つの戦略は主にコンピューター システムで使用されます。
Cache Aside (バイパス キャッシング) 戦略
The Cache Aside (bypass cache) 戦略は、最も一般的に使用されます. アプリケーションは、「データベースとキャッシュ」と直接対話し、キャッシュを維持する責任があります. この戦略は、「読み取り戦略」と「書き込み戦略」に細分できます.
ポリシーを作成する手順:
- 最初にデータベース内のデータを更新してから、キャッシュ内のデータを削除してください。
ポリシーを読み取る手順:
- 読み取りデータがキャッシュにヒットした場合、データは直接返されます。
- 読み取りデータがキャッシュにヒットしない場合、データはデータベースから読み取られ、キャッシュに書き込まれ、ユーザーに返されます。
書き込み戦略のステップの順序を逆にすることはできないことに注意してください.つまり、最初にキャッシュを削除してからデータベースを更新することはできません.理由は、「読み取り+書き込み」が同時に行われる場合、キャッシュとデータベース。
たとえば、ユーザーの年齢が 20 歳で、要求 A がユーザーの年齢を 21 に更新したい場合、キャッシュ内のコンテンツを削除します。このとき、別のリクエスト B はユーザーの年齢を読み取りたいと考えています. キャッシュをクエリしてミスを見つけた後、データベースから年齢 20 を読み取ってキャッシュに書き込み、リクエスト A にデータベースの変更を続行するよう要求します. 、およびユーザーの年齢が 21 に更新されます。
結局、ユーザーの年齢はキャッシュでは 20 (古い値)、データベースでは 21 (新しい値) であり、キャッシュとデータベースのデータは矛盾しています。
「最初にデータベースを更新してからキャッシュを削除する」と、データの不整合の問題が発生しないのはなぜですか?
「読み取り + 書き込み」要求の同時シナリオの分析を続けます。
特定のユーザー データがキャッシュに存在しない場合、要求 A がデータを読み取ると、データベース クエリから年齢が 20 になり、別の要求 B がキャッシュに書き込まれていないときにデータを更新します。データベースの年齢を 21 に更新し、キャッシュをクリアします。このとき、リクエスト A は、データベースから読み取った age 20 データをキャッシュに書き込みます。
結局、ユーザーの年齢はキャッシュでは 20 (古い値) で、データベースでは 21 (新しい値) であり、キャッシュとデータベースのデータは矛盾しています。上記の理論的な分析から、最初にデータベースを更新してからキャッシュを削除することもデータの不整合を引き起こしますが、実際には、この問題が発生する可能性は高くありません。
通常、キャッシュの書き込みはデータベースの書き込みよりもはるかに高速であるため、リクエスト B がデータベースを更新してキャッシュを削除した後で、リクエスト A がキャッシュの更新を完了するのは実際には困難です。リクエスト B がキャッシュを削除する前にリクエスト A がキャッシュを更新すると、次のリクエストはキャッシュ ミスのためにデータベースからデータを再読み込みするため、この不整合は発生しません。
キャッシュ アサイド ポリシーは、読み取りが多く書き込みが少ないシナリオには適していますが、書き込みが多いシナリオには適していません。書き込みが頻繁に行われると、キャッシュ内のデータが頻繁にクリーンアップされ、キャッシュに何らかの影響が及ぶためです。ヒット率。ビジネスにキャッシュ ヒット率に関する厳しい要件がある場合は、次の 2 つのソリューションを検討できます。
- 1 つのアプローチは、データを更新するときにキャッシュを更新することですが、キャッシュを更新する前に分散ロックを追加することです。これは、同時にキャッシュを更新できるスレッドは 1 つだけであり、同時実行性の問題が発生しないためです。もちろん、そうすると、書き込みのパフォーマンスにある程度の影響があります。
- もう 1 つの方法は、データを更新するときにキャッシュを更新することですが、キャッシュに短い有効期限を追加することで、キャッシュが矛盾していてもキャッシュされたデータはすぐに期限切れになり、ビジネスへの影響は許容されます。
Read/Write Through (リードスルー/ライトスルー) 戦略
リード/ライト スルー戦略の原則は、アプリケーションがキャッシュと対話するだけで、データベースとは対話しなくなりますが、キャッシュはデータベースと対話します。これは、キャッシュ自体によってデータベースを更新する操作と同等です。
戦略を読み通す
最初にキャッシュ内のデータが存在するかどうかを確認し、存在する場合はそれを直接返します。存在しない場合は、キャッシュ コンポーネントがデータベースからデータをクエリし、結果をキャッシュ コンポーネントに書き込み、最後にキャッシュ コンポーネントがアプリケーションへのデータ。
ライトスルー戦略
データの更新がある場合、最初に書き込むデータが既にキャッシュに存在するかどうかをクエリします。
- キャッシュ内のデータが既に存在する場合、キャッシュ内のデータが更新され、キャッシュ コンポーネントがデータベースに対して同期的に更新され、キャッシュ コンポーネントがアプリケーションに更新が完了したことを通知します。
- キャッシュ内のデータが存在しない場合は、データベースを直接更新して戻ります。
以下は、リード スルー/ライト スルー戦略の概略図です。
リード スルー/ライト スルー戦略の特徴は、アプリケーション プログラムではなくキャッシュ ノードがデータベースを処理することです. 私たちの開発プロセスでは、キャッシュ アサイド戦略ほど一般的ではありません。 Memcached であるか、どちらでもない Redis は、データベースに書き込み、データベースにデータを自動的にロードする機能を提供します。また、ローカル キャッシュを使用する場合は、この戦略を使用することを検討できます。
書き戻しポリシー
データを更新する場合、ライト バック戦略はキャッシュのみを更新し、キャッシュ データをダーティとして設定し、データベースを更新せずにすぐに戻ります。データベースの更新はバッチ非同期更新で行います。
実際、Redis にはデータベースを非同期的に更新する機能がないため、Write Back (ライトバック) 戦略は、一般的なデータベースとキャッシュのシナリオには適用できません。
ライト バックはコンピュータ アーキテクチャの設計であり、たとえば、オペレーティング システムの CPU のキャッシュとファイル システムのキャッシュはすべて、ライト バック (ライト バック) 方式を採用しています。
ライトバック戦略は、書き込み操作が発生したときにキャッシュを更新してすぐに戻るだけでよいため、書き込みが多いシナリオに特に適しています。たとえば、ファイルを書き込む場合、実際にはファイル システムのキャッシュに書き込まれてから返され、ディスクには書き込まれません。
しかし問題は、データの一貫性が強くなく、データ損失のリスクがあることです。これは、キャッシュは通常メモリを使用し、メモリは非永続的であるため、キャッシュ マシンの電源がオフになると、元のキャッシュが失われるためです。汚れています。データが失われています。そのため、システムの電源を切ると、以前に書き込まれたファイルの一部が失われることがわかります。これは、ページ キャッシュがディスクをフラッシュする時間がないためです。
CPU キャッシュとメモリ使用のライト バック戦略のフローチャートを次に示します。
このプロセスはおなじみですか？CPU キャッシュの記事を書いたときに言及したからです。
シリーズ「図解 Redis」記事
データ型