Memcached в 2026: жив ли и чем заменить

Memcached — один из самых заслуженных инструментов в вебе: он появился в 2003 году и годами держал кэш всего крупного, что вы знаете. Вопрос сегодня не в том, что это такое, а в том, стоит ли брать его в новый проект.

Короткий ответ: скорее нет. Разберём честно, почему — и в каком случае «да».

Что такое Memcached

Memcached — это распределённый кэш в оперативной памяти, работающий по модели «ключ → строка».

Вся его модель данных умещается в одну строку: вы кладёте строку по ключу, задаёте время жизни, забираете обратно. Больше он не умеет ничего — и это была осознанная позиция: делать одну вещь и делать её очень быстро.

Классическое применение — снять нагрузку с базы:

1. Приложению нужен профиль пользователя.
2. Сначала смотрим в кэш по ключу user:42.
3. Нашли — отдаём, база не тронута.
4. Не нашли — идём в базу, кладём результат в кэш, отдаём.

Схема называется cache-aside и работает с любым кэшем — что с Memcached, что с Redis.

Memcached против Redis: честное сравнение

Ключевая строка в этой таблице — вторая колонка целиком. Redis не «лучше на проценты» — он делает всё, что делает Memcached, и сверху ещё десяток вещей. Именно поэтому спор о выборе за последние годы фактически закрылся.

Аргумент про скорость больше не работает

Исторически Memcached выбирали за скорость. Сегодня это неактуально: оба хранят данные в памяти, и на операции «взять строку по ключу» разница в пределах сетевой задержки. Узким местом становится сеть, а не хранилище.

Единственное реальное преимущество: многопоточность

Здесь Memcached действительно выигрывает. Он использует несколько ядер, а Redis выполняет команды в одном потоке — как и сам Node.js.

Для Redis однопоточность — осознанный размен: именно она даёт бесплатную атомарность INCR и SET NX без всяких блокировок. Цена — одно ядро на инстанс.

На практике это упирается редко: Redis выдаёт десятки тысяч операций в секунду на ядро, и раньше упрётся ваша сеть. Но если у вас очень большой объём однотипного кэша на мощной машине — это аргумент. Обходной путь для Redis — несколько инстансов или Redis Cluster.

Как он устроен внутри: slab-аллокатор

Одна деталь Memcached стоит того, чтобы её знать, — она объясняет и его скорость, и его главную странность.

Memcached не выделяет память под каждое значение отдельно. Вместо этого он заранее нарезает память на классы блоков фиксированного размера: 96 байт, 120 байт, 152 и так далее. Значение кладётся в ближайший подходящий блок.

Отсюда два следствия:

• Скорость. Не нужно искать свободный кусок нужного размера и бороться с фрагментацией — блок либо свободен, либо нет. Это работает за константное время.
• Потери. Значение на 100 байт займёт блок на 120 — 20 байт пропадут. Это называется slab overhead, и на разнородных данных потери доходят до десятков процентов.

Есть и неприятный побочный эффект: если весь кэш забит мелкими значениями, а потом пошли крупные, память под мелкие классы уже нарезана и крупным не достанется — даже при формально свободном объёме. Отсюда советы «перезапустите Memcached, если сменился профиль данных».

Redis работает иначе: у него обычный аллокатор (jemalloc), гибче по памяти, но без такой предсказуемости.

Шардирование живёт на клиенте

Второе принципиальное отличие, о котором забывают: Memcached не знает о существовании других узлов Memcached.

Кластера в привычном смысле у него нет. Если у вас пять серверов, решение о том, на какой из них положить ключ, принимает клиентская библиотека — обычно через консистентное хеширование. Сами серверы друг с другом не общаются вообще.

Плюс: узлы не координируются, ничего не реплицируется, масштабирование линейно и просто.

Минус: репликации нет. Упал узел — его часть кэша исчезла, и все запросы к этим ключам пойдут в базу. При падении одного из пяти узлов вы теряете 20% кэша и получаете всплеск нагрузки на базу.

У Redis есть Redis Cluster и репликация — узлы знают друг о друге и умеют переживать падение.

Когда Memcached всё ещё имеет смысл

Честный список, а не «никогда»:

• Он у вас уже работает. Мигрировать ради миграции незачем. Если кэш устраивает — не трогайте.
• Нужен только простой кэш и много ядер. Огромные объёмы однотипных данных, одна мощная машина.
• Инфраструктура вокруг него уже построена — мониторинг, обвязка, экспертиза команды.

Когда точно Redis

• Нужны структуры данных. Счётчики, очереди, рейтинги, множества — в Memcached их нет вообще.
• Нужна атомарность. INCR в Redis атомарен: мы замеряли — 100 параллельных инкрементов дали ровно 100. В Memcached аналога нет.
• Данные жалко терять. Перезапуск Memcached = пустой кэш. У Redis есть снапшоты и AOF.
• Нужны блокировки. SET NX в Redis — готовый распределённый замок в одну строку.
• Нужен pub/sub.

Что было на этой странице в 2017 году

Первая версия вышла 31 июля 2017 года, и она была написана в другой реальности: тогда выбор между Memcached и Redis ещё был настоящим выбором. Их сравнивали всерьёз, и аргумент «Memcached проще и быстрее на простом кэше» звучал весомо.

За прошедшие годы спор решился сам собой — не потому, что Memcached стал хуже, а потому что Redis перестал быть «тяжёлой альтернативой». Он оброс возможностями, остался таким же быстрым на простых операциях и занял нишу целиком.

Тот же путь мы видим и в других статьях этого архива: Sails.js не сломался — просто экосистема ушла в другую сторону. Технологии редко умирают. Их обычно перестают выбирать.

Что из статьи 2017 года осталось верным: описание самой модели «ключ-значение в памяти» и схема cache-aside. Они не устарели ни на слово — просто реализуют их теперь другим инструментом.

Смежные темы: Redis в Node.js — что брать вместо, с замерами; MongoDB — когда нужна база, а не кэш; что такое Node.js — почему однопоточность бывает преимуществом. Полный список — в справочнике по Node.js.