Shared Cache - sprawdzone metody unieważniania

Chciałbym wiedzieć, jakie byłoby lepsze podejście do unieważnienia / aktualizacji obiektów pamięci podręcznej.

Wymagania wstępne

• Posiadanie zdalnego serwera memcached (służącego jako pamięć podręczna dla wielu aplikacji)
• Wszystkie serwery są hostowane przez lazur (regiony koligacji, te same centra danych)
• Rozmiar obiektu pamięci podręcznej wynosi od 200 bajtów do 50 kilobajtów

Podejście 1 (zapisz w pamięci podręcznej jak najszybciej)

1. Obiekt A jest tworzony -> przechowuj w bazie danych i przechowuj w pamięci podręcznej
2. Obiekt A żądany przez klienta -> sprawdź, czy pamięć podręczna istnieje, w przeciwnym razie pobierz z bazy danych i zapisz w pamięci podręcznej
3. Obiekt A zostanie zaktualizowany -> przechowuj w bazie danych, przechowuj w pamięci podręcznej

Podejście 1 wydaje się prostsze. Jeśli coś zostanie utworzone, umieść w pamięci podręcznej jak najszybciej. Niezależnie od tego ktoś będzie tego potrzebował.

Podejście 2 (leniwy sklep z pamięcią podręczną)

1. Obiekt A jest tworzony -> przechowuj w bazie danych
2. Obiekt A żądany przez klienta -> sprawdź, czy pamięć podręczna istnieje, w przeciwnym razie pobierz z bazy danych i zapisz w pamięci podręcznej
3. Obiekt A zostanie zaktualizowany -> zapisz w bazie danych, usuń klucz w pamięci podręcznej

Podejście 2 wydaje się bardziej świadome pamięci. W tym podejściu tylko żądane elementy trafiają do pamięci podręcznej.

Pytanie 1: Jakie podejście byłoby lepsze w kontekście wydajności? Pamięć ani procesor jeszcze się nie liczą.

Pytanie 2: Czy moje myśli są rodzajem przedwczesnej optymalizacji?

Pytanie 3: Jakieś inne przemyślenia? Inne podejścia?

1. Jest nieodwracalny, z wyjątkiem tego, że zależy. Istnieje wiele czynników, które określą, które podejście będzie najlepsze w twoim przypadku, np .: Czy to normalne, że tworzone obiekty są pobierane wkrótce po ich utworzeniu? Jaki jest stosunek aktualizacji do dostępu?
2. Re. decydowanie, że potrzebujesz pamięci podręcznej: jeśli optymalizujesz bez danych, to tak, jest to technicznie przedwczesna optymalizacja. Mówię technicznie, ponieważ doświadczenie / konwencjonalna mądrość może ci powiedzieć, że będziesz potrzebować jakiegoś bufora. Re. decydowanie o tym, jak pamięć podręczna będzie najlepiej działać: tak, to zdecydowanie przedwczesna optymalizacja.
3. • Optymalizacja często nie polega na znalezieniu najlepszego / najbardziej optymalnego rozwiązania. Powinien wyglądać następująco:
     1. Znajdź wąskie gardła w systemie.
     2. Znajdź, gdzie możesz zrobić największą różnicę przy najmniejszym nakładzie pracy.
     3. Wykonuj najmniej pracy!
     4. Czy to jest wystarczająco szybkie? Jeśli nie, przejdź do # 1.
     5. Gotowy!
   • Szczerze mówiąc, żadne z opisywanych przez ciebie podejść nie jest skomplikowane. Dlaczego nie wdrożyć obu i zobaczyć, który działa najlepiej?
   • Krok 3 w podejściu nr 2 można zmienić na „Obiekt A zostanie zaktualizowany -> zapisz w bazie danych, zaktualizuj wpis w pamięci podręcznej”.

memcached zarządza obiektami z własnymi zasadami, który buforowany obiekt wygasłby, gdyby nikt nie miał do niego dostępu lub w pamięci zabrakło pamięci. Dlatego twoje pierwsze podejście nie jest dobrym pomysłem, ponieważ twój obiekt w memcached wciąż byłby unieważniany z powodu braku pamięci podczas tworzenia obiektów.

Pytanie 1 Podejście 2 byłoby lepsze pod względem wydajności, ponieważ nie wysyła obiektu do pamięci memcache, chociaż poprawa wydajności jest bardzo niewielka.

Q2 Trudno powiedzieć. Załóżmy, że znasz wąskie gardło i opracuj podejście, które nie byłoby przedwczesne.

Pytanie 3 Istnieją inne podejścia, takie jak pamięć podręczna tylko w pamięci podręcznej.