Налаштування Cron-завдань: планувальник, моніторинг, захист від дублів

Чому налаштування cron-завдань — це не просто crontab?

Cron — старий добрий демон, який запускає команди за розкладом. Але покластися на crontab без моніторингу та захисту від дублів — означає ризикувати продакшеном. Уявіть: щохвилини запускається завдання надсилання дайджесту, але поки виконується старе, нове накладається — база падає під навантаженням. Або завдання очищення токенів не виконалося, а ми дізналися через тиждень. У нашому проекті з 500 000 користувачів таке сталося: через дублі впала продуктивність на 40%, довелося терміново лагодити. Професійне налаштування cron-завдань — це розподілені блокування, моніторинг виконання та автоматичні сповіщення про помилки. Ми — команда з 5+ років досвіду та 200+ виконаними проектами — налаштували сотні таких завдань для проектів на Laravel, Node.js та Go. Розповімо, як зробити це правильно.

Які проблеми вирішує професійне налаштування?

Як уникнути дублювання при горизонтальному масштабуванні?

Якщо у вас два сервери та crontab на обох — завдання запуститься двічі. Рішення — onOneServer() в Laravel або distributed lock через Redis. Приклад нижче. Без цього подвійні розсилки, подвійні списання та зайве навантаження на БД — гарантовані. На одному проекті ми допомогли клієнту заощадити $12,000 на рік, виключивши дублювання завдань.

Втрата виконання та пропущені помилки

Без моніторингу ви не дізнаєтеся, що завдання не виконалося 3 дні. Використовуємо Healthchecks.io або кастомні сповіщення в Telegram/Slack. В Laravel вбудовано pingOnFailure() — це в 10 разів надійніше, ніж перевіряти логи вручну. Тільки за останні 12 місяців ми зафіксували понад 50 інцидентів, де моніторинг врятував проект.

Конфлікти блокувань та стану гонки

--withoutOverlapping та withoutOverlapping(5) в Laravel — задають максимальний час перекриття. В Node.js — acquireLock з TTL. Без цього дві копії завдання можуть одночасно читати та записувати одні дані, що призводить до пошкодження бази. Втрати від пропущених завдань можуть досягати $5,000 на місяць.

Як ми налаштовуємо cron-завдання: стек та приклади

Laravel Task Scheduling (основний стек)

Laravel — наш основний бекенд-фреймворк. php artisan schedule:run викликає конфіг app/Console/Kernel.php. Приклад:

// app/Console/Kernel.php
protected function schedule(Schedule $schedule): void
{
    // Щоденний дайджест о 9:00 за Москвою
    $schedule->job(SendDailyDigestJob::class)
        ->dailyAt('09:00')
        ->timezone('Europe/Moscow')
        ->withoutOverlapping()      // не запускати, якщо попередній ще працює
        ->onOneServer()             // тільки на одному сервері при горизонтальному масштабуванні
        ->runInBackground();

    // Очищення застарілих сесій — щогодини
    $schedule->command('sessions:cleanup')
        ->hourly()
        ->withoutOverlapping(5)     // максимум 5 хвилин на перекриття
        ->appendOutputTo(storage_path('logs/sessions-cleanup.log'));

    // Щохвилинна перевірка черги сповіщень
    $schedule->command('notifications:send-pending')
        ->everyMinute()
        ->runInBackground()
        ->skip(fn() => !config('features.notifications'));
}

# Crontab: запускати планувальник щохвилини
* * * * * cd /var/www/myapp && php artisan schedule:run >> /dev/null 2>&1

Node.js: node-cron

import cron from 'node-cron';
import { db } from './database';
import { emailService } from './services/email';

// Щоденне очищення о 3:00
cron.schedule('0 3 * * *', async () => {
  const lock = await acquireLock('cleanup-expired-tokens');
  if (!lock) return;  // інший інстанс вже виконує

  try {
    const deleted = await db.query(
      'DELETE FROM password_reset_tokens WHERE expires_at < NOW()'
    );
    console.log(`Cleaned ${deleted.rowCount} expired tokens`);
  } finally {
    await releaseLock('cleanup-expired-tokens');
  }
}, { timezone: 'Europe/Moscow' });

// Кожні 5 хвилин: оновлення курсів валют
cron.schedule('*/5 * * * *', async () => {
  try {
    const rates = await fetchExchangeRates();
    await cache.set('exchange_rates', rates, 300);
  } catch (err) {
    console.error('Exchange rates update failed:', err);
  }
});

Distributed Lock через Redis (запобігання дублюванню)

// Для Laravel: стандартний Cache::lock()
$schedule->call(function () {
    $lock = Cache::lock('daily-digest', 3600);

    if (!$lock->get()) {
        return;  // інший сервер вже виконує
    }

    try {
        app(DigestService::class)->sendAll();
    } finally {
        $lock->release();
    }
})->dailyAt('09:00')->onOneServer();

Моніторинг: Healthchecks.io / Laravel Health

// Сповіщення про помилки планувальника
$schedule->job(SendDailyDigestJob::class)
    ->dailyAt('09:00')
    ->pingOnSuccess('https://hc-ping.com/success-uuid')
    ->pingOnFailure('https://hc-ping.com/fail-uuid')
    ->emailOutputOnFailure('[email protected]');

Порівняння підходів: Laravel Schedule vs node-cron vs go-cron

Типові помилки та їх наслідки

Чому важливий моніторинг?

Без моніторингу ви ризикуєте виявити проблему занадто пізно. У нашій практиці був випадок: клієнт не знав, що завдання генерації звітів не працювало 2 тижні — дані застаріли на 30%. Після впровадження моніторингу з алертами в Telegram час реакції скоротився до 15 хвилин. Рекомендуємо пінгувати health endpoint щохвилини — це покриває 99% сценаріїв.

Що входить в роботу (deliverables)

• Код завдань з захистом від дублів (distributed lock).
• Моніторинг виконання (Healthchecks.io або свій).
• Сповіщення про помилки (Slack, Telegram, email).
• Документація з підтримки та додавання нових завдань.
• Навчання команди замовника.

Терміни орієнтовно

• Просте налаштування (2-3 завдання): від 1 дня.
• Комплексна з моніторингом та блокуваннями: від 2 днів.

Процес роботи

1. Аналітика — з'ясовуємо, які завдання потрібні: очищення кешу, розсилки, генерація звітів.
2. Проектування — визначаємо інтервали, блокування, моніторинг.
3. Реалізація — пишемо код з обробкою помилок та withoutOverlapping.
4. Тестування — запускаємо в стейджингу, перевіряємо логи.
5. Деплой — налаштовуємо crontab та healthchecks.

Наші інженери гарантують, що ваш планувальник працюватиме стабільно. Якщо ви хочете уникнути проблем з дублями — замовте професійне налаштування cron-завдань. Зв'яжіться з нами, оцінимо проект безкоштовно.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.