Які види кешу є в Yii2 і як інвалідувати кеш через залежності?

Пояснення

Чотири види кешу в Yii2 відрізняє не сховище, а місце в життєвому циклі запиту. yii\filters\HttpCache - фільтр дії: він читає If-Modified-Since та If-None-Match, питає ваші колбеки lastModified і etagSeed, і за збігом віддає 304 без тіла, навіть не доходячи до рендеру (тільки для GET і HEAD). yii\filters\PageCache стоїть у тому ж місці, але зберігає в кеші готовий Response::$data разом із заголовками зі cacheHeaders і куками зі cacheCookies, тому при попаданні дія взагалі не виконується. Кеш фрагментів - віджет yii\widgets\FragmentCache під обгорткою $this->beginCache($id, $options) / $this->endCache() всередині view; його беруть тоді, коли сторінку цілком кешувати не можна, а важкий сайдбар - можна. Кеш даних через компонент cache не привʼязаний до жодної точки циклу: get(), set(), add(), multiGet(), getOrSet() приймають будь-що серіалізовне, від масиву до HTML.

Нижче цих чотирьох рівнів живе кеш запитів, який регулярно плутають із кешем даних. Yii::$app->db->cache(fn () => ..., $duration, $dependency) перехоплює yii\db\Command всередині колбека й зберігає сирі рядки результату в компоненті, вказаному в $db->queryCache. Те саме можна поставити на окремий запит: Post::find()->where([...])->cache(600). Виграш тут суто на мережі до БД та її роботі: гідратація в обʼєкти Post відбувається заново при кожному читанні, бо в кеші лежать масиви з драйвера. Коли дорога саме гідратація, правильніше кешувати asArray()->all() звичайним getOrSet(). І не забувайте про enableSchemaCache: без нього Yii робить SHOW FULL COLUMNS для кожної моделі в кожному запиті, що на проді з трьома десятками таблиць видно в профайлері.

Інвалідація зводиться до двох варіантів: час або обʼєкт Dependency. Механіка проста, але має неочевидний наслідок: залежність перевіряється в get(), а не в set(). Коли Yii знаходить запис, він викликає Dependency::isChanged() і тільки за false віддає дані. Для DbDependency це означає реальний SQL-запит на кожне читання: ви замінили важкий агрегат на SELECT MAX(updated_at) ... WHERE category_id = :cid, але звернення до бази залишилось. Звідси симптом «сторінка закешована, а база отримує звернення на кожен хіт». Якщо залежність використовується кілька разів у межах одного запиту, поставте 'reusable' => true - результат перевірки ляже в статичну властивість, і SQL виконається один раз. Цінність DbDependency - у ситуаціях, коли дані змінює хтось поза вашим кодом: інший сервіс, імпорт дампом, стара адмінка.

TagDependency працює інакше й дешевше. Теги зберігаються як окремі ключі з випадковим значенням від Yii::$app->security->generateRandomKey(); set() запамʼятовує поточні значення біля даних, isChanged() їх перечитує і порівнює, а TagDependency::invalidate($cache, $tags) генерує нові. Вартість інвалідації не залежить від кількості звʼязаних записів - перезаписується стільки ключів, скільки тегів. Побічний ефект, який дивує на першому Redis-моніторингу: дані нікуди не зникають. Вони просто перестають сходитись при порівнянні й лежать до кінця власного TTL, до спрацювання gcProbability у FileCache/DbCache або до витіснення за maxmemory-policy. Логічне місце для invalidate() - afterSave() і afterDelete() моделі, тоді читання не платить нічого. Коли потрібна комбінація умов, є ChainedDependency з прапорцем dependOnAll.

Окрема тема, на якій валиться багато відповідей, - cache stampede. Популярний ключ протермінувався, сто паралельних воркерів одночасно отримали false і пішли будувати значення самі; база стає вузьким місцем у найгірший момент. getOrSet() тут не допомагає, це синтаксичний цукор: між його внутрішнім get() і set() жодного замка немає. Робочі підходи: компонент mutex (MysqlMutex, PgsqlMutex, FileMutex, yii\redis\Mutex) із коротким таймаутом на acquire(), щоб перебудовував один процес, а решта або чекали, або віддавали заглушку; схема з двома TTL, де службовий ключ протермінується раніше за дані й дозволяє віддавати трохи застарілий результат, поки один воркер оновлює; прогрів консольною командою в cron. І обовʼязково розсинхронізуйте TTL - 3600 + random_int(0, 300) замість рівної години, інакше після деплою всі ключі помруть одночасно й ви отримаєте те саме, тільки за розкладом.

variations ламають продакшн частіше за будь-яку теорію з цього списку. PageCache і FragmentCache нічого не знають про те, від чого залежить ваш вивід. Двомовний сайт без 'variations' => [Yii::$app->language] віддасть англійцеві українську сторінку. Блок, що показує Yii::$app->user->identity->name або містить CSRF-токен, без варіації за id користувача покаже чуже імʼя й зламає POST-форми. Те саме з фільтрами списку: якщо вивід залежить від $_GET['sort'], цей параметр мусить бути у варіаціях або в ключі. Наостанок про Yii::$app->cache->flush() на проді: так робити не варто, бо він зносить усе, включно з метаданими схеми й сесіями, якщо вони в тому ж сторі. Для «чистого старту» після деплою достатньо змінити keyPrefix у конфігурації компонента.

КодPHP

use yii\caching\DbDependency;
use yii\caching\TagDependency;

// 1. Кеш даних. getOrSet() зʼявився у 2.0.11; масив-ключ Yii нормалізує через buildKey()
$top = Yii::$app->cache->getOrSet(
    ['top-posts', 'category' => $categoryId, 'lang' => Yii::$app->language],
    fn () => Post::find()->where(['category_id' => $categoryId])->limit(10)->asArray()->all(),
    3600 + random_int(0, 300),                      // розсинхронізований TTL проти stampede
    new TagDependency(['tags' => ["category-$categoryId", 'posts']])
);

// 2. Інвалідація за тегом: перезаписує службові ключі, самі записи лишаються в storage
TagDependency::invalidate(Yii::$app->cache, "category-$categoryId");

// 3. Залежність від стану БД. isChanged() виконує цей SQL на КОЖНОМУ get(),
//    тому умова мусить мати індекс; reusable схлопує перевірки в межах запиту
$freshness = new DbDependency([
    'sql' => 'SELECT MAX(updated_at) FROM {{%post}} WHERE category_id = :cid',
    'params' => [':cid' => $categoryId],
    'reusable' => true,
]);

// 4. Кеш запитів: у кеш ідуть сирі рядки, гідратація в моделі робиться щоразу
$count = Yii::$app->db->cache(
    fn () => Post::find()->where(['category_id' => $categoryId])->count(),
    600,
    $freshness
);

// 5. Важкий звіт під mutex: перебудовує лише той воркер, що взяв замок
$key = ['report', 'month' => $month];
$report = Yii::$app->cache->get($key);
if ($report === false) {
    $lock = 'report-' . $month;
    if (Yii::$app->mutex->acquire($lock, 3)) {      // 3 с очікування, далі false
        try {
            $report = Yii::$app->cache->getOrSet($key, fn () => $this->buildReport($month), 900);
        } finally {
            Yii::$app->mutex->release($lock);
        }
    } else {
        $report = $this->reportPlaceholder();        // решта не стають у чергу до БД
    }
}

Що хоче почути інтервʼюер

Що рівні кешу відрізняються не технологією, а точкою в життєвому циклі: HTTP-кеш обриває запит до рендеру, PageCache - після `beforeAction`, фрагмент - усередині view, кеш даних - будь-де.

Що залежність перевіряється на `get()`, а не на `set()`: `DbDependency` виконує свій SQL при кожному читанні з кешу, тому важка умова в залежності зводить виграш до нуля.

Що `TagDependency::invalidate()` не видаляє даних: воно перезаписує службові ключі тегів, і старі записи просто перестають проходити `isChanged()`.

Що кеш запитів (`$db->cache()`, `->cache()` на `ActiveQuery`) кешує рядки результату, а не гідратовані моделі, і потребує `enableQueryCache` на підключенні.

Що `variations` обовʼязкові там, де вивід залежить від мови, ролі або параметрів фільтра, інакше користувач побачить чужу сторінку.

Що від cache stampede вбудованого захисту немає: Yii дає компонент `mutex`, а `getOrSet()` ніяких блокувань не ставить.

Типові помилки

Думати, що `getOrSet()` захищає від паралельної перебудови: він робить `get()`, і якщо пусто - викликає колбек, скільки б процесів туди не зайшло одночасно.

Чекати, що `TagDependency::invalidate()` звільнить памʼять у Redis чи видалить файли FileCache: записи лежать до закінчення TTL або до GC.

Ставити `DbDependency` з `sql => 'SELECT COUNT(*) FROM order'` на велику таблицю: сторінка «з кешу» починає з повного підрахунку, у InnoDB це seq scan.

Викликати `beginCache()` без перевірки повернутого значення - тоді тіло рендериться завжди, а `endCache()` падає з винятком про незбалансований виклик.

Забути `variations` у `PageCache` на двомовному сайті й віддавати україномовну сторінку англійській версії.

Кешувати у фрагменті блок, який залежить від CSRF-токена або `Yii::$app->user`, без варіації за id користувача.

Міняти схему таблиці на проді й не чистити `enableSchemaCache`: Yii продовжує вважати, що колонки немає.

ПОРАДА

Відповідайте по осі «де в життєвому циклі обривається робота»: HttpCache - 304 ще до рендеру, PageCache - готовий HTML із заголовками, fragment - частина view, data cache - будь-який серіалізовний результат. Потім одним реченням про інвалідацію: «за часом, або `Dependency::isChanged()` на `get()`, причому `DbDependency` коштує запит, а `TagDependency` - лише читання службового ключа». Згадка про mutex проти stampede додає бал майже завжди.

Додаткові питанняЗ ВІДПОВІДЯМИ

При `set()` з `TagDependency` Yii для кожного тега читає (або створює) службовий ключ і запамʼятовує разом із даними пару «тег -> його поточне значення». Значення - випадковий рядок із `Yii::$app->security->generateRandomKey()`. При `get()` викликається `isChanged()`: він ще раз читає службові ключі тегів і порівнює з тим, що лежало біля даних. `TagDependency::invalidate($cache, $tags)` просто перезаписує службові ключі новими випадковими значеннями, тому всі записи, звʼязані з цим тегом, одразу не сходяться при порівнянні. Фізично вони лишаються в storage до закінчення власного TTL або до прибирання (`gcProbability` у `FileCache` і `DbCache`, витіснення по `maxmemory-policy` у Redis). Практичний висновок: інвалідація за тегом - це O(кількість тегів), а не O(кількість ключів), тому вона дешева навіть для десятків тисяч записів, але памʼять вона не повертає.

`DbDependency` виграє, коли дані змінюються поза вашим кодом: інший сервіс пише в ту саму базу, є імпорт через SQL-дамп, адмінка на іншій кодовій базі. Ви не контролюєте запис, тож і `invalidate()` викликати нема звідки - лишається перевіряти стан. Умова мусить бути дешевою: `SELECT MAX(updated_at) FROM {{%post}} WHERE category_id = :cid` з індексом на `(category_id, updated_at)`, а не `COUNT(*)` по всій таблиці. `TagDependency` кращий, коли всі записи йдуть через ваші моделі: тоді в `afterSave()`/`afterDelete()` ви викликаєте `TagDependency::invalidate()` і не платите нічого при читанні, бо перевірка - це читання одного-двох ключів із того самого кешу. Є ще `ChainedDependency` з `dependOnAll` (за замовчуванням `true`) - коли потрібна комбінація, і `ExpressionDependency`, якому передають PHP-вираз рядком; останній тримайте для простих речей типу `Yii::$app->language`, бо він проходить через `eval()`. Усі залежності мають прапорець `reusable`: з `true` результат перевірки кешується в статичній властивості на час поточного запиту, тож десять фрагментів з однаковою `DbDependency` зроблять один SQL, а не десять.

Кеш даних кешує те, що ви йому дали, - масив, DTO, рендерений HTML. Кеш запитів працює рівнем нижче: `Yii::$app->db->cache(function ($db) { ... }, $duration, $dependency)` змушує всі `yii\db\Command::queryAll()`/`queryOne()` всередині колбека зберігати сирі рядки результату в компоненті `queryCache`. Альтернативно тривалість ставлять на конкретний запит: `Post::find()->where([...])->cache(600)`. Умови, за яких це не працює: вимкнений `enableQueryCache` на підключенні (за замовчуванням `true`, але його часто гасять у `config/db.php`), відсутній компонент із id з `$db->queryCache` (типово `'cache'`), обгортка `$db->noCache()` всередині, а також запити, що повертають ресурсні хендли - великі BLOB у деяких драйверах не серіалізуються. Важливий нюанс: у кеш ідуть рядки, а гідратація в обʼєкти `Post` відбувається щоразу заново, тобто ви економите на базі, але не на `populateRecord()`. Якщо дорога саме гідратація, кешуйте результат `asArray()->all()` звичайним `getOrSet()`. Окремо від цього живе `enableSchemaCache` - кеш метаданих таблиць, який на проді треба вмикати завжди, бо інакше Yii робить `SHOW FULL COLUMNS` на кожну модель у кожному запиті.

Stampede (він же dog-piling) - це коли популярний ключ протермінувався, і всі паралельні запити одночасно не знайшли його в кеші й пішли будувати значення самостійно. Сто воркерів виконують один і той самий важкий агрегат, база стає вузьким місцем, час відповіді зростає, нові запити накопичуються. `getOrSet()` від цього не рятує: між його внутрішнім `get()` і `set()` немає жодного замка. Робочі способи в Yii2: взяти `yii\mutex\MysqlMutex`, `PgsqlMutex`, `FileMutex` або `yii\redis\Mutex` і робити `acquire($key, $timeout)` перед перебудовою - той, хто не отримав замок, або чекає короткий таймаут, або віддає спрощену версію. Другий варіант - два TTL: дані кладуть на годину, а поряд службовий ключ на 55 хвилин; коли службовий зник, перший процес бере mutex і перебудовує, а решта тим часом віддають ще живий старий результат (stale-while-revalidate руками). Третій - прогрів через консольну команду в cron, щоб ключ ніколи не вмирав під навантаженням. І розсинхронізуйте TTL: `3600 + random_int(0, 300)` замість однакової години для всіх ключів, інакше після деплою вони протермінуються разом.

Обидва - `ActionFilter`, обидва працюють у `beforeAction()`, і порядок у масиві `behaviors()` визначає, хто спрацює першим. `HttpCache` перевіряє `If-Modified-Since` і `If-None-Match`, і якщо ваші колбеки `lastModified`/`etagSeed` кажуть, що контент не змінився, він одразу віддає 304 без тіла - найдешевший варіант, бо нічого не рендериться й нічого не передається по мережі. Працює він тільько для GET і HEAD. `PageCache` зберігає в кеші готовий `Response::$data` плюс заголовки зі списку `cacheHeaders` і куки з `cacheCookies`; при попаданні відповідь віддається без запуску дії. Поєднувати їх логічно: `HttpCache` першим - для повторних візитів того самого браузера, `PageCache` другим - для нових відвідувачів і ботів. Пастка: `PageCache` кешує відповідь разом із заголовками, тому `Set-Cookie` з CSRF-токеном або сесією може поїхати іншому користувачеві, якщо ви необережно розширили `cacheCookies`. І `variations` потрібні обом: мова, тема, роль, усе, від чого залежить вивід.

Ключем може бути рядок або масив - `Cache::buildKey()` серіалізує масив і бере від нього md5, тому `['top-posts', 'category' => 5, 'lang' => 'uk']` перетворюється на нормальний скалярний ключ без ручного `implode`. Масиви читабельніші й менш схильні до колізій за склеювання через дефіс, коли одне зі значень саме містить дефіс. Для розділення середовищ є `keyPrefix` у конфігурації компонента: Yii підставляє його до кожного ключа, тому staging і production на одному Redis не перетираються. Якщо середовища мають власні номери БД у Redis (`database` у `yii\redis\Connection`), префікс менш критичний, але він усе одно корисний після деплою нової версії - зміна префікса дає чистий кеш без `FLUSHDB`. І не викликайте `Yii::$app->cache->flush()` на проді: воно чистить усе, включно зі схемою БД і сесіями, якщо вони в тому ж сторі.

оновлено 3 жовтня 2026 · ліцензія CC-BY-SA-4.0 Знайшли неточність? Напишіть →