Redis może zrobić wszystko, co zapewnia Memcached (pamięć podręczna LRU, wygaśnięcie elementu, a teraz grupowanie w wersji 3.x +, obecnie w wersji beta) lub za pomocą narzędzi takich jak twemproxy. Wydajność też jest podobna. Co więcej, Redis dodaje trwałość, dzięki czemu nie trzeba rozgrzewać pamięci podręcznej w przypadku ponownego uruchomienia serwera.

Odniesienie do niektórych starych odpowiedzi, które porównują Redis i Memcache, z których niektóre preferują Redis jako zamiennik Memcache (jeśli jest już obecny w stosie):

• Memcached czy Redis?

• Czy memcached to dinozaur w porównaniu do Redis?

• Redis i Memcache czy tylko Redis?

Mimo to, badając stosy dużych firm internetowych, takich jak Instagram, Pinterest, Twitter itp., Odkryłem, że używają one zarówno Memcached, jak i Redis do różnych celów, a nie Redis do podstawowego buforowania. Podstawowa pamięć podręczna jest nadal Memcached, a Redis jest używana do jej logicznego buforowania opartego na strukturach danych.

Od 2014 roku, dlaczego memcached nadal jest wart dodania jako dodatkowego składnika do twojego stosu, skoro masz już komponent Redis, który może zrobić wszystko, co może memcached? Jakie są korzystne punkty, które skłaniają architektów / inżynierów do nadal uwzględniania memcached poza już istniejącym Redisem?

Aktualizacja :

W przypadku naszych platform całkowicie odrzuciliśmy Memcached i używamy redis do prostych i logicznych wymagań dotyczących buforowania. Wysoka wydajność, elastyczność i niezawodność.

Kilka przykładowych scenariuszy:

• Wyświetlanie wszystkich kluczy w pamięci podręcznej według określonego wzorca i odczytywanie lub usuwanie ich wartości. Bardzo łatwe w redis, nie do wykonania (łatwe) w memcached.
• Przechowywanie ładunku większego niż 1 MB, łatwe do wykonania w redis, wymaga zmian w rozmiarze płyty w memcached, co ma własne efekty uboczne związane z wydajnością.
• Łatwe migawki aktualnej zawartości pamięci podręcznej
• Klaster Redis jest również gotowy do produkcji wraz ze sterownikami językowymi, dlatego też wdrożenie w klastrze jest łatwe.

Głównym powodem, dla którego widzę dziś zastosowanie memcached w porównaniu z Redis, jest doskonała wydajność pamięci, którą powinieneś być w stanie uzyskać dzięki buforowaniu zwykłych fragmentów HTML (lub podobnych aplikacji). Jeśli chcesz przechowywać różne pola obiektów w różnych kluczach memcached, skróty Redis będą bardziej wydajne w pamięci, ale gdy masz dużą liczbę par kluczy -> simple_string, memcached powinien być w stanie dać ci więcej elementów megabajt.

Inne zalety memcached:

• Jest to bardzo prosty fragment kodu, więc jeśli potrzebujesz tylko funkcjonalności, którą zapewnia, jest to chyba rozsądna alternatywa, ale nigdy nie użyłem go w produkcji.
• Jest wielowątkowy, więc jeśli potrzebujesz skalować w konfiguracji single-box, 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 pośrednictwem struktur danych Redis.

Porównanie Redis LRU i memcached LRU.

Zarówno memcached, jak i Redis nie wykonują prawdziwych eksmisji LRU, a jedynie przybliżenie tego.

Eksmisja Memcache jest zależna od klasy rozmiaru i zależy od szczegółów implementacji alokatora płyty. Na przykład, jeśli chcesz dodać element, który pasuje do danej klasy rozmiaru, memcached spróbuje usunąć elementy tej klasy, które wygasły / nie były ostatnio używane, zamiast tego spróbować globalnej próby zrozumienia, czym jest obiekt, niezależnie od jego rozmiar, który jest najlepszym kandydatem.

Zamiast tego Redis próbuje wybrać dobry obiekt jako kandydata do eksmisji po osiągnięciu maxmemorylimitu, patrząc na wszystkie obiekty, niezależnie od klasy wielkości, ale jest w stanie zapewnić tylko w przybliżeniu dobry obiekt, a nie najlepszy obiekt z większym bezczynnością czas.

Sposób, w jaki Redis to robi, polega na próbkowaniu kilku obiektów, wybierając ten, który był bezczynny (bez dostępu) przez najdłuższy czas. Od wersji Redis 3.0 (obecnie w wersji beta) algorytm został ulepszony i bierze również dobre pule kandydatów z eksmisji, więc przybliżenie uległo poprawie. W dokumentacji Redis można znaleźć opis i wykresy ze szczegółowymi informacjami o tym, jak to działa .

Dlaczego memcached ma lepszy ślad 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ą skojarzony typ, kodowanie, zliczanie referencji do zarządzania pamięcią. To sprawia, że ​​wewnętrzna struktura Redis 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 działać wydajniej pod kątem 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 Hash reprezentujący obiekt jest przechowywany wewnętrznie nie w tabeli skrótów, ale jako binarny unikalny obiekt blob. Zatem ustawienie wielu pól na obiekt w hash jest bardziej wydajne niż przechowywanie N oddzielnych kluczy w memcached.

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 ani 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 do niszczenia obiektów, gdy pamięć podręczna jest unieważniona, w celu późniejszego odtworzenia jej 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 publikowane w witrynie Hacker News w celu zapełnienia sekcji „Najnowsze” witryny. To, co robisz w Redis, to tworzenie listy (ograniczonej do pozycji M) z wstawionymi najnowszymi wiadomościami. Jeśli używasz innego magazynu dla swoich danych, a Redis jako pamięci podręcznej, wystarczy wypełnić oba widoki (Redis i DB), gdy zostanie opublikowany nowy element. Nie ma unieważnienia pamięci podręcznej.

Jednak aplikacja może zawsze mieć logikę, więc jeśli okaże się, że lista Redis jest pusta, na przykład po uruchomieniu, początkowy widok można ponownie utworzyć z bazy danych.

Korzystając z inteligentnego buforowania, można wykonać buforowanie w Redis w bardziej efektywny sposób w porównaniu z memcached, ale nie wszystkie problemy są odpowiednie dla tego wzorca. Na przykład buforowanie fragmentów HTML może nie przynosić korzyści z tej techniki.

Nawyki są trudne do przełamania :)

Poważnie, istnieją dwa główne powody - według mojego rozumienia - dlaczego Memcached jest nadal używany:

1. Legacy - istnieją programiści, którzy dobrze znają Memcached, a także aplikacje, które ją obsługują. Oznacza to również, że jest to dojrzała i sprawdzona technologia.
2. Skalowanie - standardowy Memcached jest łatwo skalowalny w poziomie, podczas gdy Redis (do i wyłączając wkrótce wydaną wersję v3) wymaga więcej pracy w tym celu (tj. Sharding).

Jednak:

1. Re. starsze - biorąc pod uwagę solidność Redis (struktury danych, polecenia, trwałość ...), jest aktywnie rozwijane i klienci w każdym możliwym języku - nowe aplikacje są zwykle tworzone za jego pomocą.
2. Ponowne skalowanie - oprócz nadchodzącej wersji 3, istnieją rozwiązania, które mogą znacznie ułatwić skalowanie. Na przykład Redis Cloud oferuje bezproblemowe skalowanie bez utraty danych lub przerw w świadczeniu usług. Innym popularnym podejściem do skalowania / dzielenia na fragmenty Redis jest dwa proxy .