分散キャッシングでのローカルキャッシュとリモートキャッシュの同期
分散キャッシュでは、キャッシュのサブセットはローカルに保持され、残りはリモートに保持されます。
- get操作では、エントリがローカルで使用できない場合、リモートキャッシュが使用され、エントリがローカルキャッシュに追加されます。
- put操作では、ローカルキャッシュとリモートキャッシュの両方が更新されます。クラスタ内の他のノードも、ローカルキャッシュを無効にするように通知する必要があります。
ノードが相互に認識していないと仮定して、自分で実装の場合、これを実現する最も簡単な方法は何ですか。
編集私の現在の実装は次のようになります：
- 各キャッシュエントリにはタイムスタンプが含まれています。
- Put操作はローカルキャッシュとリモートキャッシュを更新します
- Get操作は、ローカルキャッシュ、次にリモートキャッシュを試行します
- 各ノードのバックグラウンドスレッドは、ローカルキャッシュのエントリごとにリモートキャッシュを定期的にチェックします。リモートのタイムスタンプが新しい場合は、ローカルを上書きします。リモートでエントリが見つからない場合は、ローカルから削除します。
焦点を当てたいと思うかもしれない問題は、リモートキャッシュの更新を運ぶローカルキャッシュメッセージをいつ送信するかです。一方では、変更されたアイテムごとに、他のすべてのキャッシュにメッセージを送信できます。これにより、タイムリーな更新が保証されますが、多くの更新メッセージが存在する可能性があります。一方、ローカルキャッシュは、アイテムを使用する直前（および同じ要求からの特定の時間枠の後）にアイテムが有効かどうかを確認し、リモートキャッシュに要求できます。別のオプションとして、いくつかの変更されたアイテムの更新を定期的に送信できます。
最適な戦略は、構築するシステムによって異なります。戦略は、更新の頻度、更新メッセージによって生成されるトラフィック、更新のオーバーヘッド、欠落している更新の重要度など、いくつかの要因のバランスである可能性があります。
キャッシュの項目は、アクセスに関して頻繁に変化しますか？ローカルキャッシュはいくつありますか？変更は、各ローカルキャッシュ、これらのいくつか、すべて、またはリモートキャッシュから発生しますか？
残念ながら、同期ポイントが1つでない限り、キャッシュに最新のデータが含まれることを保証することはできないと思います。
ただし、単一ポイントを作成すると、すべてが最初にそこに移動する必要があるため、パフォーマンスの問題が発生します。分散システムの場合は、ネットワーク呼び出しとパフォーマンスのボトルネックになります。
これを回避するためのより良い方法は、アナリストにプッシュバックして、データが変更される可能性があるときに可能な限り最新のデータを取得する必要がある場合、キャッシュはオプションではないことを述べることです。代わりに、より高速なネットワークとハードウェアが必要です。これは、開発者に実際には機能しないカスタムキャッシュソリューションをコーディングさせるよりも多くの要因が安価です。