ナビゲーション:
目次
1.2 キャッシュを更新しますか、それともキャッシュを削除しますか?
1.3 データベースを操作するのが先ですか、それともキャッシュを削除するのが先ですか?
1.3.1 キャッシュを削除してからデータベースを運用する場合のメリットとデメリット
1.3.2 データベースを操作してからキャッシュを削除する場合のメリットとデメリット (推奨)
1.4 最適な同期戦略: 最初にデータベースを更新し、次にキャッシュを削除します
5. 複数の保証: 最終的な強力なコンセンサスソリューション
1. 4 つの基本的な同期戦略
1.1 同期戦略
キャッシュとデータベース間の二重書き込みの一貫性を確保するには、4 つの同期戦略があります。つまり、最初にキャッシュを更新してからデータベースを更新、最初にデータベースを更新してからキャッシュを更新、最初にキャッシュを削除してから更新します。データベースを更新し、次にデータベースを更新してからキャッシュを削除します。
- 最初にキャッシュを更新し、次にデータベースを更新します。2 番目のステップは失敗し、キャッシュ ライブラリはダーティ データです。
- 最初にデータベースを更新してからキャッシュを更新します。2番目のステップは失敗し、キャッシュ ライブラリは古いデータです。
- 最初にキャッシュを削除してからデータベースを更新します。2 番目のステップは失敗し、キャッシュ ライブラリは空のデータになります。
- まずデータベースを更新してからキャッシュを削除します (推奨): 2 番目のステップは失敗し、キャッシュ ライブラリは古いデータです
1.2 キャッシュを更新しますか、それともキャッシュを削除しますか?
1.2.1 キャッシュ更新のメリットとデメリット
キャッシュを更新する利点は、データが変更されるたびにタイムリーにキャッシュを更新できるため、クエリミスが発生しにくいことですが、この操作の消費量は多くなります。複雑な計算後のキャッシュ、頻繁 更新されたキャッシュはサーバーのパフォーマンスに影響します。データが頻繁に書き込まれるシナリオの場合、キャッシュは頻繁に更新される可能性がありますが、データを読み取る必要はありません。
1.2.2 キャッシュ削除のメリットとデメリット（推奨）
キャッシュを削除する利点は、更新操作が複雑かどうかに関係なく、キャッシュ内のデータが直接削除されるため、操作が簡単であることです。このアプローチの欠点は、キャッシュが削除された後、次回ミスが発生する可能性が高く、データベースを再度読み取る必要があることです。
対照的に、キャッシュを削除することがより良い選択であることは間違いありません。
1.3 データベースを操作するのが先ですか、それともキャッシュを削除するのが先ですか?
1.3.1 キャッシュを削除してからデータベースを運用する場合のメリットとデメリット
ケース 1: データベースとキャッシュの内容が一致しない
スレッド 1 がキャッシュを削除し、データベースを更新する時間がない場合、スレッド 2 がキャッシュを読み取ります。キャッシュ内のデータはスレッド 1 によってクリアされているため、スレッド 2 はデータベースからデータを読み取り、データベースを保存する必要があります。キャッシュ内の結果を読み取ります。この時点で、スレッド 1 はデータベースを正常に更新し、更新します。データベースとキャッシュの内容の間に不一致が発生します。
ケース 2: キャッシュの故障、データベースのスタック
スレッド 1 がキャッシュを削除し、データベースを更新する時間がない場合、大量の読み取りリクエストが受信されます。キャッシュ内にデータがないため、キャッシュの故障により大量のリクエストがデータベースに直接アクセスされ、データベースがクラッシュします。
1.3.2 データベースを操作してからキャッシュを削除する場合のメリットとデメリット (推奨)
ダーティ データの問題:データベースが最初に操作されてもキャッシュの削除に失敗した場合、古いデータは常にキャッシュ ライブラリに残りますが、新しいデータはデータベースに保存されます。
解決策: 非同期再試行メカニズム
上記の問題が発生した場合、通常はリトライ機構を利用して解決しますが、リトライ機構による本業務の実行への影響を避けるため、リトライ機構は非同期で実行することが一般的に推奨されます。再試行メカニズムを採用する場合、同時実行性の存在により、最初にキャッシュを削除すると、古いデータがキャッシュに保存されたままになる可能性がありますが、新しいデータはデータベースに保存され、2 つのデータは不整合になります。
1.4 最適な同期戦略:最初にデータベースを更新し、次にキャッシュを削除します
したがって、最初にデータベースを更新してからキャッシュを削除するのが影響の少ない解決策であるという結論に達しました。2 番目のステップが失敗した場合は、再試行メカニズムを使用して問題を解決できます。
同期削除スキーム:最初にデータベースを更新し、次にキャッシュを削除します。データの一貫性が必須ではないシナリオに適しています
プロセス:まずデータベースを更新してから、キャッシュを削除します。
質問：
- 同時実行中のダーティ データ:データベースのクエリからキャッシュの書き込みまでの期間に、他のスレッドが更新と削除を実行するため、キャッシュされたデータが古いデータになります。
- キャッシュの削除に失敗しました:削除に失敗したため、キャッシュ ライブラリは古いデータのままです
2.同期削除＋信頼性の高いメッセージ方式
同期削除 + 信頼性の高いメッセージ削除:データの整合性が必須ではないシナリオに適しています。
プロセス:まずデータベースを更新してからキャッシュを削除します。削除に失敗した場合は、信頼性の高い MQ を送信し、削除が成功するまでキャッシュの削除を再試行するか、5 回再試行します。
問題: MQ が複数回の再試行に失敗し、長期にわたってダーティなデータが生成されました。
3.遅延二重削除: より一貫性の高いソリューション
遅延二重削除スキーム:同期削除戦略よりも一貫性が高いスキーム。
プロセス:最初にキャッシュを削除し、ライブラリからデータベースが更新された後に 1 回程度、データベースを更新します。
問題:タイミングは制御できず、データベースがリポジトリから更新された後にキャッシュが削除されるという保証はありません。スレーブ データベースが更新される前に削除された場合、ユーザーはスレーブ データベースをチェックし、更新する前にキャッシュにダーティ データを書き込むことになります。
4.非同期監視＋確実なメッセージ削除方式
非同期監視 + 信頼性の高いメッセージ削除:多くの大手メーカーが使用しているソリューション。
プロセス：
- データベースの更新後は何も操作しません。
- Canal とその他のコンポーネントは binlog を監視し、更新が見つかると信頼できる MQ を送信してキャッシュを削除します。
- キャッシュの削除に失敗した場合、メッセージは手動の確認応答や再試行などのメカニズムに基づいて、限られた回数内で再試行されます。
アドバンテージ：
- 非同期削除、より高いパフォーマンス。
- 信頼性の高いメッセージ再試行メカニズムにより、複数の削除により確実に削除が成功します。
問題: canal などの Binlog キャプチャ コンポーネントは高可用性が必要ですが、canal に障害が発生すると、長期にわたるダーティ データが発生します。
5. 複数の保証: 最終的な強力なコンセンサスソリューション
複数の保証スキーム:同期削除 + 非同期監視 + 信頼性の高いメッセージ削除、キャッシュ時の有効期限の設定、クエリ時のメイン ライブラリの強制チェック、データの一貫性が必須の状況に適しています。
- 同期削除:最初にデータベースを更新してからキャッシュを削除します。キャッシュが削除される前に古いキャッシュ データが再び見つかることを防ぐため、このリンクの後はデータを再度確認することは禁止されています。
- Canal の監視: Canal とその他のコンポーネントは binlog を監視し、更新があることを検出すると信頼性の高い MQ を送信してキャッシュを削除します。2 番目の層はキャッシュが正常に削除されたことを確認します。
- 遅延メッセージ検証の一貫性: Canal およびその他のコンポーネントは、binlog を監視し、遅延 MQ を送信し、N 秒後にキャッシュの一貫性を検証します。
- キャッシュの有効期限:キャッシュがキャッシュされるたびに有効期限を設定します。第 3 層はキャッシュの削除の成功を保証します。
- 必須の Redis マスター ライブラリ チェック:今後キャッシュをチェックするときに、マスターとスレーブの同期に遅延が発生すると同時に、スレーブ キャッシュのメイン ライブラリを強制的にチェックする必要があります。シャーディング クラスター メカニズムによるメイン ライブラリへの負荷。