キャッシュRedisなどを使用している限り、二重書き込みの整合性の問題に直面するプログラムです。多くのプログラマーはこの問題に陥ります。
どのように答えても、完璧には見えないからです。
まず第一に、私たちが直面しているのは、最初にキャッシュに書き込むかデータベースに書き込むかです。最初にキャッシュに書き込み、次にデータベースに書き込むとします。次に、キャッシュの書き込みが成功し、データベースの書き込みが失敗すると、不整合が発生します。
データベースの書き込みに失敗すると、キャッシュを再度削除すると言うかもしれません。あなたは助けてくれますか、あなたはキャッシュを削除することに成功しますか？言うまでもなく、キャッシュの書き込みが成功した後、データベースが更新される前にキャッシュを読み取るクエリ要求が発生する場合があります。
次に、更新戦略を改善します。最初にキャッシュを削除し、次にデータベースを更新し、更新が成功した後にデータベースを削除します。
この方法がシリアルの場合、論理的には問題ありません。ただし、シリアル化は間違いなく過度のサービス圧力につながるか、崩壊さえします。シリアルに実行されていない場合、キャッシュを削除してデータベースを更新していないと、他のスレッドがDB内の古いデータをキャッシュに読み込みます。次に、DBを更新します。このギャップ期間では、後続のキャッシュの削除操作を再度実行するまで、読み取りキャッシュは古いデータを読み取ります。
最初にキャッシュに書き込み、次にデータベースに書き込むと、このスキームは機能しないと思いますか。次に、2番目の方法を見て、最初にDBを書き込み、キャッシュを書き込みます。
DB書き込みが失敗した場合、キャッシュに書き込む必要はありません。ただし、DB書き込みが成功した場合、キャッシュ書き込みが失敗した場合はどうなりますか？データに再び一貫性がありません。
並行性についてはどうですか？1つはAにクエリ操作を要求し、もう1つはBに更新操作を要求します。次に、次の状況が発生する必要があります。
Aがキャッシュをチェックするように要求されたとき、キャッシュはちょうど失敗しました。したがって、Aはデータベースをチェックして値を取得し、Bに新しい値をデータベースに書き込むように要求し、Bにキャッシュを削除するように要求し、Aに見つかった古い値をキャッシュに書き込むように要求します。
しかし、Facebookがこの種のスキームを採用していると言っても、驚くことはありません。
Facebookもこの問題を知っていますが。このケースは理論的には発生する可能性がありますが、実際には発生する可能性は非常に低い可能性があります。これは、キャッシュが読み取られてキャッシュが無効であり、同時書き込み操作がある場合にこの状態が発生する必要があるためです。実際、データベースの書き込み操作は読み取り操作よりもはるかに遅く、テーブルをロックする必要があります。読み取り操作は書き込み操作の前にデータベース操作に入る必要があり、キャッシュを更新するには書き込み操作よりも遅くなります。これらの条件はすべて満たされています。確率は基本的に大きくありません。
最も重要なことは、このようなことが起こったとしても、Facebookの一部のビジネスにはほとんど影響を与えないということです。ビジネスと戦略の二重のバランスは、建築の真の芸術です。
さらに、前に言ったこと：キャッシュアサイドパターン、リードスルーパターン、ライトスルーパターン、ライトビハインドキャッシングパターンは完全ではありません。
繰り返しますが、強い整合性を確保する必要がある場合は、2PC、3PC、またはPaxosプロトコルを使用して整合性を確保してください。
完璧なテクノロジーはなく、どのテクノロジーにも反論があります。建築は芸術であり、それはあなたがそれをどのようにバランスさせるかに依存します！