В похвалу memcached: простой кэш лучше сложного
Redis часто выбирают как кэш по инерции, но это приводит к проблемам: разработчики начинают полагаться на персистентность Redis как на базу данных, инфраструктура падает и теряет данные. Memcached решает эту проблему архитектурой: он НЕ поддерживает персистентность, что гарантирует, что он останется именно кэшем. Масштабирование в memcached тривиально: клиент хешит ключ, выбирает сервер из пула, и при падении узла клиент автоматически удаляет его из активного набора. Memcached потребляет ~64 MB памяти на инстанс, позволяя запускать десятки инстансов без накладов. Redis имеет больше функций, но для чистого кэширования эти функции усложняют инфраструктуру без выигрыша.
Ключевые факты
- Memcached не поддерживает персистентность, что делает его идеальным только для кэширования
- Клиентская консистентная хеш-таблица позволяет масштабировать без координации между серверами
- Падение memcached-сервера не требует восстановления; клиент просто удалит узел из пула
- Запуск дюжин инстансов требует ~64 MB памяти на каждый с минимальными накладами
- Redis часто неправильно используется как база данных, когда нужен простой кэш
Ред. Главная фича memcached это отсутствие фич. Звучит как недостаток ровно до первого инцидента с потерей данных.
Почему это важно
В облачных архитектурах кэширование, критический слой между приложением и БД. Неправильный выбор кэша приводит к потере данных, неправильно сконфигурированному мониторингу и наследованию технического долга. Memcached, будучи простым и явно безсостояние-ориентированным, вынуждает правильное поведение. Redis с его персистентностью часто соблазняет разработчиков использовать его как БД.
Ред. Redis выбирают не потому, что он лучше как кэш, а потому что в резюме красивее. А потом персистентность, которой никто не просил, тихо превращает кэш в базу данных, которую никто не бэкапит.
Кому это важно
Разработчикам, выбирающим кэш для нового сервиса. DevOps и SRE, отвечающим за инфраструктуру кэширования. Компаниям, сталкивающимся с проблемами надёжности Redis. Стартапам, желающим избежать сложности операционного управления.
Ред. Тем, кто уже однажды восстанавливал "кэш" после падения и понял, что кэш восстанавливать не должен в принципе.
Как это применить
Вместо Redis для кэширования выбрать memcached, особенно если используется фреймворк с поддержкой разных бэкендов (Django, в примере). Настроить клиентскую библиотеку с несколькими хостами memcached. Использовать service discovery для автоматического добавления/удаления узлов из пула. Запустить дешёвые stateless инстансы (можно в Kubernetes как обычные поды). Убедиться, что приложение не полагается на данные, оставшиеся в кэше после перезагрузки.
Ред. Совет хорош, но последняя строчка важнее всех: приложение не должно полагаться на данные, пережившие перезагрузку. Если полагается, проблема не в Redis, а в архитектуре.
Можно ли доверять
Memcached существует с 2003 года, используется в больших production-системах (Facebook, Twitter и т.д.). Автор, опытный sysadmin с практическим опытом обслуживания обоих инструментов. Рекомендация основана на операционных реалиях, а не на особенностях протокола.
Ред. Memcached старше многих сеньоров, что его и спасает: за двадцать лет в нём просто не успели накрутить лишнего, обо что можно споткнуться.
Риски и подводные камни
Memcached абсолютно безсостояние-ориентирован, что ограничивает его применение только кэшем. Если нужна хотя бы малая персистентность или advanced features (streams, sorted sets и т.д.), нужен Redis. Консистентная хеш-таблица требует правильной реализации в клиентской библиотеке; плохая реализация может привести к горячим узлам. Забыть про monitoring memcached легче, чем Redis, потому что он "просто кэш".
Ред. Тонкий момент в конце: про memcached забывают в мониторинге именно потому, что он "просто кэш". Простота инструмента не делает простой эксплуатацию, она лишь усыпляет бдительность.
«memcached 'solves' the whole persistence issue, because it does not persist to disk. It is therefore a perfect fit to just being scheduled as a stateless workload wherever you desire it.»
— автор статьи