キャッシュの一貫性を維持する3つの方法

ラルフワルドエマーソンを信じるなら、愚かな一貫性は気の毒なことかもしれませんが、スケーラブルで成功したエンタープライズレベルのキャッシング戦略を実装することになると、一貫性について愚かなことは何もありません。実際、エンタープライズデータベースの運用を管理する上での最大の課題の1つは、キャッシュの一貫性を維持することです。

そもそもなぜキャッシュを気にするのですか？エンタープライズキャッシュの主な利点は、データにアクセスできる速度と効率です。プライマリデータベースへの各呼び出しは、時間と処理能力の両方の点でコストがかかる可能性がありますが、キャッシュへの呼び出しは非常に高速であり、プライマリデータベースに影響を与えることはありません。

キャッシュの一貫性に対する3つの障害

もちろん、これらの利点は、キャッシュ内のデータ（または複数のキャッシュ）が常にソースデータと同じ値を維持するという基本的な仮定に基づいています。これは簡単な目標のように思えるかもしれませんが、理論的には実際よりも簡単です。実際、それを狂わせる可能性のある3つの落とし穴があります。

1.プライマリデータベースへの変更がキャッシュに反映されない場合

キャッシュを介したデータへのアクセスは、定義上、プライマリデータベースを介したデータへのアクセスよりも高速であるため、特定のアイテムが要求された場合は、最初にキャッシュが参照されます。アイテムがキャッシュに存在すると仮定すると、プライマリデータベースからのアイテムよりもはるかに迅速に返されます。この戦略は、キャッシュアサイドパターンとして知られています。 。デフォルトでは、キャッシュが最初にチェックされます。データがキャッシュにない場合、アプリケーションはプライマリデータベースにクエリを実行し、ユーザーに戻る途中で結果をキャッシュに保存します。

この問題は、プライマリデータベースのデータが変更されたときと、その変更を反映するようにキャッシュが調整されたときとの間のギャップの間に発生します。これは、アプリケーションがキャッシュをチェックする頻度に影響されます。ただし、各チェックにはプロセッサリソースが必要です。同じプロセッサが他の多くの機能やトランザクションを同時に処理している可能性があります。それらのいくつかは、キャッシュを更新するよりも重要です。

課題は、更新のチェックが多すぎるか不十分であるかの間にある一種のGoldilocks領域であるスイートスポットを見つけることです。もちろん、ユーザーがこのギャップの間に廃止されたデータにアクセスしようとすると、そのギャンブルは失われます。

2。キャッシュされた結果の更新に遅延がある場合

この問題は、前の問題と少し重複しています。プライマリデータベースで値が更新されるたびに、メッセージがキャッシュに送信され、変更された値を更新するか、完全に削除するように指示されます。 （後者の場合、次に値が要求されると、プライマリデータベースからアクセスされ、その後キャッシュからアクセスされます。）通常の状況では、この通信は比較的迅速に行われ、キャッシュされたアイテムは順番に更新または削除されます。キャッシュの一貫性を維持するため。

ただし、この変更には処理能力が必要であり、時間がかかります。遅延は、利用可能な処理速度とネットワークスループットの両方の影響を受ける可能性があります。サーバーがキャッシュを更新するためにメッセージが送信されてから、そのメッセージがキャッシュによって受信されて処理されるまでの間に、ユーザーが古いデータにアクセスすることを選択するという不幸があった場合、結果は古いデータになる可能性があります。 、正しくない、またはその両方。

3。キャッシュされたノード間で不整合がある場合

もちろん、Webサイトまたはアプリケーションが大きいほど、キャッシュは1つではなく複数のノードに保存される可能性が高くなります。 プライマリに加えて ノードには、任意の数のレプリカが存在する可能性があります 理想的には、同一のデータを格納しているノード。負荷分散とパフォーマンスの観点から、これは多くの場合理にかなっています。

しかし、データの整合性の観点からは、キャッシュの不整合のさらに別の潜在的な原因が発生します。プライマリデータベースでデータが更新されるたびに、この変更をすべてのレプリカにも反映する必要があります。これらのノードが地理的に配置されている場所とその数によっては、更新プロセスにかなりの時間がかかる場合があります。更新プロセスが進行中の場合でも、変更がまだ行われていないノードにユーザーがアクセスする可能性は十分にあります。繰り返しになりますが、ご想像のとおり、結果はキャッシュの不整合になる可能性があります。

キャッシュの不整合のコスト

キャッシュされたデータベースのすべての利点について、キャッシュの不整合の可能性はおそらくその最も顕著な欠点です。しかし、問題はどれくらい大きいのでしょうか？最終的に、キャッシュの不整合のコストはコンテキストによって異なります。

一部のキャッシュの不整合は、大きな影響なしに発生する可能性があります。たとえば、キャッシュ内の「いいね」の合計がプライマリデータベースの実際の合計と一時的に同期していない場合、一時的な不一致によって問題が発生したり、気付かれたりすることはほとんどありません。

一方、特定の商品の残りの1つのアイテムがまだ在庫にあることをキャッシュにリストし、プライマリデータベースの実際の在庫に残りがないと表示されている場合、結果として生じる競合は顧客を混乱させ、疎外し、ブランドの評判を損なう可能性があります信頼性のために、会社の取引と会計に大混乱をもたらし、極端な場合には、法的な危険にさらされることさえあります。

不整合に対抗する3つの方法

幸いなことに、上記のキャッシュの不整合の潜在的な原因のそれぞれについて、対応する数のソリューションがあります。

1。キャッシュの無効化

キャッシュを無効にすると、プライマリデータベースで値が更新されるたびに、対応するキーを持つ各キャッシュアイテムが1つまたは複数のキャッシュから自動的に削除されます。キャッシュの無効化はおそらく「ブルートフォースアプローチ」と見なすことができますが、利点は、プライマリデータベース自体への書き込みが2回以上ではなく、1回だけで済むことです。

2。ライトスルーキャッシュ

この場合、ライトスルー戦略を使用してプライマリデータベースを更新してキャッシュを削除するのではなく、アプリケーションがキャッシュを更新してから、キャッシュがプライマリデータベースを同期的に更新します。つまり、プライマリデータベースに依存して更新を開始するのではなく、キャッシュが独自の整合性を維持し、変更内容をプライマリデータベースに配信します。

3。ライトビハインドキャッシング

残念ながら、2回の書き込みで実際に間違いが発生する場合があります。ライトスルーキャッシュ戦略の欠点の1つは、キャッシュとプライマリデータベースの両方を更新するには、最初にキャッシュに対して、次にプライマリデータベースに対して、2つの時間のかかるプロセッサ負荷の変更が必要になることです。

後書きとして知られる別の戦略 、最初にキャッシュのみを更新し、後でプライマリデータベースを更新することで、この問題を回避します。もちろん、プライマリデータベースも更新する必要があり、早ければ早いほどよいですが、この場合、ユーザーは2回の書き込みの「コスト」を支払う必要はありません。プライマリデータベースへの2回目の書き込みは、パフォーマンスを低下させる可能性が低いときに、非同期で舞台裏で行われます（したがって、名前は後書き）。

Redisエンタープライズが救助に

キャッシュの無効化に加えて、ライトスルーおよびライトビハインドキャッシングは、キャッシュの一貫性を実現するのに役立つ多くのシナリオに対処できます。しかし、問題の答えを見つけることは、それを実装することと同じではありません。

Redis Enterpriseのアクティブ-アクティブジオ複製により、複数のプライマリが可能になり、ますます重い負荷を巧みに処理できるようになります。 active-activeという名前は、データベースの各インスタンスが任意のキーに対して読み取り操作と書き込み操作の両方を受け入れることができるという事実を指します。各データベースインスタンスは、どれだけ離れていても、ネットワーク上のピアです。つまり、いずれかのインスタンスへの書き込みが発生すると、そのノードはネットワーク上の他のすべてのインスタンスにメッセージを自動的に送信し、キャッシュ内の内容が変更されたことを示し、すべてのインスタンスがキャッシュされたデータの一貫したセットを保持するようにします。

Redis Enterpriseの独自のアクティブ-アクティブジオ複製は、キャッシュの不整合につながる可能性のある潜在的な書き込みの競合に対処するように設計された高度なアルゴリズムを採用しています。これらのアルゴリズムは、競合のないレプリケートされたデータ型（CRDT）に基づいており、複数のレプリカからの書き込みを、一貫性を効果的に維持する方法でマージできるようにします。

ホブゴブリンのためのやったー！

キャッシュの一貫性を維持するという課題は、アーキテクチャが成長するにつれてより複雑になり、ますます重要になるため、ビジネスに必要な一貫性と顧客が期待する一貫性を確実に提供するには、エンタープライズレベルのキャッシュソリューションが必要です。

エマソンに関する限り、一貫性はホブゴブリンだったかもしれませんが、エンタープライズレベルのデータベースキャッシングに関しては絶対に不可欠です。そのため、RedisEnterpriseを選択するのが賢明です。そうしないのはばかげているでしょう。

キャッシングの全体像を把握します。 Redisを使用した大規模なキャッシュを読む 、リー・アチソン作。