---
title: "Queue::forward(): маршрутизація Laravel-черг в одному місці"
url: https://laravelukraine.com/blog/queueforward-marsrutizaciia-laravel-cerg-v-odnomu-misci
date: 2026-08-21
source: https://laravel-news.com/laravel-queue-forward?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+laravelnews
---

# Queue::forward(): маршрутизація Laravel-черг в одному місці

Назви черг мають властивість «вбудовуватися» всюди. Клас job встановлює `onQueue('reports')`, місце виклику додає `->onConnection('redis')`, атрибут `#[Queue]` закріплює інше значення, а флот воркерів налаштований відповідно. Потім черга reports починає «душити» всі інші, і ви хочете винести її на окремий екземпляр Redis, або переносите production на керований сервіс черг, який вимагає FIFO-іменування - і зміна торкається кожного з цих місць одночасно, плюс сторонні пакети, що відправляють завдання у черги, які ви не контролюєте.

## Новий метод Queue::forward()

[Laravel 13.26](https://laravel-news.com/laravel-13-26-0) додає `Queue::forward()`, внесений [@jackbayliss](https://github.com/jackbayliss) у [
#61188](https://github.com/laravel/framework/pull/61188). Він оголошує в одному місці, що все, відправлене в певну чергу, має потрапити в іншу чергу, інше з'єднання або обидва варіанти. Класи job, місця виклику dispatch і vendor-пакети продовжують говорити `reports` - forward вирішує, що це означає сьогодні.

## API методу

Усі варіанти приймають чергу для збігу та призначення:

```php
use Illuminate\Support\Facades\Queue;

// Перейменувати чергу та перенести на інше з'єднання
Queue::forward('reports', 'reports.fifo', 'cloud');

// Зберегти ім'я, змінити з'єднання
Queue::forward('payments', connection: 'cloud');

// Перейменувати на тому ж з'єднанні
Queue::forward('updates', 'notifications');

// Кілька одночасно
Queue::forward([
    'reports' => 'reports.fifo',
    'emails' => 'emails.fifo',
], connection: 'cloud');
```

Імена черг можуть бути рядками або backed enum, відповідно до підтримки enum, яку черги отримали раніше. Виклики належать до методу `boot()` сервіс-провайдера, і вони компонуються з рештою системи черг, оскільки forwarding розв'язується через той самий хук `getConnection()`, який використовує `Queue::route()`, а перейменування застосовується власним механізмом розв'язання черг кожного драйвера. Немає нового контракту для реалізації користувацькими драйверами.

## Тонкощі збігу

Одна тонкість у збігу: forward, що вказує з'єднання, перезаписує ім'я черги лише для job, які прямували до цього з'єднання. `Queue::forward('reports', 'reports.fifo', 'cloud')` перейменовує `reports` на з'єднанні `cloud` і переміщує туди нецільові виклики `reports`, але job, явно відправлена в `reports` на вашому з'єднанні `redis`, зберігає своє ім'я. Forwards - це маппінг, а не глобальний find-and-replace.

## Маршрутизація за середовищем

Дизайн реєстрації-в-провайдері робить маршрутизацію умовною способами, в яких конфігураційні файли погані. Канонічний випадок з PR - застосунок, що запускає Redis локально та керований сервіс черг у production:

```php
namespace App\Providers;

use Illuminate\Support\Facades\Queue;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        if ($this->app->isProduction()) {
            Queue::forward([
                'reports' => 'reports.fifo',
                'emails' => 'emails.fifo',
            ], connection: 'cloud');
        }
    }
}
```

Локально `dispatch(new GenerateReport)` йде в `reports` на Redis, і `queue:work` підбирає його як завжди. У production ідентичний код потрапляє в `reports.fifo` на керованому з'єднанні. Ніяких перевірок середовища в класах job і ніякої акробатики в `config/queue.php`, щоб одна назва черги означала дві речі.

## Операційні переміщення

Та сама форма покриває операційні переміщення, які раніше вимагали deploy з торканням багатьох файлів:

```php
// Черга encoding топить дефолтний екземпляр Redis:
Queue::forward('encoding', connection: 'redis-heavy');

// Випробувати нове з'єднання з однією нерискованою чергою перед комітом:
Queue::forward('notifications', connection: 'sqs-experiment');
```

Оскільки forward - це один рядок, відкат - це його видалення. Це робить практичними поступові розгортання з'єднань: перемістити чергу, спостерігати, перемістити наступну.

## Що forwarding не робить

Forward застосовується під час dispatch - до job, що входять у чергу з цього моменту. Job, що вже сидять у старій черзі, залишаються там, тому перемикання потребує воркерів, що дренують стару назву, доки вона не спорожніє. PR явно вказує на стаціонарний стан: тривале запуск воркерів проти оригінальної та перенаправленої назв запрошує race conditions, тому коли forward на місці, трактуйте стару назву як deprecated і виведіть її воркерів після дренажу.

## Суміжні можливості

Кілька суміжних нюансів. Forwarding переписує призначення, він не призупиняє чи throttle нічого; для зупинки споживання є [API паузи черг з Laravel 13.25](https://laravel-news.com/laravel-13-25-0). І якщо ваші listeners, а не jobs, є галасливою частиною системи, цей реліз також поставив [debounced queued listeners](https://laravel-news.com/laravel-debounced-queued-listeners), які атакують обсяг черги з іншого кінця.

## Подальше читання

- [Нотатки релізу Laravel 13.26](https://laravel-news.com/laravel-13-26-0) для всього іншого в цьому релізі
- [Laravel Jobs and Queue 101: з'єднання, множинні черги та пріоритети](https://laravel-news.com/laravel-jobs-queues-101) - основи, які ця функція обходить
- [Пауза всіх черг у Laravel 13.25](https://laravel-news.com/laravel-13-25-0) - компаньйон-контроль для зупинки споживання замість перенаправлення
