MySQLキャッシュデータベースプロセスとしてredisを使用します。
キャッシュされたデータを最初に読み取ります。キャッシュされたデータがある場合、結果はすぐに返されます。データがない場合、データはデータベースから読み取られ、読み取られたデータはキャッシュに同期されて、次の読み取り要求の戻りデータを提供します。
これにより、データベースへの負荷を軽減できますが、データが変更および削除された場合、マルチスレッドの高い同時実行性シナリオでキャッシュとデータベースデータの間に不整合が発生する可能性があります。解決方法
シーン1：
この問題の根本的な原因は、読み取りデータと書き込みデータの要求が並行している場合、データベースとキャッシュデータは更新されていますが、アクセスされたデータはまだ古いデータであり、ダーティな読み取りデータが表示されていることです。読み取り要求プロセスに問題がないと想定し、書き込み要求プロセスを分析します。最適化
- 最初にキャッシュを更新してから、データベースを更新します
この計画は間違いなく機能しません。その理由は、更新キャッシュが成功し、更新データベースが異常なため、キャッシュデータがデータベースデータと完全に一致しないためです。
- 最初にデータベースを更新してから、キャッシュを更新します
このソリューションも機能せず、原則は最初のソリューションと同じです。データベースの更新は成功し、キャッシュの更新は失敗し、データの不整合の問題も発生します。
解決する
書き込み要求が発生した場合、最初にキャッシュデータを削除してからデータベースを更新できます。これにより、データベースの更新が失敗した場合でも、キャッシュの削除が失敗した場合でも、キャッシュは常にデータベースと一貫性があります。キャッシュを削除してからデータベースを更新するまでの時間はミリ秒単位で計算でき、通常の同時実行ではほとんど影響がないため、この種のスキームは一般的に数万人の同時操作に対応できます。
シーン2：
何億もの同時アクセスにより、キャッシュとデータ間の不整合が生じます。
解決する
解決策1：読み取りと書き込みの分離
読み取りリクエストはキャッシュにのみアクセスし、書き込みリクエストはデータベースとキャッシュのみを変更します
データベースとキャッシュを変更する書き込みリクエストはトランザクションアクションです。データベースの更新が成功し、キャッシュの更新が失敗した場合、データベースはロールバックされ、キャッシュとデータベースデータの強い整合性が確保されます。このようにして、読み取りと書き込みの分離が実現されます。これにより、読み取りの応答速度が向上するだけでなく、書き込み要求がキャッシュとデータベースの一貫性の原因となります。成功した書き込み要求のみがキャッシュの内容に影響し、適時性が大幅に向上します。
解決策2：キューストレージリクエスト
シナリオ1のソリューションに従います。その欠陥を解決するために、キューが追加されます。書き込みリクエストが発生すると、書き込みリクエストはキューに配置されます。キューは、書き込みリクエストを統一された方法で管理します。書き込みリクエストが正常に処理されると、キューから削除されます。読み取り要求が来たら、対応する書き込み要求があるかどうかをキューで確認し、ある場合はキューに入れて書き込み要求が実行されるのを待ってから、読み取り要求を実行します。リクエストがブロックされないようにするには、タイムアウトメカニズムまたは有効期限メカニズムを設定します。
シーン3：
アクセス量が多く、プロセッサの処理が遅すぎて、キュー内のリクエスト数がますます増えており、クエリの効率に影響します。
解決する：
分散データベースクラスターとメッセージキュー（kafkaなど）