これはばかげた質問かもしれませんが、何をグーグルで調べてもわかりません。DBからいくつかのデータをフェッチし、このデータをキャッシュするサーバーがあり、リクエストにこのデータが含まれるたびに、DBからではなくキャッシュからデータがフェッチされます。リクエストの処理にかかる時間を短縮します。このキャッシュは変更できます。つまり、一部のキーをキャッシュに追加したり、削除したり、更新したりできます。キャッシュで発生する変更は、DB でも発生します。問題は、サーバーの前にロードバランサーを追加したいトラフィックの急増によるものです。サーバーをもう 1 つ追加するとします。次に、2 つのサーバーに 2 つの異なるキャッシュがあります。最初のサーバー キャッシュに何かが追加された場合、2 番目のサーバー キャッシュにそれを更新するように通知するにはどうすればよいですか??
質問する
371 次
2 に答える
2
最終的にキャッシュをメインの Web サーバー プロセスの外に移動することにした場合は、コンシステント ハッシュを検討することもできます。これは、レプリケートされたキャッシュの代わりになります。
複製されたキャッシュの問題は、キャッシュに参加しているノードの数に反比例してスケーリングされることです。つまり、ノードを追加するとパフォーマンスが低下します。ノード数が少ない場合は問題なく動作します。N 個のノード間でデータを複製する場合 (または、N 個のノードにエビクション メッセージを送信する必要がある場合)、すべての書き込みには、元のノードのキャッシュへの 1 回の書き込みと、他のノードへの N-1 回の書き込みが必要です。
コンシステント ハッシュでは、代わりにハッシュ関数を定義します。これは、格納または取得するデータのキーを入力として受け取り、そのキーのデータをキャッシュする役割を担うクラスター内のサーバーの ID を返します。そのため、各キャッシング サーバーは全体的なキーの一部を担当し、クライアントはルックアップなしで、どのサーバーが検索対象のデータを含むかを判断でき、データと削除メッセージをキャッシング サーバー間で複製する必要がありません。
コンシステント ハッシュの「一貫性」の部分とは、クラスタに追加またはクラスタから削除される新しいサーバーをハッシュ関数が処理する方法を指します。サーバー間のキーの再配布が必要ですが、関数はそのような中断の量を最小限に抑えるように設計されています.
実際には、キャッシュは Web サーバーでインプロセスで実行できるため、実際には専用のキャッシュ クラスターは必要ありません。各Webサーバーは、キーのキャッシュデータを保存する必要がある他のWebサーバーを決定できます。
コンシステント ハッシュは大規模に使用されます。この段階ではやり過ぎかもしれません。ただし、O(N) メッセージング アーキテクチャに固有のスケーラビリティのボトルネックに注意してください。レプリケートされたキャッシュは、最初はおそらく良い考えです。
編集:実際に箱から出して一貫したハッシュを使用する分散キャッシュであるInfinispanを見てください。
于 2013-08-28T11:23:27.317 に答える