Redis i Memcache czy tylko Redis?


85

Używam memcached do buforowania w mojej aplikacji Rails 3 za pośrednictwem prostego Rails.cacheinterfejsu, a teraz chciałbym wykonać pewne przetwarzanie zadań w tle za pomocą redis i resque.

Myślę, że są na tyle różne, że uzasadniają używanie obu. Jednak na heroku obowiązują oddzielne opłaty za używanie memcached i redis. Czy ma sens używanie obu, czy też powinienem przejść na używanie tylko redis?

Lubię używać memcached do buforowania, ponieważ ostatnio używane klucze są automatycznie wypychane z pamięci podręcznej i nie potrzebuję danych pamięci podręcznej, aby zachować. Redis jest dla mnie w większości nowy, ale rozumiem, że domyślnie jest trwały i że klucze nie wygasają automatycznie z pamięci podręcznej.

EDYCJA: Po prostu chciałem wyjaśnić moje pytanie. Wiem, że można używać tylko Redis zamiast obu. Chyba po prostu chcę wiedzieć, czy ma to jakieś szczególne wady? Biorąc pod uwagę zarówno implementację, jak i infrastrukturę, czy są jakieś powody, dla których nie powinienem po prostu używać Redis? (To znaczy, czy memcached jest szybszy dla prostego buforowania?) Nie znalazłem nic ostatecznego.


5
Dla każdego, kto się nad tym zastanawia: dostępna jest wtyczka redis-store dla rails, która pozwala używać redis jako magazynu pamięci podręcznej.
markquezada

Odpowiedzi:


49

Zakładając, że migracja z memcached do redis w celu buforowania, które już wykonałeś, jest dość łatwa, wybrałbym redis tylko po to, aby wszystko było proste.

W redis trwałość jest opcjonalna, więc możesz jej używać podobnie jak memcached, jeśli tego chcesz. Może się nawet okazać, że utrwalenie pamięci podręcznej jest przydatne, aby uniknąć wielu błędów pamięci podręcznej po ponownym uruchomieniu. Dostępne jest również wygasanie - algorytm nieco różni się od memcached, ale nie jest na tyle istotny, aby mieć znaczenie dla większości celów - szczegóły można znaleźć na stronie http://redis.io/commands/expire .


1
Dzięki za odpowiedź i odpowiednią dokumentację. Zmodyfikowałem trochę moje pytanie, aby było bardziej jasne, czego szukam. Nie myślałem o trwałości pamięci podręcznej po ponownym uruchomieniu ... to fajna funkcja. (Chociaż nie jestem pewien, jak przydatne jest to, biorąc pod uwagę, że używałbym redis do pójścia z heroku.)
markquezada

1
Jeśli chcesz zachować niektóre elementy efemeryczne (buforowanie fragmentów), a niektóre elementy trwałe w redis, czy musisz utworzyć dwie oddzielne instancje redis?
Brian Armstrong,

1
Chociaż używamy Redis zarówno dla kolejek zadań, jak i pamięci podręcznej, uruchamiamy je w różnych konfiguracjach, szczególnie z powodów, które podaje @BrianArmstrong. Pamięć podręczna jest efemeryczna, więc konfigurujemy ją tak, aby była szybka, ale można stracić zawartość pamięci i upuścić LRU. W przypadku kolejki naprawdę nie chcemy tracić zadań, więc konfigurujemy ją z trwałością, aby można ją było odzyskać.
jwadsack

@jwadsack czy masz post, w którym pokazujesz, jak zaimplementowałeś tę konfigurację?
Marklar

1
@Marklar Dobry pomysł. Teraz tak: ballardhack.wordpress.com/2015/09/30/ ...
jwadsack

44

Jestem autorem redis-store , nie ma potrzeby bezpośredniego używania poleceń Redis, wystarczy skorzystać z takiej :expires_inopcji:

ActionController::Base.cache_store = :redis_store, :expires_in => 5.minutes

Zaletą korzystania z Redis jest trwałość, a także z mojego gem, jest to, że masz już do sklepów Rack::Cache, Rails.cachelub I18n.


Dzięki za odpowiedź Luca. Zakładam, że możesz nadpisać: expires_in bezpośrednio, gdy musisz trwale przechowywać coś? Wydaje mi się, że tak naprawdę chodzi o używanie zarówno funkcji typu memcached, jak i używania redis jako stałego magazynu obok siebie.
markquezada

3
Myślę, że nie ma sensu mieć jednocześnie memcached i redis, ponieważ są one w tym samym segmencie NoSQL: oba są magazynami ak / v. Redis PROS: 1. szybszy niż memcached 2. potężniejsze polecenia 3. nie wymaga rozgrzewania pamięci podręcznej 4. przydatne przy rozwiązywaniu innych problemów (np. Kolejek z Resque) WADY: 1. potrzebujesz zewnętrznego klejnotu 2. po restarcie serwer nie przyjmuje poleceń podczas odczytu danych z dołączanego pliku. Memcached PROS: wypiekane w Railsach WADY: 1. wolniej niż Redis 2. rozgrzewka cache.
Luca Guidi

3
@LucaGuidi Obecnie używam RedisStore do mojej pamięci podręcznej Railsów. Nie mogę dowiedzieć się, jak ustawić zarówno adres URL Redis, jak i domyślny :expires_in. Możesz pomóc?
Chris Vincent,

Podobnie jak ja, jeśli napotykasz problem z ustawieniem :expires_inprzy użyciu redis_store, odnieś się do stackoverflow.com/questions/20907247/ ...
Anirudhan J,

19

Widziałem kilka dużych witryn railsowych, które używają zarówno Memcached, jak i Redis. Memcached służy do efemerycznych rzeczy, które są przyjemne do przechowywania w pamięci, ale można je utracić / zregenerować w razie potrzeby, a Redis do trwałego przechowywania. Oba są używane do odciążenia głównej bazy danych do odczytu / zapisu ciężkich operacji.

Więcej szczegółów:

Memcached: używany do buforowania stron / fragmentów / odpowiedzi i można przekroczyć limit pamięci w Memcached, ponieważ LRU (ostatnio używany) wygaśnie stare rzeczy i często utrzyma dostępne klucze w pamięci. Ważne jest, aby w razie potrzeby wszystko w Memcached mogło zostać odtworzone z bazy danych (nie jest to jedyna kopia). Ale możesz dalej wrzucać do niego rzeczy, a Memcached domyśli się, które są najczęściej używane, i zachowa je w pamięci. Nie musisz się martwić usuwaniem rzeczy z Memcached.

redis: używasz tego do danych, których nie chciałbyś stracić i są wystarczająco małe, aby zmieścić się w pamięci. Zwykle obejmuje to zadania resque / sidekiq, liczniki ograniczenia szybkości, podzielone wyniki testów lub cokolwiek, czego nie chciałbyś stracić / odtworzyć. Nie chcesz tutaj przekraczać limitu pamięci, więc musisz trochę bardziej uważać na to, co przechowujesz i czyścisz później.

Redis zaczyna mieć problemy z wydajnością po przekroczeniu limitu pamięci (popraw mnie, jeśli się mylę). Można to rozwiązać, konfigurując Redis tak, aby działał jak elementy Memcached i LRU, dzięki czemu nigdy nie osiągnie limitu pamięci. Ale nie chciałbyś tego robić ze wszystkim, co przechowujesz w Redis, na przykład ze wznowieniem pracy. Więc zamiast ludzie często zachowują wartość domyślną, Rails.cache ustawia używanie Memcached (używając dalliklejnotu). Następnie trzymają oddzielną zmienną globalną $ redis = ... do wykonywania operacji redis.

# in config/application.rb
config.cache_store = :dalli_store  # memcached

# in config/initializers/redis.rb
$redis = $redis = Redis.connect(url: ENV['REDIS_URL'])

Może istnieć łatwy sposób na zrobienie tego wszystkiego w Redis - być może przez dwie oddzielne instancje Redis, jedną z twardym limitem pamięci LRU, podobną do Memcache, a drugą do trwałego przechowywania? Nie widziałem tego używanego, ale myślę, że byłoby to wykonalne.


15

Rozważyłbym sprawdzenie mojej odpowiedzi na ten temat:

Railsy i buforowanie - czy łatwo jest przełączać się między memcache i redis?

Zasadniczo, z mojego doświadczenia, zalecałbym zachowanie ich oddzielnie: memcached do buforowania i redis dla struktur danych i bardziej trwałego przechowywania


Chociaż początkowo planowałem skonsolidować je w oparciu o pierwotną odpowiedź na moje pytanie, od tego czasu doszedłem do zasadniczo tego samego wniosku. Używam memcache do podstawowego buforowania i redis do resque.
markquezada

6

Zapytałem zespół w Redis Labs (który dostarcza dodatki Memcached Cloud i Redis Cloud ) o to, który produkt poleciliby do buforowania Railsów. Powiedzieli, że ogólnie poleciliby Redis Cloud, że Memcached Cloud jest oferowany głównie do celów starszych, i wskazali, że ich usługa Memcached Cloud jest w rzeczywistości oparta na Redis Cloud.


Więc nie ma potrzeby zarówno memcached, jak i redis, jak wspomniano w odpowiedzi Briana? „Ludzie często używają domyślnego ustawienia Rails.cache do używania memcached (używając klejnotu dalli). A potem trzymają oddzielną zmienną globalną $ redis = ... do wykonywania operacji redis.”
Marklar

4

Nie wiem, do czego ich używasz, ale w rzeczywistości używanie obu może dać ci przewagę wydajności: Memcached ma znacznie lepszą wydajność działającą na wielu rdzeniach niż Redis, więc buforowanie najważniejszych danych w Memcached i zatrzymywanie reszty w Redis , wykorzystując jego możliwości jako bazy danych, może zwiększyć wydajność.


1
To nie do końca prawda - redis używa wielu instancji, a nie wielu wątków, więc porównanie pojedynczego rdzenia instancji redis z wielordzeniową instancją memcached nie jest szczególnie istotnym testem. Poza tym, gdy dostępne są testy porównawcze pokazujące, że oba systemy są najszybsze, różnica raczej nie będzie miała znaczenia w prawdziwym świecie.
Tom Clarkson

Multi podejście proces wag REDIS lepiej wielu systemach bazowych, niż (domyślnie) podejścia memcached multi-przewlekania antirez.com/post/update-on-memcached-redis-benchmark.html
Ludger Sprenker

3
Ta poważna wada Redis jest naprawdę bardzo bagatelizowana. Jeśli szukasz wysokiej współbieżności i masz wiele rdzeni, Memcached może poruszać się po Redis. Sharding nie jest dobrym rozwiązaniem, ponieważ musisz zaimplementować spójne mieszanie w swojej aplikacji i nie uzyskasz idealnej dystrybucji między instancjami Redis. Na przykład, jeśli fragment A buforuje konfigurację aplikacji używaną w każdym żądaniu, fragment A otrzyma więcej żądań niż inne fragmenty, które nie są trafione dla każdego żądania.
ColinM
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.