Ответ 1

Основная причина, по которой я сегодня вижу в качестве прецедента для memcached over Redis, - это превосходная эффективность памяти, которую вы должны получить с помощью простого кэширования фрагментов HTML (или подобных приложений). Если вам нужно хранить разные поля ваших объектов в разных memcached-ключах, хеши Redis будут более эффективными с точки зрения памяти, но когда у вас есть большое количество ключей → простых_строчных пар, 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 и DB) при публикации нового элемента. Отсутствует недействительность кэша.

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

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

Ответ 2

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

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

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

Однако:

• Re. (структура данных, команды, постоянство...), активно развивается и клиенты на всех мыслимых языках - новые приложения обычно, разработанные вместе с ним.
• Re масштабирование - помимо предстоящего v3 есть решения, которые могут значительно упростить масштабирование. Например, Redis Cloud предлагает бесшовное масштабирование без потери данных или прерывания обслуживания. Еще один популярный подход к масштабированию/осколке Redis - twemproxy.