2012-10-08 15 views

Odpowiedz

17

S3 nie wysyła żadnych informacji o unieważnieniu do CloudFront. Domyślnie CloudFront przechowuje informacje do maksymalnego czasu określonego przez nagłówki kontroli pamięci podręcznej, które zostały ustawione, gdy pobierze dane z punktu początkowego (może usunąć elementy z pamięci podręcznej wcześniej, jeśli ma na to ochotę).

Możesz unieważnić wpisy pamięci podręcznej, tworząc partię unieważniającą. Będzie to kosztować twoje pieniądze: pierwsze 1000 próśb na miesiąc jest darmowe, ale poza tym kosztuje 0,005 $ za każde żądanie - jeśli unieważniasz 1000 plików dziennie, kosztowałoby to 150 $ miesięcznie (chyba że możesz skorzystać z funkcji wieloznacznej). Możesz oczywiście wywołać to w odpowiedzi na zdarzenie s3 za pomocą funkcji Amazon Lambda.

Innym podejściem jest użycie innej ścieżki, gdy obiekt się zmienia (w efekcie generacyjny klucz pamięci podręcznej). Podobnie możesz dodać parametr zapytania do adresu URL i zmienić ten parametr zapytania, gdy chcesz, aby w chmurze pojawiła się nowa kopia (w tym celu musisz poinformować CloudFront, aby użył parametrów ciągu zapytania - domyślnie ignoruje je).

Innym sposobem, jeśli tylko nieczęsto (ale duże) zmiany, jest po prostu utworzenie nowej dystrybucji w chmurze.

+0

Miałem okropne uczucie, że tak było. Wygląda na to, że przegapili jakąś funkcję. Czy możesz podać odniesienie do tego, czy też nie jest ono określone? Dzięki. – Joe

+0

Byłoby błędne założenie, że przesłanie nowej wersji do S3 oznacza, że ​​chcesz wyczyścić pamięć podręczną w CloudFront. Tak, może to być zachowanie, którego szukasz, ale byłoby to aroganckie z AWS, aby "ćwiczyć", że to jest to, czego chcesz. W wielu przypadkach będę zapisywać zawartość w pamięci podręcznej w CloudFront, wiedząc, że wygasa ona zgodnie z moimi ustawieniami i będzie przesuwać zaktualizowaną zawartość w S3 z wyprzedzeniem. W moim przypadku automatyczne unieważnienie jest przeciwieństwem tego, czego chcę. –

+0

Nie zakładam, ale wydaje się, że był to użyteczny parametr. – Joe

3

O ile mi wiadomo, wszystkie CDN działają w ten sposób.

To dlatego zazwyczaj używasz czegoś w rodzaju aktywów wersji na CDN. Nie używałbym foo.ext?x.y.z, ponieważ w niektórych przeglądarkach i serwerach proxy istniało coś, co nie powodowało buforowania zasobów o wartości ?QUERY_STRING.

Ogólnie może chcesz sprawdzić to: https://developers.google.com/speed/docs/best-practices/caching

Zawiera on wiele najlepszych praktyk i idzie w szczegóły, co robić i jak to działa.

Jeśli chodzi o S3 i Cloudfront, nie jestem zaznajomiony z unieważnieniem pamięci podręcznej, ale to, co powiedział Frederick Cheung, jest poprawne.

Niektórzy dostawcy umożliwiają również bezpośrednie wyczyszczenie pamięci podręcznej, ale ze względu na naturę CDN zmiany te prawie nigdy nie są natychmiastowe. Inną metodą jest ustawienie mniejszej wartości TTL (nagłówki wygasania), aby zasoby były odświeżane częściej. Ale myślę, że to także pokonuje cel CDN.

W naszym przypadku (Edgecast) unieważnienie pamięci podręcznej jest możliwe (proces ręczny) i bezpłatne, ale rzadko to robimy, ponieważ odpowiednio dostosowujemy nasze zasoby.

+0

Dzięki za odpowiedź. Znam zarówno S3, jak i CloudFront (i inne), pytałem o specyficzną integrację między tymi dwoma produktami Amazon. – Joe

+0

OK, nie zrozumiałem tego specjalnie. Tak więc - moja rekomendacja będzie dotyczyć zasobów wciąż wersji i ustawienia nagłówka 'Cache-Control' na obiekcie. – Till

+0

Dzięki temu wygląda na to, że będę musiał to obejść. Nadal uważam, że jest to niezbędna i łatwa do implementacji funkcja, którą przegapili. – Joe