Scheduler у Laravel — це стандартний механізм для всього, що має виконуватися регулярно: щохвилини, щогодини, щодня, за ніч, у певний час доби. Його сила в тому, що ви перестаєте “костилити” окремі cron-команди під кожну задачу: у системі є один cron-тригер, який запускає scheduler, а далі Laravel сам вирішує, які задачі треба виконати в цей момент. Якщо ви робите реальну систему (CMS, фінанси, аналітика), scheduler стає обов’язковим, бо “підтримуючі” процеси завжди накопичуються.
Почнемо з того, для чого scheduler доречний. Періодичні задачі — це все, що або підтримує дані в актуальному стані, або формує похідні дані, або прибирає сміття. У новинному проєкті це може бути: оновлення кешів блоків, перерахунок рейтингу “популярне”, генерація sitemap, чистка старих тимчасових файлів, синхронізація статистики, повторна обробка медіа, перевірка “завислих” публікацій. У бізнес-системі — закриття періодів, нарахування, нагадування про прострочки, звірка станів, регулярні імпорти/експорти, архівація логів. Головна ознака: це не реакція на один HTTP-запит, а “обслуговування” системи в часі.
Друга частина теми — health-checks. Health-check — це контроль того, що scheduler реально працює і що система не “тихо померла”. У продакшені найчастіша проблема не “код зламався”, а “cron перестав виконуватися” або “queue worker зупинився” після ребута/оновлення/вильоту. Якщо ви не маєте health-check, ви можете не помітити це тижнями, поки не накопичиться сміття або не зірвуться процеси (наприклад, не перерахувався кеш, не відправились нотифікації).
Як правильно мислити scheduler у навчанні. Вам потрібно засвоїти три речі: які задачі робити синхронно, які — через queue, і які — через scheduler. Scheduler не замінює queue. Scheduler — це “коли запускати”, а queue — це “як виконувати у фоні”. Часто правильна зв’язка така: scheduler кожні N хвилин ставить у чергу jobs або запускає команду, яка диспатчить jobs. Тобто scheduler — диригент, queue — робочі.
Щоб не перетворити scheduler на джерело проблем, є два базових ризики: дублювання виконань і “накопичення” довгих задач. Дублювання трапляється, коли задача запускається повторно, поки попередня ще не завершилась. Це може створити дублікати (надіслали два листи), гонки (перерахунок кешу одночасно), блокування БД. Тому правило: для критичних задач потрібен механізм “не запускати паралельно” або “lock”. Другий ризик — довгі задачі в scheduler. Якщо задача триває 10 хвилин, а ви запускаєте її щохвилини, у вас утвориться черга виконань і система почне задихатися. Тому довгі речі — або рідше, або в queue з контролем воркерів, або розбивати на дрібні jobs.
Тепер — практична структура періодичних задач, яку варто навчити людину робити з самого початку.
Перший клас задач: “підтримка і чистка” (maintenance). Це регулярне прибирання: тимчасові файли, старі чернетки, старі токени, непотрібні записи, лог-файли, кеш-ключі. Такі задачі зазвичай запускають вночі або щогодини, і вони повинні бути безпечними: нічого не видаляти без умов, мати ліміти (пакетами), логувати результат. Це важливо, бо чистка — типова зона фатальних помилок (“видалили зайве”).
Другий клас: “перерахунки/агрегації” (rebuild/recalc). Це, наприклад, рейтинги, підсумки, лічильники, “популярне”. Тут правило: робити це або інкрементально, або з кешем, або пакетно. Scheduler запускає перерахунок, але перерахунок не має валити БД. Тому ви обмежуєте діапазон (останній день/тиждень), ставите індекси, і по можливості кешуєте результат.
Третій клас: “перевірки станів” (watchdogs). Це і є health-checks. Вони не повинні бути важкими. Вони повинні швидко відповісти на питання: “scheduler взагалі живий?”, “черги працюють?”, “чи є завислі задачі?”, “чи є failed jobs?”. На практиці це регулярний запис “heartbeat” у БД або cache, плюс перевірка, що він оновлюється.
Здоровий health-check складається з двох рівнів. Перший — heartbeat scheduler: задача раз на хвилину/5 хвилин пише в БД/кеш поточний timestamp. Другий — watchdog, який перевіряє: якщо heartbeat старший за, скажімо, 10 хвилин — scheduler не працює, треба сигнал. Аналогічно для queue: воркер пише heartbeat або ви перевіряєте, що не накопичується backlog і що немає масових failed jobs. Це не “розкіш”, це раннє попередження.
Що саме вимірювати в health-checks. Мінімум: останній запуск scheduler (timestamp), кількість failed jobs за останню годину/добу, кількість jobs у черзі (backlog) по ключових чергах, і наявність “завислих” статусів у ваших таблицях (наприклад, медіа зі статусом processing довше N хвилин). Ці перевірки дають вам відповідь: система працює або потроху помирає.
Ще один важливий момент — логування результатів scheduler-задач. Якщо задача виконується регулярно, ви повинні бачити хоча б короткий лог: коли стартувала, скільки зробила, чи була помилка. Інакше ви не зможете розібратися, чому “популярне” не оновлюється або чому sitemap застарів. Для навчання достатньо дисципліни: кожна scheduled задача має писати короткий підсумок у лог.
Типова помилка новачків — намагатися через scheduler робити те, що має бути подієвим. Наприклад, “кожні 5 хвилин перевіряти, чи треба відправити лист після публікації”. Це погано, бо лист має летіти одразу після події публікації — через job. Scheduler потрібен як страховка (наприклад, знайти ті, що не відправились через збій), а не як основний механізм реакції. Тобто scheduler — для регулярного, queue — для реактивного.
Висновок: Scheduler — це контроль часу в системі. Він запускає регулярні “обслуговуючі” задачі та перевірки стану, щоб система не деградувала тихо. Періодичні задачі доречні для чистки, агрегацій і перевірок. Health-checks потрібні, щоб одразу бачити, коли cron/worker перестав працювати, і щоб ловити завислі процеси та failed jobs. Якщо ви навчитеся поєднувати scheduler як диригента і queue як виконавця, ви отримаєте систему, яка стабільно працює місяцями без ручного “підкручування”.
