Если redis уже является частью стека, почему Memcached все еще используется вместе с Redis?

85

Redis может делать все, что предоставляет Memcached (кеш LRU, истечение срока действия элементов и теперь кластеризация в версии 3.x +, в настоящее время находится в стадии бета-тестирования) или с помощью таких инструментов, как twemproxy. Спектакль тоже похож. Более того, Redis добавляет постоянство, благодаря которому вам не нужно нагревать кеш в случае перезапуска сервера.

Ссылка на некоторые старые ответы, которые сравнивают Redis и Memcache, некоторые из которых поддерживают Redis в качестве замены Memcache (если он уже присутствует в стеке):

Несмотря на это, изучая стеки крупных веб-компаний, таких как Instagram, Pinterest, Twitter и т. Д., Я обнаружил, что они используют Memcached и Redis для разных целей, не используя Redis для первичного кэширования. Основным кешем по-прежнему является Memcached, а Redis используется для логического кэширования на основе структур данных.

Почему с 2014 года memcached по-прежнему стоит того, чтобы добавить его в качестве дополнительного компонента в ваш стек, если у вас уже есть компонент Redis, который может делать все, что может memcached? Какие благоприятные моменты склоняют архитекторов / инженеров к тому, чтобы по-прежнему включать memcached помимо уже существующего Redis?

Обновить :

Для наших платформ мы полностью отказались от Memcached и используем redis как для простого, так и для логического кэширования. Высокая производительность, гибкость и надежность.

Некоторые примеры сценариев:

  • Список всех кэшированных ключей по определенному шаблону, а также чтение или удаление их значений. Очень просто в Redis, но не выполнимо (легко) в memcached.
  • Хранение полезной нагрузки более 1 МБ, что легко сделать в Redis, требует настройки размера блока в memcached, что имеет собственные побочные эффекты производительности.
  • Легкие снимки текущего содержимого кеша
  • Кластер Redis также готов к производству вместе с языковыми драйверами, поэтому кластерное развертывание также легко.
ДхрувПатхак
источник

Ответы:

122

Основная причина, по которой я вижу сегодня вариант использования memcached поверх Redis, - это превосходная эффективность использования памяти, которую вы должны получить при кэшировании простых HTML-фрагментов (или аналогичных приложений). Если вам нужно хранить разные поля ваших объектов в разных ключах memcached, тогда хэши Redis будут более эффективными с точки зрения памяти, но когда у вас есть большое количество пар ключ -> simple_string, memcached сможет предоставить вам больше элементов за мегабайт.

Другие достоинства memcached:

  • Это очень простой фрагмент кода, поэтому, если вам просто нужна предоставляемая им функциональность, я думаю, это разумная альтернатива, но я никогда не использовал ее в производстве.
  • Он многопоточный, поэтому, если вам нужно масштабировать установку с одним блоком, это хорошо, и вам нужно поговорить только с одним экземпляром.

Я считаю, что Redis как кеш имеет все больше и больше смысла по мере того, как люди переходят к интеллектуальному кэшированию или когда они пытаются сохранить структуру кешированных данных с помощью структур данных Redis.

Сравнение Redis LRU и memcached LRU.

И memcached, и Redis не выполняют настоящих выселений LRU, а только приближенно.

Вытеснение Memcache - это класс по размеру и зависит от деталей реализации его распределителя slab. Например, если вы хотите добавить элемент, который соответствует заданному классу размера, memcached попытается удалить просроченные / не недавно использованные элементы в этом классе, вместо этого, чтобы попытаться глобально понять, что это за объект, независимо от его размер, который является лучшим кандидатом.

Redis вместо этого пытается выбрать хороший объект в качестве кандидата на выселение при достижении maxmemoryпредела, просматривая все объекты, независимо от класса размера, но может предоставить только приблизительно хороший объект, а не лучший объект с большим бездействием. время.

Redis делает это путем выборки нескольких объектов, выбирая тот, который бездействовал (не был доступен) в течение длительного времени. Начиная с Redis 3.0 (в настоящее время в стадии бета-тестирования) алгоритм был улучшен и также принимает хорошие пулы кандидатов при выселении, поэтому приближение было улучшено. В документации Redis вы можете найти описание и графики с подробностями о том, как это работает .

Почему memcached имеет лучший объем памяти, чем Redis, для простых строковых -> строковых карт.

Redis - более сложная программа, поэтому значения в Redis хранятся более похоже на объекты на языке программирования высокого уровня: у них есть связанный тип, кодировка, подсчет ссылок для управления памятью. Это делает внутреннюю структуру Redis хорошей и управляемой, но имеет накладные расходы по сравнению с memcached, который работает только со строками.

Когда Redis начинает более эффективно использовать память

Redis может хранить небольшие совокупные типы данных особым способом экономии памяти. Например, небольшой Redis Hash, представляющий объект, хранится внутри не с хеш-таблицей, а как двоичный уникальный BLOB-объект. Таким образом, установка нескольких полей для каждого объекта в хэш более эффективна, чем хранение N разделенных ключей в memcached.

Фактически вы можете сохранить объект в memcached как один JSON (или в двоичном коде) blob, но, в отличие от Redis, это не позволит вам получать или обновлять независимые поля.

Преимущество Redis в контексте интеллектуального кеширования.

Из-за структур данных Redis обычный шаблон, используемый с memcached для уничтожения объектов, когда кеш становится недействительным, для последующего воссоздания его из БД, является примитивным способом использования Redis.

Например, представьте, что вам нужно кэшировать последние N новостей, опубликованных в Hacker News, чтобы заполнить раздел «Самые новые» на сайте. Что вы делаете с Redis, так это берете список (до M элементов) с вставленными новейшими новостями. Если вы используете другое хранилище для своих данных и Redis в качестве кеша, вам нужно заполнить оба представления (Redis и БД) при публикации нового элемента. Нет недействительности кеша.

Однако у приложения всегда может быть логика, так что если список Redis окажется пустым, например, после запуска, исходное представление может быть воссоздано из БД.

Используя интеллектуальное кэширование, можно выполнять кэширование с помощью Redis более эффективным способом по сравнению с memcached, но не все проблемы подходят для этого шаблона. Например, кеширование фрагментов HTML может не принести пользу от этого метода.

антирез
источник
Спасибо Antirez создателю. Но ** почему объем памяти Redis для простых строк больше, чем у memcached? ** Является ли сжатие фактором? Или Redis сохраняет некоторые другие дополнительные данные, когда SET используется для хранения простой строки? Было бы здорово, если бы вы могли включить эту информацию в ответ.
DhruvPathak
3
Я попытался улучшить ответ. Спасибо за отзывы.
antirez
3
Другой аспект вышеупомянутого «интеллекта» или использование типов данных Redis и логики на стороне сервера посредством операций и / или сценариев заключается в том, что вы экономите как на сложности приложения, так и на сети (как это обсуждается @antirez в antirez. com / news / 73 и Yiftach на redislabs.com/blog/the-proven-redis-performance ).
Итамар Хабер
1
Антирез спасибо за ответ. Другой причиной может быть то, что memcached работает немного быстрее. Также это старое программное обеспечение, и многие фреймворки поддерживают его по умолчанию
Ник
3
Отличный ответ, мне нужно любить, насколько отец Redis предан сообществу.
Ман
13

Привычки сложно сломать :)

Если серьезно, то, насколько я понимаю, есть две основные причины, по которым Memcached все еще используется:

  1. Legacy - есть разработчики, которые хорошо знакомы с Memcached, а также с приложениями, которые его поддерживают. Это также означает, что это зрелая и хорошо протестированная технология.
  2. Масштабирование - стандартный Memcached легко масштабируется по горизонтали, тогда как Redis (до и за исключением версии v3, которая скоро будет выпущена) требует для этого больше работы (т. Е. Сегментирования).

Тем не мение:

  1. Re. наследие - учитывая надежность Redis (структуры данных, команды, постоянство ...), он активно развивается и клиенты на всех мыслимых языках - новые приложения обычно разрабатываются с его помощью.
  2. Повторное масштабирование - помимо предстоящей версии 3, есть решения, которые могут значительно упростить масштабирование. Например, Redis Cloud предлагает плавное масштабирование без потери данных или прерывания обслуживания. Еще один популярный подход к масштабированию / сегментированию Redis - это twemproxy .
Итамар Хабер
источник
1
Просто примечание: как это было подтверждено текущим сопровождающим в Twitter, Memcached все еще активно развивается / поддерживается. Я предполагаю, что тот факт, что он не добавляет что-то новое, часто объясняется зрелостью проекта и нежеланием добавлять что-то новое, поэтому новые разработки сосредоточены на оптимизации / исправлениях.
antirez
1
TIL, что Memcached все еще жив и здоров - отредактировал мой ответ / ty antirez & dormando
Итамар Хабер
1
Согласованное хеширование по-прежнему является более надежной моделью для постепенного отказа, чем сегментирование Redis для сценария чистого кеширования. При падении узлов ключи кеша автоматически перемещаются на другие серверы. Пока у вас есть один сервер, ваш кеш все еще работает, в отличие от redis, где, если вы потеряете главный и подчиненный сервер для любой хэш-группы, ваш кластер выйдет из строя.
Усман Исмаил
1
RedisLabs превосходен. Это ключевая технология, лежащая в основе Userify Cloud.
fatal_error
1
Я также крайне подозрительно отношусь к любой реализации, не основанной на многопоточности и цикле событий. ... Ладно, а где сейчас все апологеты выступления, я приготовил их ужин. Теперь redis может это сделать, и я был бы гораздо более про-redis со стороны системы. Однако на данный момент, если группа разработчиков не обладает необычными способностями к кэшированию, memcached является простой и более эффективной реализацией ... функции НИКОГДА не бесплатны, не позволяйте апологетам говорить вам, что они есть, или что ваши затраты незначительны.
JM Becker,