-1

Amazon S3 バケット、cloudinary キャッシュ、fastly キャッシュを使用しています。これらを組み合わせることで、必要な形状、サイズ、またはその他の変換の画像を非常に高速に提供します。ただし、パージ要求は異なる速度で伝播されます。

カスケード配置は次のとおりです。

  • 画像がリクエストされると、Fastly はその画像をキャッシュから提供しようとします。
  • 画像がない場合、Fastly は Cloudinary にその画像を要求します。
  • Cloudinary は、そのキャッシュから画像サーバーを提供しようとします。
  • 画像が存在しない場合、Cloudinary は、要求された画像に変換パラメーターが関連付けられているかどうかを確認します。
  • 変換パラメータを見つけた後、Cloudinary はキャッシュ内の変換されていないバージョンの画像を見つけて、変換を適用しようとします。
  • 変換されていない画像がない場合、Cloudinary は S3 バケットからそれをリクエストします。
  • その後、Cloudinary は変換を適用し、元のバージョンと変換されたバージョンの両方をキャッシュします。
  • Cloudinary は、変換された画像を Fastly に提供します。
  • 変換された画像をすばやくキャッシュして提供します。

画像とその画像のすべての変換されたバージョン (派生物) をすべてのサービスから完全に削除したいと考えています。Cloudinary が DELETE 要求をすべてのサーバーに伝達するのに 1 時間かかります。

最初に S3 で削除し、次に Cloudinary で削除し、最後にすばやくパージするのが最善であることがわかりました。ただし、パージ呼び出しを 1 時間遅らせるにはどうすればよいでしょうか? この状況で、プログラム的に言えば、ベストプラクティスは何ですか?

4

1 に答える 1

0

そのソリューションの一部として、Cloudinary は Akamai を介して CDN サービスを提供します (他の CDN への統合も可能です)。

イメージは、最初の配信後、パージが要求されるまで CDN にキャッシュされます。すべての CDN ノードへの伝播には時間がかかり、最大 1 時間かかる場合がありますが、通常は数分しかかかりません。

2 つの CDN レイヤー間の調整は非常に複雑な作業であるため、特に無効化が一般的に必要な場合は、Cloudinary の前に独自の CDN を使用しないことをお勧めします。

于 2016-08-17T12:51:08.057 に答える