Głównym powodem, dla którego dzisiaj widzę przypadek użycia memcached nad Redis, jest lepsza wydajność pamięci, którą powinieneś być w stanie uzyskać dzięki zwykłemu Buforowanie fragmentów HTML (lub podobnych aplikacji). Jeśli potrzebujesz przechowywać różne pola swoich obiektów w różnych kluczach memcached, skróty Redis będą bardziej wydajne pod względem pamięci, ale gdy masz dużą liczbę par klucz -> simple_string, memcached powinien być w stanie dać ci więcej elementów na megabajtów.
Inne rzeczy, które są dobre na temat memcached:
- To bardzo prosty fragment kodu, więc jeśli potrzebujesz tylko funkcjonalności, którą zapewnia, jest to rozsądna alternatywa, jak sądzę, ale nigdy nie używałem jej w produkcji.
- Jest wielowątkowy, więc jeśli potrzebujesz skalować w konfiguracji jednoelementowej, jest to dobra rzecz i musisz rozmawiać tylko z jedną instancją.
Uważam, że Redis jako pamięć podręczna ma coraz większy sens, gdy ludzie przechodzą w kierunku inteligentnego buforowania lub gdy próbują zachować strukturę danych w pamięci podręcznej za pomocą struktur danych Redis.
Porównanie między Redis LRU i memcached LRU.
Zarówno memcached, jak i Redis nie wykonują prawdziwych eksmisji LRU, a jedynie ich przybliżenie.
Eksmisja Memcache jest klasą rozmiaru i zależy od szczegółów implementacji jej alokatora płyt. Na przykład, jeśli chcesz dodać element, który pasuje do danej klasy rozmiaru, memcached spróbuje usunąć wygasłe / nieużywane ostatnio elementy w tej klasie, zamiast spróbować globalną próbę zrozumienia, czym jest obiekt, niezależnie od jego rozmiar, który jest najlepszym kandydatem.
Redis zamiast tego próbuje wybrać dobry obiekt jako kandydata do eksmisji, gdy maxmemory limit został osiągnięty, patrząc na wszystkie obiekty, niezależnie od klasy rozmiaru, ale jest w stanie zapewnić tylko w przybliżeniu dobry obiekt, a nie najlepszy obiekt z dłuższym czasem bezczynności.
Sposób, w jaki Redis to robi, polega na próbkowaniu kilku obiektów, wybieraniu tego, który był bezczynny (brak dostępu) przez najdłuższy czas. Od Redis 3.0 (obecnie w wersji beta) algorytm został ulepszony, a także przyjmuje dobre pule kandydatów między eksmisjami, więc przybliżenie zostało ulepszone. W dokumentacji Redisa można znaleźć opis i wykresy ze szczegółowym opisem tego, jak to działa.
Dlaczego memcached ma lepsze zużycie pamięci niż Redis dla prostych map ciągów -> ciągów.
Redis jest bardziej złożonym oprogramowaniem, więc wartości w Redis są przechowywane w sposób bardziej podobny do obiektów w języku programowania wysokiego poziomu:mają powiązany typ, kodowanie, zliczanie odwołań do zarządzania pamięcią. To sprawia, że wewnętrzna struktura Redisa jest dobra i łatwa w zarządzaniu, ale ma narzut w porównaniu z memcached, który zajmuje się tylko ciągami.
Kiedy Redis zaczyna być bardziej wydajny pod względem pamięci
Redis jest w stanie przechowywać małe zagregowane typy danych w specjalny sposób oszczędzający pamięć. Na przykład mały skrót Redis reprezentujący obiekt jest przechowywany wewnętrznie nie w tabeli skrótów, ale jako binarny unikalny obiekt blob. Tak więc ustawienie wielu pól na obiekt w hashu jest bardziej wydajne niż przechowywanie N oddzielnych kluczy w pamięci podręcznej.
W rzeczywistości możesz przechowywać obiekt w memcached jako pojedynczy obiekt blob JSON (lub zakodowany binarnie), ale w przeciwieństwie do Redis, nie pozwoli to na pobieranie lub aktualizowanie niezależnych pól.
Zaleta Redis w kontekście inteligentnego buforowania.
Ze względu na struktury danych Redis, zwykły wzorzec używany w memcached, polegający na niszczeniu obiektów, gdy pamięć podręczna jest unieważniona, aby później odtworzyć ją z bazy danych, jest prymitywnym sposobem korzystania z Redis.
Na przykład wyobraź sobie, że musisz zapisać w pamięci podręcznej najnowsze wiadomości N opublikowane w Hacker News, aby wypełnić sekcję „Najnowsze” witryny. To, co robisz z Redis, to pobranie listy (ograniczonej do M elementów) z wstawionymi najnowszymi wiadomościami. Jeśli używasz innego sklepu dla swoich danych, a Redis jako pamięci podręcznej, wystarczy wypełnić oba widoki (Redis i DB) po wysłaniu nowej pozycji. Nie ma unieważnienia pamięci podręcznej.
Jednak aplikacja zawsze może mieć logikę, więc jeśli lista Redis okaże się pusta, na przykład po uruchomieniu, początkowy widok można ponownie utworzyć z bazy danych.
Korzystając z inteligentnego buforowania, możliwe jest wykonanie buforowania z Redis w bardziej wydajny sposób w porównaniu do memcached, ale nie wszystkie problemy są odpowiednie dla tego wzorca. Na przykład buforowanie fragmentów HTML może nie korzystać z tej techniki.
