Кластеризация memcached

memcached в веб-кластере 1С-Битрикс решает две задачи: общий кеш для всех веб-нод и хранилище сессий. Разберём, как собрать пул серверов, как распределяются ключи и что контролировать в продакшене.

Зачем memcached в кластере

В одиночной инсталляции Битрикс кеширует данные на локальном диске (/bitrix/managed_cache/). В кластере это не работает: каждая нода имела бы свой кеш, и данные расходились бы. Общий memcached делает кеш единым для всех нод.

Второй эффект — скорость. memcached держит данные в оперативной памяти и отдаёт их за микросекунды, разгружая базу от повторных запросов. Управляемый кеш Битрикс (теги, зависимости) полностью работает поверх memcached.

Пул серверов и распределение ключей

Кластеризация memcached в Битрикс — это пул из нескольких инстансов. Ключи распределяются между ними алгоритмом хеширования: каждый ключ детерминированно попадает на «свой» сервер. Это даёт горизонтальное масштабирование объёма кеша — добавили инстанс, увеличили суммарную память.

// bitrix/.settings.php
'cache' => array(
  'value' => array(
    'type' => 'memcache',
    'servers' => array(
      array('host' => '10.0.0.21', 'port' => 11211, 'weight' => 1),
      array('host' => '10.0.0.22', 'port' => 11211, 'weight' => 1),
    ),
  ),
),

Важно: все веб-ноды должны видеть один и тот же список серверов в одинаковом порядке. Иначе хеширование на разных нодах даст разное распределение, и кеш перестанет быть общим.

Настройка в Битрикс

Подключить memcached можно двумя способами:

1. Через административную панель — Настройки → Веб-кластер → Memcached, где добавляются серверы пула.
2. Напрямую в bitrix/.settings.php (секция cache) — предпочтительно для инфраструктуры-как-код и одинаковой конфигурации нод.

В BitrixVM memcached ставится и конфигурируется через меню bx. Объём памяти под кеш задаётся параметром -m в конфиге memcached и подбирается по рабочему набору данных.

Кеш и сессии на одном пуле

memcached в кластере часто используется и под кеш, и под сессии. Это удобно, но требует осторожности:

Hit rate и вытеснение

Главная метрика памяти кеша — hit rate (доля попаданий). Низкий hit rate означает, что кеш не успевает прогреться или памяти мало, и данные постоянно вытесняются. Проверить статистику можно так:

echo -e "stats\r\n" | nc 10.0.0.21 11211 | grep -E 'get_hits|get_misses|evictions'

• get_hits / get_misses — считайте отношение, целитесь в высокий процент попаданий.
• evictions — рост означает нехватку памяти: увеличьте -m или добавьте инстанс в пул.
• Следите за curr_connections, чтобы не упереться в лимит соединений.

Отказоустойчивость пула

memcached не реплицирует данные между инстансами. Если один сервер пула падает, ключи, которые на него хешировались, становятся недоступны — это кеш-промахи, которые компенсируются чтением из БД. Сайт продолжит работать, но нагрузка на БД скакнёт.

• Не размещайте весь пул на одной физической машине — теряется смысл распределения.
• Под сессии в memcached падение инстанса означает разлогин части пользователей — ещё один аргумент за Redis для сессий.
• Для критичных сценариев рассмотрите Redis с репликацией вместо memcached.

memcached хорош именно как быстрый разделяемый кеш; отказоустойчивость данных — не его задача.

Итог

Кластеризация memcached в 1С-Битрикс — это пул инстансов с хешированием ключей, дающий общий быстрый кеш и, при желании, хранилище сессий. Ключевые правила: одинаковый список серверов на всех нодах, контроль hit rate и evictions, разделение кеша и сессий. memcached не реплицирует данные, поэтому отказоустойчивость закладывают на уровне архитектуры.

Мы настраиваем кеширование под нагрузку: подбираем объём памяти, разносим кеш и сессии, добавляем Redis там, где нужна персистентность, и выстраиваем мониторинг hit rate. Это один из самых дешёвых способов снять нагрузку с базы данных.