В похвалу memcached: простой кэш лучше сложного
Redis часто выбирают как кэш по инерции, но это приводит к проблемам: разработчики начинают полагаться на персистентность Redis как на базу данных, инфраструктура падает и теряет данные. Memcached решает эту проблему архитектурой: он НЕ поддерживает персистентность, что гарантирует, что он останется именно кэшем. Масштабирование в memcached тривиально: клиент хешит ключ, выбирает сервер из пула, и при падении узла клиент автоматически удаляет его из активного набора. Memcached потребляет ~64 MB памяти на инстанс, позволяя запускать десятки инстансов без накладов. Redis имеет больше функций, но для чистого кэширования эти функции усложняют инфраструктуру без выигрыша.
Ключевые факты
- Memcached не поддерживает персистентность, что делает его идеальным только для кэширования
- Клиентская консистентная хеш-таблица позволяет масштабировать без координации между серверами
- Падение memcached-сервера не требует восстановления; клиент просто удалит узел из пула
- Запуск дюжин инстансов требует ~64 MB памяти на каждый с минимальными накладами
- Redis часто неправильно используется как база данных, когда нужен простой кэш
Почему это важно
В облачных архитектурах кэширование, критический слой между приложением и БД. Неправильный выбор кэша приводит к потере данных, неправильно сконфигурированному мониторингу и наследованию технического долга. Memcached, будучи простым и явно безсостояние-ориентированным, вынуждает правильное поведение. Redis с его персистентностью часто соблазняет разработчиков использовать его как БД.
Кому это важно
Разработчикам, выбирающим кэш для нового сервиса. DevOps и SRE, отвечающим за инфраструктуру кэширования. Компаниям, сталкивающимся с проблемами надёжности Redis. Стартапам, желающим избежать сложности операционного управления.
Как это применить
Вместо Redis для кэширования выбрать memcached, особенно если используется фреймворк с поддержкой разных бэкендов (Django, в примере). Настроить клиентскую библиотеку с несколькими хостами memcached. Использовать service discovery для автоматического добавления/удаления узлов из пула. Запустить дешёвые stateless инстансы (можно в Kubernetes как обычные поды). Убедиться, что приложение не полагается на данные, оставшиеся в кэше после перезагрузки.
Можно ли доверять
Memcached существует с 2003 года, используется в больших production-системах (Facebook, Twitter и т.д.). Автор, опытный sysadmin с практическим опытом обслуживания обоих инструментов. Рекомендация основана на операционных реалиях, а не на особенностях протокола.
Риски и подводные камни
Memcached абсолютно безсостояние-ориентирован, что ограничивает его применение только кэшем. Если нужна хотя бы малая персистентность или advanced features (streams, sorted sets и т.д.), нужен Redis. Консистентная хеш-таблица требует правильной реализации в клиентской библиотеке; плохая реализация может привести к горячим узлам. Забыть про monitoring memcached легче, чем Redis, потому что он "просто кэш".
«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.»
— автор статьи
Компания Meta Platforms признана экстремистской организацией, её деятельность на территории РФ запрещена.