4

いくつかのロードバランサーの背後にあるファームでホストされている MVC 4 アプリケーションで System.Web.Optimization を使用しています。一部のクライアントは、キャッシュ プロキシを介してこの Web にアクセスします。私たちは彼らのプロキシを制御できません。

MVC バンドルは、バンドル内のファイルに固有のバンドル スクリプト参照の後ろに ?v={hash} url パラメーターを追加するという点でスマートです。そのため、バンドル内のファイルが変更されるたびに、ハッシュも変更され、ファイルが再度要求されます。

問題は、ハッシュが現在のファイルと一致しない場合、どうすればバンドルの配信を防ぐことができるかということです。

通常の展開プロセスは次のとおりです。

  • サーバー 1 をロード バランサーから外す
  • サーバー 1 の更新
  • Server 1 でのテスト
  • サーバー 1 をファームに戻す
  • 一度に 1 つずつ、ファーム内の他のすべてのサーバーで洗い流して繰り返します

最後のステップで問題があります。たとえば、サーバー 1 と 2 は既に更新されており、サーバー 3 は現在更新中であり (ファーム内にはありません)、サーバー 4 から 8 はまだ更新されていません。

現在、約の可能性があります。1/4、そのサーバー 1 または 2 が要求に応答します。どちらも新しいスクリプトを持っているため、バンドル URL の背後にあるハッシュは、サーバー 4-8 が使用するハッシュとは異なります。

それにもかかわらず、約の可能性があります。3/4、更新されたハッシュを使用したこのスクリプトに対する正確な次の要求は、まだ更新されていないサーバーの 1 つに負荷分散されます。url パラメータのハッシュが古いファイルの内容と一致しない場合でも、バンドルは古い内容で配信されます。これは、この特定のクライアントにとって悪いことです。

より悪いシナリオでは、クライアント側のプロキシが古いスクリプトを新しい URL の下に新しいハッシュでキャッシュするようになり、この問題がそのキャッシュの背後にある他のすべてのクライアントにも引き継がれます。

間違ったコンテンツがキャッシュされないように、間違ったハッシュを持つリクエストに 404 で応答するようにバンドルに指示するにはどうすればよいですか?

4

1 に答える 1

0

現在、ハッシュはクライアントのバストをキャッシュするためにのみ使用されています。サーバーはこれを完全に無視し、バンドルを提供するだけです。

幸いなことに、バンドルの実際のコンテンツを使用してバンドルハッシュを計算するため、クライアントがバンドルの「間違った」バージョンをキャッシュする方法はありません。したがって、サーバーにまだファイルの混合/古いバージョンがある場合、ハッシュは最終的に更新されたときに変更されます。

残念ながら、サーバーのあるファームの状態が異なる場合、この状況を回避する方法については、頭のてっぺんから回避策を見つけることができません。

于 2013-02-06T19:00:06.310 に答える