Ваше веб-додаток на Laravel починає гальмувати: сторінки завантажуються 3+ секунди, база даних падає під навантаженням 1000 RPS. Типова ситуація — SQL-запити з JOIN та агрегацією виконуються 200–500 мс, а зі зростанням кількості користувачів черга запитів збільшується. Рішення — впровадити кеш-шар на Redis. Ми налаштовуємо Redis для кешування веб-додатків уже 5+ років, реалізували понад 50 проектів. Гарантуємо hit rate вище 90% та зниження часу відповіді до 50 мс. Замовте налаштування Redis під ключ — отримайте консультацію інженера.
Чому Redis швидший за SQL?
Redis зберігає дані в оперативній пам'яті, тому читання займає <1 мс проти 10-500 мс у SQL. Це робить його в 100 разів швидшим для операцій типу GET. Крім того, Redis підтримує атомарні операції та структури даних (списки, множини), що дозволяє виконувати складні запити без SQL.
Які проблеми вирішує Redis?
- Повільні SQL-запити: SELECT з COUNT, SUM, GROUP BY виконуються 200-500 мс. Кеш скорочує час до 1 мс.
- N+1 запити: один HTTP-запит породжує десятки SQL у циклі. Кеш з ключами по ID прибирає цю проблему.
- Висока вартість обчислень: дорогі операції (розрахунки рейтингу, рекомендації) кешуються на 5–10 хвилин.
Установка та базова конфігурація
Установка Redis через пакетний менеджер: apt install redis-server. Конфігурація /etc/redis/redis.conf:
bind 127.0.0.1
requirepass YourStrongRedisPassword
maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
appendonly no
databases 16
timeout 300
tcp-keepalive 300
Докладніше про налаштування
`maxmemory` встановлює ліміт пам'яті Redis. При перевищенні спрацьовує політика витіснення (наприклад, `allkeys-lru`). Відключайте `save` та `appendonly` для чистого кешу.Політики витіснення детально описані в документації Redis. Рекомендуємо allkeys-lru для чистого кешу, allkeys-lfu для нерівномірного доступу.
Чому варто використовувати окрему базу даних Redis для кешу?
У Laravel ми вказуємо database: 1 в конфігурації кешу. Це ізолює кеш від сесій та черг, запобігаючи витісненню важливих даних:
// config/database.php
'redis' => [
'client' => env('REDIS_CLIENT', 'phpredis'),
'options' => [
'cluster' => env('REDIS_CLUSTER', 'redis'),
'prefix' => env('REDIS_PREFIX', 'myapp_'),
],
'default' => [
'host' => env('REDIS_HOST', '127.0.0.1'),
'password' => env('REDIS_PASSWORD'),
'port' => env('REDIS_PORT', '6379'),
'database' => env('REDIS_DB', '0'),
],
'cache' => [
'host' => env('REDIS_HOST', '127.0.0.1'),
'password' => env('REDIS_PASSWORD'),
'port' => env('REDIS_PORT', '6379'),
'database' => env('REDIS_CACHE_DB', '1'),
],
],
Базові патерни кешування
Cache-Aside (Lazy Loading) — додаток сам керує кешем: спочатку читає з Redis, при промаху — з бази, кладе в Redis:
class ProductRepository
{
private const CACHE_TTL = 3600;
public function findById(int $id): ?Product
{
$cacheKey = "product:{$id}";
$cached = $this->redis->get($cacheKey);
if ($cached !== false) {
return unserialize($cached);
}
$product = $this->db->find(Product::class, $id);
if ($product) {
$this->redis->setex($cacheKey, self::CACHE_TTL, serialize($product));
}
return $product;
}
public function save(Product $product): void
{
$this->db->persist($product);
$this->db->flush();
$this->redis->del("product:{$product->getId()}");
}
}
Write-Through — при записі в базу одночасно оновлюємо кеш. Плюс: кеш завжди актуальний. Мінус: запис повільніший, кешуються дані, які можливо не будуть читатися.
Як вибрати політику витіснення?
Вибір залежить від сценарію:
| Політика | Опис | Коли використовувати | Очікуваний hit rate |
|---|---|---|---|
allkeys-lru |
Видаляє давно невикористовувані ключі | Чистий кеш, рівномірний доступ | >95% |
allkeys-lfu |
Видаляє рідко використовувані ключі | Zipf-розподіл (20% ключів дають 80% звернень) | >90% |
volatile-lru |
Видаляє ключі з TTL | Коли є постійні ключі без TTL | >85% |
noeviction |
Повертає помилку при нестачі пам'яті | Черги, сесії | — |
Рекомендовані TTL для різних типів даних
| Тип даних | TTL | Приклад |
|---|---|---|
| Список товарів | 1 година | products:featured |
| Картка товару | 2 години | product:{id} |
| Статистика дашборду | 5 хвилин | stats:dashboard |
| Сесії користувачів | 24 години | session:{token} |
Кешування в Laravel
Laravel підтримує Redis як cache driver з коробки. У config/cache.php достатньо вказати 'default' => env('CACHE_DRIVER', 'redis'). Після цього можна використовувати:
// Кеш з автоматичним обчисленням при промаху
$products = Cache::remember('products:featured', 3600, function () {
return Product::where('is_featured', true)->with('category')->get();
});
// Теги для групової інвалідації
$product = Cache::tags(['products', 'category:5'])->remember(
"product:{$id}", 3600, fn() => Product::find($id)
);
Cache::tags(['products'])->flush();
Теги працюють тільки з Redis та Memcached. Для важких агрегацій — статистика дашборду з TTL 5 хвилин.
Моніторинг кешу
Для production використовуємо Redis Exporter + Grafana (дашборд ID 11835). Ключові метрики:
redis-cli -a password INFO stats | grep -E "keyspace_hits|keyspace_misses|used_memory_human"
# Hit rate = hits / (hits + misses) > 90%
# Розмір кожної групи ключів
redis-cli -a password --bigkeys
Запуск експортера:
docker run -d --name redis_exporter -p 9121:9121 oliver006/redis_exporter --redis.addr=redis://localhost:6379 --redis.password=YourPassword
Моніторинг описаний в документації Laravel. Рекомендуємо налаштувати алерти при падінні hit rate нижче 85%.
Процес роботи
- Аудит поточного коду: виявляємо вузькі місця та N+1 запити.
- Проектування кеш-шару: визначаємо, що кешувати, TTL, ключі.
- Реалізація: налаштування Redis, впровадження кешування в код, інвалідація.
- Тестування: навантажувальне тестування, вимірювання hit rate.
- Деплой та моніторинг: встановлення експортера, дашборду, алертів.
Що входить у роботу
- Конфігурація Redis під ваше навантаження.
- Інтеграція з Laravel cache driver.
- Реалізація кешування для 3–5 ключових запитів (за домовленістю).
- Налаштування моніторингу (Grafana + Redis Exporter).
- Документація по використовуваних ключах та TTL.
- Навчання команди (1 година).
- Підтримка протягом 1 місяця після впровадження.
Строки та вартість
Базова налаштування Redis з інтеграцією в Laravel — від 2 до 5 робочих днів. Вартість розраховується індивідуально, залежить від складності проекту та кількості кешованих місць. Зв'яжіться з нами для оцінки.
Типові помилки при кешуванні
- Кешування всього підряд: кеш не потрібен для даних, які рідко читаються або швидко змінюються.
- Занадто довгий TTL: дані застарівають, користувачі бачать неактуальну інформацію.
- Забули інвалідацію: кеш не очищається при оновленні даних, в результаті помилки.
- Неправильна політика витіснення: якщо Redis заповнений, часто використовувані ключі можуть бути витіснені.
- Відсутність моніторингу: не можна оцінити ефективність кешу без метрик.
Уникаючи цих помилок та використовуючи описані патерни, ви отримаєте стабільний та швидкий веб-додаток. Замовте налаштування Redis — наші інженери допоможуть впровадити кеш-шар з гарантією результату.