Кэширование: Transients API и Object Cache

Архитектурная база#

Система кэширования в WordPress представляет собой многоуровневую архитектуру, разделенную на runtime-память процесса, абстракцию временных данных (Transients API) и персистентное объектное хранилище (Persistent Object Cache).

Runtime Object Cache (WP_Object_Cache): по умолчанию встроенный в ядро механизм кэширует объекты в оперативной памяти PHP-процесса (static array). Срок жизни этого кэша ограничен жизненным циклом одного HTTP-запроса. Он предотвращает повторные SQL-запросы внутри одного скрипта (например, повторный вызов get_post(42) не обращается к СУБД), но полностью очищается при завершении запроса.

Drop-in персистентного кэша (object-cache.php): размещение файла wp-content/object-cache.php переопределяет стандартный класс WP_Object_Cache. В корпоративных инфраструктурах 2026 года в качестве бэкенда используются распределенные In-Memory СУБД Redis 7.4+ или Valkey. Персистентный объектный кэш сохраняет сериализованные структуры данных между независимыми HTTP-запросами, снижая количество запросов к MySQL с сотен до единиц на страницу.

Transients API: исторический интерфейс ядра для сохранения временных данных с установленным сроком жизни (TTL):

• set_transient($key, $value, $expiration)
• get_transient($key)
• delete_transient($key)

Архитектурная развилка Transients API:

1. При наличии Persistent Object Cache: функции *_transient() прозрачно перенаправляются в wp_cache_*(), используя группу transient. Данные оседают в Redis с нативным механизмом истечения ключей (EXPIRE).
2. Без Persistent Object Cache: транзиенты записываются в реляционную таблицу wp_options в виде двух независимых строк: _transient_{key} и _transient_timeout_{key}. Если срок жизни не указан ($expiration = 0), транзиент помечается флагом autoload = 'yes'. Это приводит к катастрофическому разрастанию (bloat) таблицы wp_options, деградации опции alloptions и вымыванию оперативной памяти сервера при каждом старте ядра.

Критическим вызовом highload-архитектуры является эффект собачьей упряжки (Cache Stampede / Dogpile Effect / Thundering Herd): момент, когда горячий ключ с миллионом запросов в минуту истекает, и тысячи параллельных рабочих процессов PHP одновременно получают «cache miss» и атакуют MySQL одинаковыми тяжелыми вычислениями. Для ликвидации этой проблемы применяются распределенные мьютексы (wp_cache_add) и алгоритм превентивного вероятностного пересчета (XFetch).

Ментальная модель#

Сравнение поведения системы при истечении горячего ключа: классический коллапс (Thundering Herd) против защищенного мьютекса (Distributed Mutex Gate):

КАТАСТРОФА: THUNDERING HERD (Без мьютекса)
=================================================================================
Ключ истек в Redis!
Запрос 1  (Miss) ----+
Запрос 2  (Miss) ----|---> 10 000 параллельных тяжелых SQL-запросов к MySQL!
Запрос 3  (Miss) ----|    [Результат: 100% CPU, исчерпание соединений, 504 Gateway Timeout]
Запрос N  (Miss) ----+

АРХИТЕКТУРА ENTERPRISE: ATOMIC MUTEX + STALE SERVE
=================================================================================
Ключ истек в Redis!
Запрос 1  (Miss) ---> Пытается взять мьютекс (wp_cache_add / SETNX) -> УСПЕХ!
                        |---> Выполняет тяжелый SQL (1 поток)
                        v
                      Обновляет Redis и освобождает мьютекс
                      
Запрос 2  (Miss) ---> Пытается взять мьютекс -> ЗАНЯТО!
                        |---> Возвращает устаревшие данные (Stale Cache) или ждет 50 мс
Запрос 3  (Miss) ---> Пытается взять мьютекс -> ЗАНЯТО! -> Возвращает Stale Cache

На практике применяется#

1. Главная страница высоконагруженного маркетплейса: Кэширование агрегированного дерева категорий и фильтров брендов в Redis с групповой инвалидацией при публикации новых товаров.
2. Интеграция с внешними банковскими шлюзами и логистикой: Сохранение тарифных сеток и курсов валют через персистентный кэш с защитой от Thundering Herd при одновременных заказах.
3. Хранение счетчиков просмотров и аналитики: Использование атомарных инкрементов wp_cache_incr() в Redis вместо выполнения тяжелых UPDATE wp_postmeta SET meta_value = meta_value + 1 при каждом визите.
4. Изоляция мультитенантных сред (Multi-Site / Multi-Environment): Использование префикса солей WP_CACHE_KEY_SALT в wp-config.php для исключения коллизий ключей между staging и production на одном Redis-инстансе.

Как это работает#

При проектировании кэш-стратегии важно различать работу с БД и работу с памятью:

Почему wp_cache_flush() на продакшене — это преступление#

Вызов функции wp_cache_flush() очищает абсолютно всю базу данных в Redis. В следующую же миллисекунду сотни входящих HTTP-запросов обнаруживают абсолютно пустой кэш. Нагрузка на СУБД MySQL мгновенно возрастает в 50–100 раз: сервер уходит в глубокий своппинг, исчерпывает пул max_connections и падает с ошибкой «Error establishing a database connection».

Стандарт 2026 года запрещает глобальный сброс кэша. Вместо этого применяется Key Versioning (версионирование ключей групп):

// Инвалидация группы без очистки Redis: просто инкрементируем версию группы
$version = wp_cache_incr('group_version', 1, 'catalog_meta');
// Все последующие ключи строятся как "catalog_items:v{$version}"

Продакшн-артефакт: Enterprise Resilient Cache Manager#

Ниже представлен отказоустойчивый менеджер кэширования на PHP 8.4+, реализующий защиту от Cache Stampede через распределенный мьютекс, версионирование ключей групп и безопасную дедупликацию.

<?php
declare(strict_types=1);

namespace AgenticLab\Performance;

use Closure;

/**
* Enterprise Resilient Cache Manager.
* 
* Отказоустойчивый менеджер кэша с защитой от Thundering Herd / Dogpile эффекта.
*
* Author: Artur Yusupov (Fullstack Agentic Lab)
*/
final class AgenticResilientCache {
  private const string LOCK_GROUP = 'agentic_cache_locks';
  private const int DEFAULT_LOCK_TTL = 15; // Секунды блокировки на время расчета

  /**
   * Выполнение тяжелой операции с гарантией защиты от Cache Stampede.
   *
   * @template T
   * @param string $key Ключ кэша
   * @param string $group Группа кэша
   * @param int $ttl Время жизни в секундах
   * @param Closure(): T $compute Функция вычисления данных при промахе
   * @return T
   */
  public static function remember(
      string $key,
      string $group,
      int $ttl,
      Closure $compute
  ): mixed {
      $versioned_key = self::build_versioned_key($key, $group);
      $found = false;
      
      /** @var mixed $cached */
      $cached = wp_cache_get($versioned_key, $group, false, $found);

      if ($found && $cached !== false) {
          /** @var T */
          return $cached;
      }

      // Кэша нет. Пытаемся захватить атомарный распределенный мьютекс
      $lock_key = "lock:{$versioned_key}";
      $is_locked = !wp_cache_add($lock_key, 1, self::LOCK_GROUP, self::DEFAULT_LOCK_TTL);

      if ($is_locked) {
          // Другой рабочий процесс уже выполняет расчет.
          // Пытаемся вернуть устаревший кэш (Stale-While-Revalidate)
          $stale_key = "stale:{$versioned_key}";
          $stale_found = false;
          $stale_data = wp_cache_get($stale_key, $group, false, $stale_found);

          if ($stale_found && $stale_data !== false) {
              /** @var T */
              return $stale_data;
          }

          // Если устаревшего кэша нет, ждем 50 мс и пробуем прочитать снова
          usleep(50000);
          $retry_cached = wp_cache_get($versioned_key, $group, false, $found);
          if ($found && $retry_cached !== false) {
              /** @var T */
              return $retry_cached;
          }
      }

      // Мы захватили мьютекс или ожидание истекло: выполняем вычисление
      try {
          /** @var T $result */
          $result = $compute();

          // Сохраняем свежие данные
          wp_cache_set($versioned_key, $result, $group, $ttl);

          // Сохраняем запасную stale-копию с удвоенным TTL
          wp_cache_set("stale:{$versioned_key}", $result, $group, $ttl * 2);

          return $result;
      } finally {
          // Обязательно освобождаем мьютекс блокировки
          wp_cache_delete($lock_key, self::LOCK_GROUP);
      }
  }

  /**
   * Мгновенная инвалидация всей группы кэша без вызова опасного wp_cache_flush().
   */
  public static function invalidate_group(string $group): void {
      $version_key = "version:{$group}";
      $current_version = (int)wp_cache_get($version_key, 'group_versions');

      if ($current_version === 0) {
          wp_cache_set($version_key, 2, 'group_versions', 0);
      } else {
          wp_cache_incr($version_key, 1, 'group_versions');
      }
  }

  /**
   * Построение ключа с учетом текущей версии группы.
   */
  private static function build_versioned_key(string $key, string $group): string {
      $version_key = "version:{$group}";
      $version = wp_cache_get($version_key, 'group_versions');

      if ($version === false) {
          $version = 1;
          wp_cache_set($version_key, 1, 'group_versions', 0);
      }

      return "v{$version}:{$key}";
  }
}

Распространённые ошибки#

Резюме архитектора#

Эффективная стратегия кэширования в enterprise-решениях 2026 года на WordPress держится на трех столпах:

• Отказ от хранения транзиентов в MySQL: Обязательное подключение Redis / Valkey через object-cache.php с политикой памяти allkeys-lru.
• Защита от Dogpile-эффекта: Использование распределенных атомарных мьютексов (wp_cache_add) и алгоритмов вероятностного обновления для тяжелых ключей.
• Безопасная инвалидация: Запрет глобального wp_cache_flush() в пользу версионирования ключей групп (Key Versioning).