Shared Cache - sprawdzone metody unieważniania

14

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?

lurkerbelow
źródło

Odpowiedzi:

12
  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.
    • 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”.
Vaughandroid
źródło
Baqueta, dziękuję za odpowiedź. Doceniam to.
lurkerbelow
@lurkerbelow Cieszę się, że mogę pomóc.
vaughandroid
2

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.

neo
źródło