큐

• 소개
  • 연결 대 큐
  • 드라이버 참고 사항 및 필수 조건
• 작업 생성
  • 작업 클래스 생성
  • 클래스 구조
  • 고유 작업
  • 암호화된 작업
• 작업 미들웨어
  • 속도 제한
  • 작업 중복 방지
  • 예외 스로틀링
  • 작업 건너뛰기
• 작업 디스패치
  • 지연된 디스패치
  • 동기 디스패치
  • 작업 및 데이터베이스 트랜잭션
  • 작업 체이닝
  • 큐 및 연결 사용자 지정
  • 최대 작업 시도 횟수 / 시간 초과 값 지정
  • 오류 처리
• 작업 일괄 처리
  • 일괄 처리 가능한 작업 정의
  • 일괄 처리 디스패치
  • 체인 및 일괄 처리
  • 일괄 처리에 작업 추가
  • 일괄 처리 검사
  • 일괄 처리 취소
  • 일괄 처리 실패
  • 일괄 처리 정리
  • DynamoDB에 일괄 처리 저장
• 큐에 넣는 클로저
• 큐 워커 실행
  • queue:work 명령어
  • 큐 우선 순위
  • 큐 워커 및 배포
  • 작업 만료 및 시간 초과
• Supervisor 구성
• 실패한 작업 처리
  • 실패한 작업 정리
  • 실패한 작업 재시도
  • 누락된 모델 무시
  • 실패한 작업 정리
  • DynamoDB에 실패한 작업 저장
  • 실패한 작업 저장 비활성화
  • 실패한 작업 이벤트
• 큐에서 작업 지우기
• 큐 모니터링
• 테스팅
  • 작업 하위 집합 페이킹
  • 작업 체인 테스트
  • 작업 일괄 처리 테스트
  • 작업 / 큐 상호 작용 테스트
• 작업 이벤트

소개

웹 애플리케이션을 구축하는 동안 일반적인 웹 요청 중에 수행하는 데 너무 오래 걸리는 업로드된 CSV 파일을 구문 분석하고 저장하는 것과 같은 작업이 있을 수 있습니다. 다행히도 Laravel을 사용하면 백그라운드에서 처리할 수 있는 대기열 작업을 쉽게 만들 수 있습니다. 시간이 많이 걸리는 작업을 큐로 이동하여 애플리케이션이 웹 요청에 매우 빠른 속도로 응답하고 고객에게 더 나은 사용자 경험을 제공할 수 있습니다.

Laravel 큐는 Amazon SQS, Redis 또는 관계형 데이터베이스와 같은 다양한 큐 백엔드에서 통합된 큐 API를 제공합니다.

Laravel의 큐 구성 옵션은 애플리케이션의 config/queue.php 구성 파일에 저장됩니다. 이 파일에는 데이터베이스, Amazon SQS, Redis 및 Beanstalkd 드라이버를 포함하여 프레임워크에 포함된 각 큐 드라이버의 연결 구성과 작업을 즉시 실행하는 동기 드라이버(로컬 개발 중에 사용)가 있습니다. 큐에 넣은 작업을 삭제하는 null 큐 드라이버도 포함되어 있습니다.

연결 대 큐

Laravel 큐를 시작하기 전에 "연결"과 "큐"의 차이점을 이해하는 것이 중요합니다. config/queue.php 구성 파일에는 connections 구성 배열이 있습니다. 이 옵션은 Amazon SQS, Beanstalk 또는 Redis와 같은 백엔드 큐 서비스에 대한 연결을 정의합니다. 그러나 주어진 큐 연결에는 큐에 넣은 작업의 서로 다른 스택 또는 더미라고 생각할 수 있는 여러 개의 "큐"가 있을 수 있습니다.

queue 구성 파일의 각 연결 구성 예제에는 queue 속성이 포함되어 있습니다. 이것은 작업이 주어진 연결로 전송될 때 디스패치될 기본 큐입니다. 즉, 디스패치할 큐를 명시적으로 정의하지 않고 작업을 디스패치하는 경우, 작업은 연결 구성의 queue 속성에 정의된 큐에 배치됩니다.

use App\Jobs\ProcessPodcast;
 
// 이 작업은 기본 연결의 기본 큐로 전송됩니다...
ProcessPodcast::dispatch();
 
// 이 작업은 기본 연결의 "emails" 큐로 전송됩니다...
ProcessPodcast::dispatch()->onQueue('emails');

일부 애플리케이션에서는 여러 큐에 작업을 푸시할 필요가 없을 수도 있고, 대신 하나의 간단한 큐를 사용하는 것을 선호할 수도 있습니다. 그러나 Laravel 큐 워커를 통해 우선 순위에 따라 처리해야 할 큐를 지정할 수 있으므로 여러 큐에 작업을 푸시하는 것은 작업을 처리하는 방법을 우선 순위 지정하거나 분할하려는 애플리케이션에 특히 유용할 수 있습니다. 예를 들어 high 큐에 작업을 푸시하는 경우, 더 높은 처리 우선 순위를 제공하는 워커를 실행할 수 있습니다.

php artisan queue:work --queue=high,default

드라이버 참고 사항 및 사전 요구 사항

데이터베이스

database 큐 드라이버를 사용하려면 작업을 저장할 데이터베이스 테이블이 필요합니다. 일반적으로 이것은 Laravel의 기본 0001_01_01_000002_create_jobs_table.php 데이터베이스 마이그레이션에 포함되어 있습니다. 그러나 애플리케이션에 이 마이그레이션이 포함되어 있지 않은 경우 make:queue-table Artisan 명령을 사용하여 만들 수 있습니다.

php artisan make:queue-table
 
php artisan migrate

Redis

redis 큐 드라이버를 사용하려면 config/database.php 구성 파일에서 Redis 데이터베이스 연결을 구성해야 합니다.

Redis 클러스터

Redis 큐 연결에서 Redis 클러스터를 사용하는 경우, 큐 이름에 키 해시 태그가 포함되어 있어야 합니다. 이는 특정 큐에 대한 모든 Redis 키가 동일한 해시 슬롯에 배치되도록 하기 위해 필요합니다.

'redis' => [
    'driver' => 'redis',
    'connection' => env('REDIS_QUEUE_CONNECTION', 'default'),
    'queue' => env('REDIS_QUEUE', '{default}'),
    'retry_after' => env('REDIS_QUEUE_RETRY_AFTER', 90),
    'block_for' => null,
    'after_commit' => false,
],

블로킹

Redis 큐를 사용하는 경우, block_for 구성 옵션을 사용하여 드라이버가 작업이 사용 가능해질 때까지 대기해야 하는 시간을 지정할 수 있습니다. 해당 시간 동안 드라이버는 워커 루프를 반복하고 Redis 데이터베이스를 다시 폴링합니다.

큐 로드에 따라 이 값을 조정하면 새로운 작업을 위해 Redis 데이터베이스를 지속적으로 폴링하는 것보다 더 효율적일 수 있습니다. 예를 들어, 드라이버가 작업이 사용 가능해질 때까지 5초 동안 대기하도록 하려면 값을 5로 설정할 수 있습니다.

'redis' => [
    'driver' => 'redis',
    'connection' => env('REDIS_QUEUE_CONNECTION', 'default'),
    'queue' => env('REDIS_QUEUE', 'default'),
    'retry_after' => env('REDIS_QUEUE_RETRY_AFTER', 90),
    'block_for' => 5,
    'after_commit' => false,
],

기타 드라이버 전제 조건

나열된 큐 드라이버에는 다음 종속성이 필요합니다. 이러한 종속성은 Composer 패키지 관리자를 통해 설치할 수 있습니다.

작업 생성

작업 클래스 생성

기본적으로 애플리케이션의 모든 대기열 작업은 app/Jobs 디렉토리에 저장됩니다. app/Jobs 디렉토리가 존재하지 않으면 make:job Artisan 명령을 실행할 때 생성됩니다.

php artisan make:job ProcessPodcast

생성된 클래스는 Illuminate\Contracts\Queue\ShouldQueue 인터페이스를 구현하여 Laravel에게 해당 작업이 비동기적으로 실행되도록 큐에 푸시되어야 함을 나타냅니다.

클래스 구조

작업 클래스는 매우 간단하며, 일반적으로 큐에서 작업을 처리할 때 호출되는 handle 메서드만 포함합니다. 시작하려면 작업 클래스의 예시를 살펴보겠습니다. 이 예시에서는 팟캐스트 게시 서비스를 관리하고 있으며 게시하기 전에 업로드된 팟캐스트 파일을 처리해야 한다고 가정합니다.

<?php
 
namespace App\Jobs;
 
use App\Models\Podcast;
use App\Services\AudioProcessor;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
 
class ProcessPodcast implements ShouldQueue
{
    use Queueable;
 
    /**
     * 새 작업 인스턴스를 생성합니다.
     */
    public function __construct(
        public Podcast $podcast,
    ) {}
 
    /**
     * 작업을 실행합니다.
     */
    public function handle(AudioProcessor $processor): void
    {
        // 업로드된 팟캐스트 처리...
    }
}

이 예시에서는 Eloquent 모델을 큐에 추가된 작업의 생성자에 직접 전달할 수 있었습니다. 작업에서 사용 중인 Queueable 트레잇 덕분에 Eloquent 모델과 로드된 관계는 작업이 처리될 때 정상적으로 직렬화 및 역직렬화됩니다.

큐에 대기 중인 작업이 생성자에 Eloquent 모델을 허용하는 경우 모델의 식별자만 큐로 직렬화됩니다. 작업이 실제로 처리되면 큐 시스템은 데이터베이스에서 전체 모델 인스턴스 및 로드된 관계를 자동으로 다시 가져옵니다. 모델 직렬화에 대한 이 접근 방식은 큐 드라이버로 전송되는 작업 페이로드를 훨씬 작게 만들 수 있습니다.

handle 메서드 종속성 주입

handle 메서드는 큐에서 작업이 처리될 때 호출됩니다. 작업의 handle 메서드에서 종속성에 대한 타입 힌트를 지정할 수 있습니다. Laravel 서비스 컨테이너는 이러한 종속성을 자동으로 주입합니다.

컨테이너가 handle 메서드에 종속성을 주입하는 방법을 완전히 제어하려면 컨테이너의 bindMethod 메서드를 사용할 수 있습니다. bindMethod 메서드는 작업과 컨테이너를 받는 콜백을 허용합니다. 콜백 내에서 원하는 대로 handle 메서드를 자유롭게 호출할 수 있습니다. 일반적으로 App\Providers\AppServiceProvider 서비스 공급자의 boot 메서드에서 이 메서드를 호출해야 합니다.

use App\Jobs\ProcessPodcast;
use App\Services\AudioProcessor;
use Illuminate\Contracts\Foundation\Application;
 
$this->app->bindMethod([ProcessPodcast::class, 'handle'], function (ProcessPodcast $job, Application $app) {
    return $job->handle($app->make(AudioProcessor::class));
});

큐에 대기 중인 관계

큐에 작업을 추가할 때 로드된 모든 Eloquent 모델 관계도 직렬화되므로 직렬화된 작업 문자열이 때때로 매우 커질 수 있습니다. 또한, 작업이 역직렬화되고 모델 관계가 데이터베이스에서 다시 검색되면 전체적으로 검색됩니다. 작업 큐 프로세스 중에 모델이 직렬화되기 전에 적용된 이전의 관계 제약 조건은 작업이 역직렬화될 때 적용되지 않습니다. 따라서 주어진 관계의 하위 집합으로 작업하려면 큐에 대기 중인 작업 내에서 해당 관계를 다시 제약해야 합니다.

또는 관계가 직렬화되는 것을 방지하기 위해 속성 값을 설정할 때 모델에서 withoutRelations 메서드를 호출할 수 있습니다. 이 메서드는 로드된 관계가 없는 모델의 인스턴스를 반환합니다.

/**
 * 새 작업 인스턴스를 생성합니다.
 */
public function __construct(
    Podcast $podcast,
) {
    $this->podcast = $podcast->withoutRelations();
}

PHP 생성자 속성 승격을 사용하고 Eloquent 모델의 관계를 직렬화하지 않도록 지정하려면 WithoutRelations 속성을 사용할 수 있습니다.

use Illuminate\Queue\Attributes\WithoutRelations;
 
/**
 * 새 작업 인스턴스를 생성합니다.
 */
public function __construct(
    #[WithoutRelations]
    public Podcast $podcast,
) {}

작업이 단일 모델 대신 Eloquent 모델의 컬렉션 또는 배열을 받는 경우, 해당 컬렉션 내의 모델은 작업이 역직렬화되고 실행될 때 관계가 복원되지 않습니다. 이는 대량의 모델을 처리하는 작업에서 과도한 리소스 사용을 방지하기 위한 것입니다.

고유 작업

경우에 따라 특정 작업의 인스턴스가 한 번에 하나만 큐에 있도록 해야 할 수 있습니다. 작업 클래스에서 ShouldBeUnique 인터페이스를 구현하여 이 작업을 수행할 수 있습니다. 이 인터페이스는 클래스에서 추가 메서드를 정의할 필요가 없습니다.

<?php
 
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUnique;
 
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
    ...
}

위의 예시에서 UpdateSearchIndex 작업은 고유합니다. 따라서 작업의 다른 인스턴스가 이미 큐에 있고 처리를 완료하지 않은 경우 해당 작업은 디스패치되지 않습니다.

경우에 따라 작업을 고유하게 만드는 특정 "키"를 정의하거나 작업을 고유하게 유지하지 않는 시간 제한을 지정할 수 있습니다. 이를 위해 작업 클래스에서 uniqueId 및 uniqueFor 속성 또는 메서드를 정의할 수 있습니다.

<?php
 
use App\Models\Product;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUnique;
 
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
    /**
     * 제품 인스턴스입니다.
     *
     * @var \App\Product
     */
    public $product;
 
    /**
     * 작업의 고유 잠금이 해제되는 시간(초)입니다.
     *
     * @var int
     */
    public $uniqueFor = 3600;
 
    /**
     * 작업의 고유 ID를 가져옵니다.
     */
    public function uniqueId(): string
    {
        return $this->product->id;
    }
}

위의 예시에서 UpdateSearchIndex 작업은 제품 ID별로 고유합니다. 따라서 동일한 제품 ID로 작업을 새로 디스패치하면 기존 작업이 처리를 완료할 때까지 무시됩니다. 또한 기존 작업이 1시간 이내에 처리되지 않으면 고유 잠금이 해제되고 동일한 고유 키를 가진 다른 작업을 큐로 디스패치할 수 있습니다.

처리가 시작될 때까지 작업 고유하게 유지

기본적으로 고유 작업은 작업이 처리를 완료하거나 모든 재시도 시도에 실패한 후에 "잠금 해제"됩니다. 그러나 작업을 처리하기 직전에 잠금을 해제하려는 상황이 있을 수 있습니다. 이를 위해 작업은 ShouldBeUnique 계약 대신 ShouldBeUniqueUntilProcessing 계약을 구현해야 합니다.

<?php
 
use App\Models\Product;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUniqueUntilProcessing;
 
class UpdateSearchIndex implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
    // ...
}

고유 작업 잠금

내부적으로 ShouldBeUnique 작업이 디스패치되면 Laravel은 uniqueId 키로 잠금을 획득하려고 시도합니다. 잠금이 획득되지 않으면 작업이 디스패치되지 않습니다. 이 잠금은 작업이 처리를 완료하거나 모든 재시도 시도에 실패하면 해제됩니다. 기본적으로 Laravel은 이 잠금을 얻기 위해 기본 캐시 드라이버를 사용합니다. 그러나 잠금을 획득하기 위해 다른 드라이버를 사용하려는 경우 사용할 캐시 드라이버를 반환하는 uniqueVia 메서드를 정의할 수 있습니다.

use Illuminate\Contracts\Cache\Repository;
use Illuminate\Support\Facades\Cache;
 
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
    ...
 
    /**
     * 고유 작업 잠금에 대한 캐시 드라이버를 가져옵니다.
     */
    public function uniqueVia(): Repository
    {
        return Cache::driver('redis');
    }
}

암호화된 작업

Laravel을 사용하면 암호화를 통해 작업 데이터의 개인 정보 보호 및 무결성을 보장할 수 있습니다. 시작하려면 작업 클래스에 ShouldBeEncrypted 인터페이스를 추가하십시오. 이 인터페이스가 클래스에 추가되면 Laravel은 작업을 큐에 푸시하기 전에 자동으로 암호화합니다.

<?php
 
use Illuminate\Contracts\Queue\ShouldBeEncrypted;
use Illuminate\Contracts\Queue\ShouldQueue;
 
class UpdateSearchIndex implements ShouldQueue, ShouldBeEncrypted
{
    // ...
}

작업 미들웨어

작업 미들웨어를 사용하면 큐에 대기 중인 작업 실행 주위에 사용자 정의 로직을 래핑하여 작업 자체의 상용구 코드를 줄일 수 있습니다. 예를 들어, Laravel의 Redis 속도 제한 기능을 활용하여 5초마다 하나의 작업만 처리할 수 있도록 하는 다음 handle 메서드를 고려하십시오.

use Illuminate\Support\Facades\Redis;
 
/**
 * 작업을 실행합니다.
 */
public function handle(): void
{
    Redis::throttle('key')->block(0)->allow(1)->every(5)->then(function () {
        info('Lock obtained...');
 
        // Handle job...
    }, function () {
        // Could not obtain lock...
 
        return $this->release(5);
    });
}

이 코드는 유효하지만 handle 메서드의 구현은 Redis 속도 제한 로직으로 인해 복잡해지므로 번잡해집니다. 또한 이 속도 제한 로직은 속도 제한을 하려는 다른 모든 작업에 대해 복제해야 합니다.

handle 메서드에서 속도 제한을 하는 대신 속도 제한을 처리하는 작업 미들웨어를 정의할 수 있습니다. Laravel에는 작업 미들웨어에 대한 기본 위치가 없으므로 애플리케이션의 아무 곳에나 작업 미들웨어를 배치할 수 있습니다. 이 예에서는 미들웨어를 app/Jobs/Middleware 디렉토리에 배치합니다.

<?php
 
namespace App\Jobs\Middleware;
 
use Closure;
use Illuminate\Support\Facades\Redis;
 
class RateLimited
{
    /**
     * 큐에 대기 중인 작업을 처리합니다.
     *
     * @param  \Closure(object): void  $next
     */
    public function handle(object $job, Closure $next): void
    {
        Redis::throttle('key')
                ->block(0)->allow(1)->every(5)
                ->then(function () use ($job, $next) {
                    // 잠금 획득됨...
 
                    $next($job);
                }, function () use ($job) {
                    // 잠금을 얻을 수 없음...
 
                    $job->release(5);
                });
    }
}

보시다시피 라우트 미들웨어와 마찬가지로 작업 미들웨어는 처리 중인 작업과 작업 처리를 계속하기 위해 호출해야 하는 콜백을 받습니다.

작업 미들웨어를 생성한 후 작업의 middleware 메서드에서 반환하여 작업에 연결할 수 있습니다. 이 메서드는 make:job Artisan 명령으로 스캐폴딩된 작업에는 존재하지 않으므로 작업 클래스에 수동으로 추가해야 합니다.

use App\Jobs\Middleware\RateLimited;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [new RateLimited];
}

속도 제한

자체 속도 제한 작업 미들웨어를 작성하는 방법을 보여주었지만 Laravel에는 실제로 작업 속도 제한을 위해 사용할 수 있는 속도 제한 미들웨어가 포함되어 있습니다. 라우트 속도 제한기와 마찬가지로 작업 속도 제한기는 RateLimiter 파사드의 for 메서드를 사용하여 정의됩니다.

예를 들어, 프리미엄 고객에게는 그러한 제한을 적용하지 않으면서 사용자가 시간당 한 번 데이터를 백업하도록 허용할 수 있습니다. 이를 위해 AppServiceProvider의 boot 메서드에서 RateLimiter를 정의할 수 있습니다.

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
 
/**
 * 애플리케이션 서비스를 부트스트랩합니다.
 */
public function boot(): void
{
    RateLimiter::for('backups', function (object $job) {
        return $job->user->vipCustomer()
                    ? Limit::none()
                    : Limit::perHour(1)->by($job->user->id);
    });
}

위의 예시에서는 시간당 속도 제한을 정의했지만, perMinute 메서드를 사용하여 분 단위로 속도 제한을 쉽게 정의할 수 있습니다. 또한 속도 제한의 by 메서드에 원하는 값을 전달할 수 있습니다. 그러나 이 값은 고객별로 속도 제한을 분할하는 데 가장 자주 사용됩니다.

return Limit::perMinute(50)->by($job->user->id);

속도 제한을 정의했으면 Illuminate\Queue\Middleware\RateLimited 미들웨어를 사용하여 작업에 속도 제한기를 연결할 수 있습니다. 작업이 속도 제한을 초과할 때마다 이 미들웨어는 속도 제한 기간에 따라 적절한 지연 시간으로 작업을 큐에 다시 릴리스합니다.

use Illuminate\Queue\Middleware\RateLimited;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [new RateLimited('backups')];
}

속도 제한된 작업을 큐에 다시 릴리스하면 작업의 총 attempts 수가 여전히 증가합니다. 작업 클래스에서 tries 및 maxExceptions 속성을 적절하게 조정할 수 있습니다. 또는 retryUntil 메서드를 사용하여 작업을 더 이상 시도하지 않아야 할 시간(일)을 정의할 수 있습니다.

작업이 속도 제한될 때 재시도하지 않으려면 dontRelease 메서드를 사용할 수 있습니다.

/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new RateLimited('backups'))->dontRelease()];
}

작업 중복 방지

Laravel에는 임의 키를 기반으로 작업 중복을 방지할 수 있는 Illuminate\Queue\Middleware\WithoutOverlapping 미들웨어가 포함되어 있습니다. 이는 큐에 대기 중인 작업이 한 번에 하나의 작업에서만 수정해야 하는 리소스를 수정하는 경우에 유용할 수 있습니다.

예를 들어 사용자의 신용 점수를 업데이트하는 큐에 대기 중인 작업이 있고 동일한 사용자 ID에 대한 신용 점수 업데이트 작업 중복을 방지하려는 경우를 가정해 보겠습니다. 이를 위해 작업의 middleware 메서드에서 WithoutOverlapping 미들웨어를 반환할 수 있습니다.

use Illuminate\Queue\Middleware\WithoutOverlapping;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [new WithoutOverlapping($this->user->id)];
}

동일한 유형의 중복된 작업은 큐에 다시 릴리스됩니다. 또한 릴리스된 작업을 다시 시도하기 전에 경과해야 하는 시간(초)을 지정할 수도 있습니다.

/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new WithoutOverlapping($this->order->id))->releaseAfter(60)];
}

재시도되지 않도록 중복된 작업을 즉시 삭제하려면 dontRelease 메서드를 사용할 수 있습니다.

/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new WithoutOverlapping($this->order->id))->dontRelease()];
}

WithoutOverlapping 미들웨어는 Laravel의 원자적 잠금 기능으로 구동됩니다. 경우에 따라 작업이 예상치 않게 실패하거나 시간 초과되어 잠금이 해제되지 않을 수 있습니다. 따라서 expireAfter 메서드를 사용하여 잠금 만료 시간을 명시적으로 정의할 수 있습니다. 예를 들어 아래 예시는 Laravel에게 작업 처리가 시작된 후 3분 후에 WithoutOverlapping 잠금을 해제하도록 지시합니다.

/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new WithoutOverlapping($this->order->id))->expireAfter(180)];
}

작업 클래스 간 잠금 키 공유

기본적으로 WithoutOverlapping 미들웨어는 동일한 클래스의 중복 작업만 방지합니다. 따라서 서로 다른 두 작업 클래스가 동일한 잠금 키를 사용할 수 있지만 중복되는 것을 방지할 수는 없습니다. 그러나 Laravel에게 shared 메서드를 사용하여 작업 클래스 전체에 키를 적용하도록 지시할 수 있습니다.

use Illuminate\Queue\Middleware\WithoutOverlapping;
 
class ProviderIsDown
{
    // ...
 
    public function middleware(): array
    {
        return [
            (new WithoutOverlapping("status:{$this->provider}"))->shared(),
        ];
    }
}
 
class ProviderIsUp
{
    // ...
 
    public function middleware(): array
    {
        return [
            (new WithoutOverlapping("status:{$this->provider}"))->shared(),
        ];
    }
}

ProviderIsDown 클래스와 ProviderIsUp 클래스는 큐 미들웨어를 정의하는 예시입니다. WithoutOverlapping 미들웨어를 사용하여 동일한 공급자(provider)에 대한 작업이 동시에 실행되지 않도록 합니다. 각 클래스에서 middleware() 메소드는 미들웨어 배열을 반환하며, WithoutOverlapping 미들웨어는 작업 이름에 공급자 이름을 포함시켜 공유(shared)되도록 설정합니다.

예외 스로틀링

Laravel은 예외를 스로틀링할 수 있는 Illuminate\Queue\Middleware\ThrottlesExceptions 미들웨어를 포함하고 있습니다. 작업이 지정된 횟수만큼 예외를 발생시키면, 지정된 시간 간격이 경과할 때까지 해당 작업을 실행하려는 모든 시도가 지연됩니다. 이 미들웨어는 불안정한 타사 서비스와 상호 작용하는 작업에 특히 유용합니다.

예를 들어, 예외를 발생시키기 시작하는 타사 API와 상호 작용하는 대기열 작업을 가정해 보겠습니다. 예외를 스로틀링하려면 작업의 middleware 메서드에서 ThrottlesExceptions 미들웨어를 반환할 수 있습니다. 일반적으로 이 미들웨어는 시간 기반 시도를 구현하는 작업과 함께 사용해야 합니다.

use DateTime;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [new ThrottlesExceptions(10, 5 * 60)];
}
 
/**
 * 작업이 시간 초과되어야 하는 시간을 결정합니다.
 */
public function retryUntil(): DateTime
{
    return now()->addMinutes(30);
}

미들웨어에서 허용하는 첫 번째 생성자 인수는 작업이 스로틀링되기 전에 발생할 수 있는 예외 수이고, 두 번째 생성자 인수는 스로틀링된 후 작업을 다시 시도하기 전에 경과해야 하는 시간(초)입니다. 위의 코드 예제에서 작업이 10개의 연속 예외를 발생시키면 30분 시간 제한으로 제한되어 작업을 다시 시도하기 전에 5분을 기다립니다.

작업이 예외를 발생시키지만 예외 임계값에 아직 도달하지 않은 경우, 일반적으로 작업은 즉시 다시 시도됩니다. 그러나 미들웨어를 작업에 연결할 때 backoff 메서드를 호출하여 해당 작업이 지연되어야 하는 시간(분)을 지정할 수 있습니다.

use Illuminate\Queue\Middleware\ThrottlesExceptions;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new ThrottlesExceptions(10, 5 * 60))->backoff(5)];
}

내부적으로 이 미들웨어는 Laravel의 캐시 시스템을 사용하여 속도 제한을 구현하고 작업의 클래스 이름이 캐시 "키"로 사용됩니다. 미들웨어를 작업에 연결할 때 by 메서드를 호출하여 이 키를 재정의할 수 있습니다. 이는 여러 작업이 동일한 타사 서비스와 상호 작용하고 공통 스로틀링 "버킷"을 공유하려는 경우에 유용할 수 있습니다.

use Illuminate\Queue\Middleware\ThrottlesExceptions;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new ThrottlesExceptions(10, 10 * 60))->by('key')];
}

기본적으로 이 미들웨어는 모든 예외를 스로틀링합니다. 작업에 미들웨어를 연결할 때 when 메서드를 호출하여 이 동작을 수정할 수 있습니다. 그런 다음 when 메서드에 제공된 클로저가 true를 반환하는 경우에만 예외가 스로틀링됩니다.

use Illuminate\Http\Client\HttpClientException;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new ThrottlesExceptions(10, 10 * 60))->when(
        fn (Throwable $throwable) => $throwable instanceof HttpClientException
    )];
}

스로틀링된 예외를 애플리케이션의 예외 처리기에 보고하려면 작업에 미들웨어를 연결할 때 report 메서드를 호출하면 됩니다. 선택적으로 report 메서드에 클로저를 제공할 수 있으며, 지정된 클로저가 true를 반환하는 경우에만 예외가 보고됩니다.

use Illuminate\Http\Client\HttpClientException;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 *
 * @return array<int, object>
 */
public function middleware(): array
{
    return [(new ThrottlesExceptions(10, 10 * 60))->report(
        fn (Throwable $throwable) => $throwable instanceof HttpClientException
    )];
}

작업 건너뛰기

Skip 미들웨어를 사용하면 작업의 논리를 수정할 필요 없이 작업을 건너뛰거나 삭제하도록 지정할 수 있습니다. Skip::when 메서드는 주어진 조건이 true로 평가되면 작업을 삭제하고, Skip::unless 메서드는 조건이 false로 평가되면 작업을 삭제합니다.

use Illuminate\Queue\Middleware\Skip;
 
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*/
public function middleware(): array
{
    return [
        Skip::when($someCondition),
    ];
}

더 복잡한 조건부 평가를 위해 when 및 unless 메서드에 Closure를 전달할 수도 있습니다.

use Illuminate\Queue\Middleware\Skip;
 
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*/
public function middleware(): array
{
    return [
        Skip::when(function (): bool {
            return $this->shouldSkip();
        }),
    ];
}

작업 디스패치

작업 클래스를 작성했으면 작업 자체에서 dispatch 메서드를 사용하여 디스패치할 수 있습니다. dispatch 메서드에 전달된 인수는 작업의 생성자에 전달됩니다.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
 
class PodcastController extends Controller
{
    /**
     * 새 팟캐스트를 저장합니다.
     */
    public function store(Request $request): RedirectResponse
    {
        $podcast = Podcast::create(/* ... */);
 
        // ...
 
        ProcessPodcast::dispatch($podcast);
 
        return redirect('/podcasts');
    }
}

작업을 조건부로 디스패치하려면 dispatchIf 및 dispatchUnless 메서드를 사용할 수 있습니다.

ProcessPodcast::dispatchIf($accountActive, $podcast);
 
ProcessPodcast::dispatchUnless($accountSuspended, $podcast);

새 Laravel 애플리케이션에서 sync 드라이버는 기본 대기열 드라이버입니다. 이 드라이버는 현재 요청의 포그라운드에서 작업을 동기적으로 실행하며, 이는 로컬 개발 중에 종종 편리합니다. 백그라운드 처리를 위해 실제로 작업을 대기열에 넣기 시작하려면 애플리케이션의 config/queue.php 구성 파일 내에서 다른 대기열 드라이버를 지정할 수 있습니다.

지연된 디스패치

대기열 작업자가 즉시 처리할 수 없도록 작업을 지정하려면 작업을 디스패치할 때 delay 메서드를 사용할 수 있습니다. 예를 들어, 작업을 디스패치한 후 10분 후에 작업을 처리할 수 있도록 지정해 보겠습니다.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
 
class PodcastController extends Controller
{
    /**
     * 새 팟캐스트를 저장합니다.
     */
    public function store(Request $request): RedirectResponse
    {
        $podcast = Podcast::create(/* ... */);
 
        // ...
 
        ProcessPodcast::dispatch($podcast)
                    ->delay(now()->addMinutes(10));
 
        return redirect('/podcasts');
    }
}

경우에 따라 작업에 기본 지연이 구성되어 있을 수 있습니다. 이 지연을 우회하고 작업을 즉시 처리하기 위해 디스패치해야 하는 경우 withoutDelay 메서드를 사용할 수 있습니다.

ProcessPodcast::dispatch($podcast)->withoutDelay();

브라우저로 응답을 보낸 후 디스패치

또는 웹 서버에서 FastCGI를 사용하는 경우 dispatchAfterResponse 메서드는 HTTP 응답이 사용자 브라우저로 전송된 후까지 작업 디스패치를 지연합니다. 이렇게 하면 대기열 작업이 여전히 실행 중이더라도 사용자가 애플리케이션을 사용하기 시작할 수 있습니다. 이것은 일반적으로 이메일 전송과 같이 약 1초 정도 걸리는 작업에만 사용해야 합니다. 현재 HTTP 요청 내에서 처리되기 때문에 이러한 방식으로 디스패치된 작업은 처리하기 위해 실행 중인 대기열 작업자가 필요하지 않습니다.

use App\Jobs\SendNotification;
 
SendNotification::dispatchAfterResponse();

또한 클로저를 dispatch하고 dispatch 헬퍼에 afterResponse 메서드를 체인하여 HTTP 응답이 브라우저로 전송된 후 클로저를 실행할 수도 있습니다.

use App\Mail\WelcomeMessage;
use Illuminate\Support\Facades\Mail;
 
dispatch(function () {
    Mail::to('[email protected]')->send(new WelcomeMessage);
})->afterResponse();

동기 디스패치

작업을 즉시 (동기적으로) 디스패치하려면 dispatchSync 메서드를 사용할 수 있습니다. 이 메서드를 사용하는 경우 작업은 대기열에 들어가지 않고 현재 프로세스 내에서 즉시 실행됩니다.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
 
class PodcastController extends Controller
{
    /**
     * 새 팟캐스트를 저장합니다.
     */
    public function store(Request $request): RedirectResponse
    {
        $podcast = Podcast::create(/* ... */);
 
        // 팟캐스트 생성...
 
        ProcessPodcast::dispatchSync($podcast);
 
        return redirect('/podcasts');
    }
}

작업 및 데이터베이스 트랜잭션

데이터베이스 트랜잭션 내에서 작업을 디스패치하는 것은 완벽하게 좋지만 작업이 실제로 성공적으로 실행될 수 있도록 특별히 주의해야 합니다. 트랜잭션 내에서 작업을 디스패치할 때, 부모 트랜잭션이 커밋되기 전에 작업이 작업자에 의해 처리될 수 있습니다. 이 경우 데이터베이스 트랜잭션 중에 모델 또는 데이터베이스 레코드에 대해 수행한 모든 업데이트가 데이터베이스에 아직 반영되지 않을 수 있습니다. 또한 트랜잭션 내에서 생성된 모델 또는 데이터베이스 레코드가 데이터베이스에 존재하지 않을 수 있습니다.

다행히 Laravel은 이 문제를 해결하는 몇 가지 방법을 제공합니다. 먼저 대기열 연결 구성 배열에서 after_commit 연결 옵션을 설정할 수 있습니다.

'redis' => [
    'driver' => 'redis',
    // ...
    'after_commit' => true,
],

after_commit 옵션이 true이면 데이터베이스 트랜잭션 내에서 작업을 디스패치할 수 있습니다. 그러나 Laravel은 실제로 작업을 디스패치하기 전에 열려 있는 부모 데이터베이스 트랜잭션이 커밋될 때까지 기다립니다. 물론 현재 열려 있는 데이터베이스 트랜잭션이 없으면 작업이 즉시 디스패치됩니다.

트랜잭션 중에 발생하는 예외로 인해 트랜잭션이 롤백되면 해당 트랜잭션 중에 디스패치된 작업이 삭제됩니다.

커밋 디스패치 동작을 인라인으로 지정

after_commit 대기열 연결 구성 옵션을 true로 설정하지 않은 경우, 특정 작업을 열려 있는 모든 데이터베이스 트랜잭션이 커밋된 후에 디스패치해야 함을 나타낼 수 있습니다. 이를 위해 디스패치 작업에 afterCommit 메서드를 연결할 수 있습니다.

use App\Jobs\ProcessPodcast;
 
ProcessPodcast::dispatch($podcast)->afterCommit();

마찬가지로 after_commit 구성 옵션이 true로 설정된 경우, 특정 작업을 열려 있는 데이터베이스 트랜잭션이 커밋되기를 기다리지 않고 즉시 디스패치해야 함을 나타낼 수 있습니다.

ProcessPodcast::dispatch($podcast)->beforeCommit();

작업 체이닝

작업 체이닝을 사용하면 기본 작업이 성공적으로 실행된 후 순차적으로 실행해야 하는 대기열 작업 목록을 지정할 수 있습니다. 시퀀스에서 하나의 작업이 실패하면 나머지 작업은 실행되지 않습니다. 대기열 작업 체인을 실행하려면 Bus 파사드에서 제공하는 chain 메서드를 사용할 수 있습니다. Laravel의 명령 버스는 대기열 작업 디스패치가 기반으로 구축된 하위 수준 구성 요소입니다.

use App\Jobs\OptimizePodcast;
use App\Jobs\ProcessPodcast;
use App\Jobs\ReleasePodcast;
use Illuminate\Support\Facades\Bus;
 
Bus::chain([
    new ProcessPodcast,
    new OptimizePodcast,
    new ReleasePodcast,
])->dispatch();

작업 클래스 인스턴스를 체이닝하는 것 외에도 클로저를 체이닝할 수도 있습니다.

Bus::chain([
    new ProcessPodcast,
    new OptimizePodcast,
    function () {
        Podcast::update(/* ... */);
    },
])->dispatch();

체인 연결 및 대기열

체인된 작업에 사용해야 하는 연결 및 대기열을 지정하려면 onConnection 및 onQueue 메서드를 사용할 수 있습니다. 이러한 메서드는 대기열 작업에 다른 연결/대기열이 명시적으로 할당되지 않은 경우 사용해야 하는 대기열 연결 및 대기열 이름을 지정합니다.

Bus::chain([
    new ProcessPodcast,
    new OptimizePodcast,
    new ReleasePodcast,
])->onConnection('redis')->onQueue('podcasts')->dispatch();

체인에 작업 추가

경우에 따라 해당 체인에 있는 다른 작업 내에서 기존 작업 체인에 작업을 추가하거나 추가해야 할 수 있습니다. prependToChain 및 appendToChain 메서드를 사용하여 이를 수행할 수 있습니다.

/**
 * 작업을 실행합니다.
 */
public function handle(): void
{
    // ...
 
    // 현재 체인 앞에 추가하고, 현재 작업 직후에 작업을 실행합니다...
    $this->prependToChain(new TranscribePodcast);
 
    // 현재 체인 뒤에 추가하고, 체인 끝에서 작업을 실행합니다...
    $this->appendToChain(new TranscribePodcast);
}

체인 실패

작업을 체인으로 연결할 때 체인 내 작업이 실패할 경우 호출해야 하는 클로저를 지정하기 위해 catch 메서드를 사용할 수 있습니다. 주어진 콜백은 작업 실패를 유발한 Throwable 인스턴스를 받습니다.

use Illuminate\Support\Facades\Bus;
use Throwable;
 
Bus::chain([
    new ProcessPodcast,
    new OptimizePodcast,
    new ReleasePodcast,
])->catch(function (Throwable $e) {
    // 체인 내 작업이 실패했습니다...
})->dispatch();

큐 및 연결 사용자 정의

특정 큐로 디스패치

작업을 다른 큐로 푸시하면 대기열에 있는 작업을 "분류"하고 다양한 큐에 할당하는 작업자 수를 우선순위를 지정할 수도 있습니다. 큐 구성 파일에 정의된 대로 작업을 다른 큐 "연결"로 푸시하는 것이 아니라 단일 연결 내의 특정 큐로만 푸시한다는 점에 유의하십시오. 큐를 지정하려면 작업을 디스패치할 때 onQueue 메서드를 사용합니다.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
 
class PodcastController extends Controller
{
    /**
     * 새 팟캐스트를 저장합니다.
     */
    public function store(Request $request): RedirectResponse
    {
        $podcast = Podcast::create(/* ... */);
 
        // 팟캐스트 생성...
 
        ProcessPodcast::dispatch($podcast)->onQueue('processing');
 
        return redirect('/podcasts');
    }
}

또는 작업의 생성자 내에서 onQueue 메서드를 호출하여 작업의 큐를 지정할 수 있습니다.

<?php
 
namespace App\Jobs;
 
 use Illuminate\Contracts\Queue\ShouldQueue;
 use Illuminate\Foundation\Queue\Queueable;
 
class ProcessPodcast implements ShouldQueue
{
    use Queueable;
 
    /**
     * 새 작업 인스턴스를 생성합니다.
     */
    public function __construct()
    {
        $this->onQueue('processing');
    }
}

특정 연결로 디스패치

애플리케이션이 여러 큐 연결과 상호 작용하는 경우 onConnection 메서드를 사용하여 작업을 푸시할 연결을 지정할 수 있습니다.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
 
class PodcastController extends Controller
{
    /**
     * 새 팟캐스트를 저장합니다.
     */
    public function store(Request $request): RedirectResponse
    {
        $podcast = Podcast::create(/* ... */);
 
        // 팟캐스트 생성...
 
        ProcessPodcast::dispatch($podcast)->onConnection('sqs');
 
        return redirect('/podcasts');
    }
}

onConnection 및 onQueue 메서드를 함께 연결하여 작업의 연결과 큐를 지정할 수 있습니다.

ProcessPodcast::dispatch($podcast)
              ->onConnection('sqs')
              ->onQueue('processing');

또는 작업의 생성자 내에서 onConnection 메서드를 호출하여 작업의 연결을 지정할 수 있습니다.

<?php
 
namespace App\Jobs;
 
 use Illuminate\Contracts\Queue\ShouldQueue;
 use Illuminate\Foundation\Queue\Queueable;
 
class ProcessPodcast implements ShouldQueue
{
    use Queueable;
 
    /**
     * 새 작업 인스턴스를 생성합니다.
     */
    public function __construct()
    {
        $this->onConnection('sqs');
    }
}

최대 작업 시도 횟수 / 제한 시간 값 지정

최대 시도 횟수

대기열에 있는 작업 중 하나에서 오류가 발생하는 경우 무한정 다시 시도하지 않으려는 것이 좋습니다. 따라서 Laravel은 작업 시도 횟수 또는 기간을 지정하는 다양한 방법을 제공합니다.

작업을 시도할 수 있는 최대 횟수를 지정하는 한 가지 방법은 Artisan 명령줄에서 --tries 스위치를 사용하는 것입니다. 처리 중인 작업에서 시도 횟수를 지정하지 않는 한 이는 작업자가 처리하는 모든 작업에 적용됩니다.

php artisan queue:work --tries=3

php artisan queue:work --tries=3 해당 명령어는 Laravel Artisan 콘솔을 사용하여 큐 워커를 시작하고, 실패한 작업을 최대 3번까지 재시도하도록 설정합니다. 큐 워커는 큐에 있는 작업을 처리하는 백그라운드 프로세스입니다. --tries=3 옵션은 작업이 실패할 경우, 최대 3번까지 자동으로 재시도하도록 지정합니다. Laravel Queue에 대한 추가 정보는 Laravel 공식 문서를 참조하십시오. 작업이 최대 시도 횟수를 초과하면 "실패한" 작업으로 간주됩니다. 실패한 작업을 처리하는 방법에 대한 자세한 내용은 실패한 작업 문서를 참조하세요. queue:work 명령어에 --tries=0이 제공되면 작업은 무기한 재시도됩니다.

작업 클래스 자체에서 작업이 시도될 수 있는 최대 횟수를 정의하여 더 세분화된 접근 방식을 취할 수 있습니다. 작업에 최대 시도 횟수가 지정되면 명령줄에 제공된 --tries 값보다 우선합니다.

<?php
 
namespace App\Jobs;
 
class ProcessPodcast implements ShouldQueue
{
    /**
     * 작업이 시도될 수 있는 횟수입니다.
     *
     * @var int
     */
    public $tries = 5;
}

특정 작업의 최대 시도 횟수를 동적으로 제어해야 하는 경우 작업에서 tries 메서드를 정의할 수 있습니다.

/**
 * 작업이 시도될 수 있는 횟수를 결정합니다.
 */
public function tries(): int
{
    return 5;
}

시간 기반 시도

작업이 실패하기 전에 시도할 수 있는 횟수를 정의하는 대신 작업 시도를 중지해야 하는 시간을 정의할 수 있습니다. 이렇게 하면 주어진 시간 프레임 내에서 작업을 여러 번 시도할 수 있습니다. 작업 시도를 중지해야 하는 시간을 정의하려면 작업 클래스에 retryUntil 메서드를 추가하세요. 이 메서드는 DateTime 인스턴스를 반환해야 합니다.

use DateTime;
 
/**
 * 작업이 타임아웃되어야 하는 시간을 결정합니다.
 */
public function retryUntil(): DateTime
{
    return now()->addMinutes(10);
}

최대 예외

경우에 따라 작업이 여러 번 시도될 수 있지만 (release 메서드에 의해 직접 해제되는 것과 달리) 처리되지 않은 예외가 지정된 횟수만큼 발생하여 재시도가 트리거되는 경우 실패해야 할 수 있습니다. 이를 수행하려면 작업 클래스에 maxExceptions 속성을 정의하면 됩니다.

<?php
 
namespace App\Jobs;
 
use Illuminate\Support\Facades\Redis;
 
class ProcessPodcast implements ShouldQueue
{
    /**
     * 작업이 시도될 수 있는 횟수입니다.
     *
     * @var int
     */
    public $tries = 25;
 
    /**
     * 실패하기 전에 허용되는 최대 처리되지 않은 예외 수입니다.
     *
     * @var int
     */
    public $maxExceptions = 3;
 
    /**
     * 작업 실행.
     */
    public function handle(): void
    {
        Redis::throttle('key')->allow(10)->every(60)->then(function () {
            // Lock obtained, process the podcast...
            // 락을 획득하여 팟캐스트를 처리합니다...
        }, function () {
            // Unable to obtain lock...
            // 락을 획득할 수 없습니다...
            return $this->release(10);
        });
    }
}

이 예제에서 애플리케이션이 Redis 락을 획득할 수 없는 경우 작업은 10초 동안 해제되고 최대 25번까지 계속 재시도됩니다. 그러나 작업에서 처리되지 않은 예외가 3개 발생하면 작업은 실패합니다.

타임아웃

종종 큐에 대기된 작업이 대략 얼마나 걸릴지 알고 있습니다. 이러한 이유로 Laravel을 사용하면 "타임아웃" 값을 지정할 수 있습니다. 기본적으로 타임아웃 값은 60초입니다. 작업이 타임아웃 값에 지정된 초 수보다 오래 처리되는 경우 작업을 처리하는 작업자는 오류와 함께 종료됩니다. 일반적으로 작업자는 서버에 구성된 프로세스 관리자에 의해 자동으로 다시 시작됩니다.

작업이 실행될 수 있는 최대 초 수는 Artisan 명령줄에서 --timeout 스위치를 사용하여 지정할 수 있습니다.

php artisan queue:work --timeout=30

작업이 계속해서 시간 초과되어 최대 시도 횟수를 초과하면 실패로 표시됩니다.

작업 클래스 자체에서 작업이 실행되도록 허용해야 하는 최대 시간(초)을 정의할 수도 있습니다. 작업에 시간 초과가 지정된 경우 명령줄에 지정된 시간 초과보다 우선합니다.

<?php
 
namespace App\Jobs;
 
class ProcessPodcast implements ShouldQueue
{
    /**
     * 작업이 시간 초과되기 전에 실행될 수 있는 시간(초)입니다.
     *
     * @var int
     */
    public $timeout = 120;
}

소켓이나 나가는 HTTP 연결과 같은 IO 차단 프로세스는 지정된 시간 초과를 따르지 않을 수 있습니다. 따라서 이러한 기능을 사용하는 경우 항상 해당 API를 사용하여 시간 초과를 지정해야 합니다. 예를 들어 Guzzle을 사용하는 경우 항상 연결 및 요청 시간 초과 값을 지정해야 합니다.

시간 초과 시 실패 처리

시간 초과 시 작업을 실패로 표시하도록 지정하려면 작업 클래스에서 $failOnTimeout 속성을 정의하면 됩니다.

/**
 * 시간 초과 시 작업을 실패로 표시해야 하는지 여부를 나타냅니다.
 *
 * @var bool
 */
public $failOnTimeout = true;

오류 처리

작업이 처리되는 동안 예외가 발생하면 작업은 자동으로 큐로 다시 릴리스되어 다시 시도할 수 있습니다. 작업은 애플리케이션에서 허용하는 최대 횟수만큼 시도될 때까지 계속해서 릴리스됩니다. 최대 시도 횟수는 queue:work Artisan 명령에서 사용되는 --tries 스위치에 의해 정의됩니다. 또는 최대 시도 횟수는 작업 클래스 자체에서 정의할 수도 있습니다. 큐 워커 실행에 대한 자세한 내용은 아래에서 확인할 수 있습니다.

수동으로 작업 릴리스

경우에 따라 작업을 수동으로 큐로 다시 릴리스하여 나중에 다시 시도할 수 있도록 하고 싶을 수 있습니다. release 메서드를 호출하여 이를 수행할 수 있습니다.

/**
 * 작업 실행.
 */
public function handle(): void
{
    // ...
 
    $this->release();
}

기본적으로 release 메서드는 즉시 처리를 위해 작업을 큐로 다시 릴리스합니다. 그러나 정수 또는 날짜 인스턴스를 release 메서드에 전달하여 지정된 시간(초)이 경과할 때까지 작업을 처리할 수 없도록 큐에 지시할 수 있습니다.

$this->release(10);
 
$this->release(now()->addSeconds(10));

수동으로 작업 실패 처리

경우에 따라 작업을 수동으로 "실패"로 표시해야 할 수 있습니다. 이렇게 하려면 fail 메서드를 호출하면 됩니다.

/**
 * 작업 실행.
 */
public function handle(): void
{
    // ...
 
    $this->fail();
}

잡은 예외 때문에 작업을 실패로 표시하려면 예외를 fail 메서드에 전달할 수 있습니다. 또는 편의를 위해 문자열 오류 메시지를 전달하면 해당 문자열 오류 메시지가 예외로 변환됩니다.

$this->fail($exception);
 
$this->fail('문제가 발생했습니다.');

작업 일괄 처리

Laravel의 작업 일괄 처리 기능을 사용하면 작업 일괄 처리를 쉽게 실행한 다음 작업 일괄 처리 실행이 완료되면 특정 작업을 수행할 수 있습니다. 시작하기 전에 완료율과 같은 작업 일괄 처리에 대한 메타 정보를 포함할 테이블을 빌드하기 위한 데이터베이스 마이그레이션을 생성해야 합니다. 이 마이그레이션은 make:queue-batches-table Artisan 명령을 사용하여 생성할 수 있습니다.

php artisan make:queue-batches-table
 
php artisan migrate

일괄 처리 가능한 작업 정의

일괄 처리 가능한 작업을 정의하려면, 일반적인 대기열에 넣을 수 있는 작업을 생성해야 합니다. 하지만 작업 클래스에 Illuminate\Bus\Batchable 트레이트를 추가해야 합니다. 이 트레이트는 작업이 실행 중인 현재 일괄 처리를 검색하는 데 사용할 수 있는 batch 메서드에 대한 액세스를 제공합니다.

<?php
 
namespace App\Jobs;
 
use Illuminate\Bus\Batchable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
 
class ImportCsv implements ShouldQueue
{
    use Batchable, Queueable;
 
    /**
     * 작업 실행.
     */
    public function handle(): void
    {
        if ($this->batch()->cancelled()) {
            // 일괄 처리가 취소되었는지 확인...
 
            return;
        }
 
        // CSV 파일의 일부를 가져오기...
    }
}

일괄 처리 발송

작업 일괄 처리를 발송하려면 Bus 파사드의 batch 메서드를 사용해야 합니다. 물론 일괄 처리는 완료 콜백과 결합할 때 주로 유용합니다. 따라서 일괄 처리에 대한 완료 콜백을 정의하기 위해 then, catch, finally 메서드를 사용할 수 있습니다. 이러한 각 콜백은 호출될 때 Illuminate\Bus\Batch 인스턴스를 받습니다. 이 예에서는 CSV 파일에서 주어진 수의 행을 각각 처리하는 작업 일괄 처리를 대기열에 넣는다고 가정합니다.

use App\Jobs\ImportCsv;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
use Throwable;
 
$batch = Bus::batch([
    new ImportCsv(1, 100),
    new ImportCsv(101, 200),
    new ImportCsv(201, 300),
    new ImportCsv(301, 400),
    new ImportCsv(401, 500),
])->before(function (Batch $batch) {
    // 일괄 처리가 생성되었지만 작업이 추가되지 않았습니다...
})->progress(function (Batch $batch) {
    // 단일 작업이 성공적으로 완료되었습니다...
})->then(function (Batch $batch) {
    // 모든 작업이 성공적으로 완료되었습니다...
})->catch(function (Batch $batch, Throwable $e) {
    // 첫 번째 일괄 처리 작업 실패 감지...
})->finally(function (Batch $batch) {
    // 일괄 처리가 실행을 완료했습니다...
})->dispatch();
 
return $batch->id;

$batch->id 속성을 통해 액세스할 수 있는 일괄 처리의 ID는 발송 후 일괄 처리에 대한 정보를 Laravel 명령 버스에 쿼리하는 데 사용할 수 있습니다.

일괄 처리 이름 지정

Laravel Horizon 및 Laravel Telescope와 같은 일부 도구는 일괄 처리에 이름을 지정하면 일괄 처리에 대한 사용자 친화적인 디버그 정보를 제공할 수 있습니다. 일괄 처리에 임의의 이름을 할당하려면 일괄 처리를 정의하는 동안 name 메서드를 호출할 수 있습니다.

$batch = Bus::batch([
    // ...
])->then(function (Batch $batch) {
    // 모든 작업이 성공적으로 완료되었습니다...
})->name('Import CSV')->dispatch();

일괄 처리 연결 및 대기열

일괄 처리된 작업에 사용해야 하는 연결 및 대기열을 지정하려면 onConnection 및 onQueue 메서드를 사용할 수 있습니다. 모든 일괄 처리된 작업은 동일한 연결 및 대기열 내에서 실행되어야 합니다.

$batch = Bus::batch([
    // ...
])->then(function (Batch $batch) {
    // 모든 작업이 성공적으로 완료되었습니다...
})->onConnection('redis')->onQueue('imports')->dispatch();

체인과 일괄 처리

체인된 작업을 배열 안에 배치하여 일괄 처리 내에서 체인된 작업 세트를 정의할 수 있습니다. 예를 들어, 두 개의 작업 체인을 병렬로 실행하고 두 작업 체인이 모두 처리를 완료하면 콜백을 실행할 수 있습니다.

use App\Jobs\ReleasePodcast;
use App\Jobs\SendPodcastReleaseNotification;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
 
Bus::batch([
    [
        new ReleasePodcast(1),
        new SendPodcastReleaseNotification(1),
    ],
    [
        new ReleasePodcast(2),
        new SendPodcastReleaseNotification(2),
    ],
])->then(function (Batch $batch) {
    // ...
})->dispatch();

반대로, 체인 내에서 일괄 처리를 정의하여 체인 내에서 작업 일괄 처리를 실행할 수 있습니다. 예를 들어, 먼저 여러 팟캐스트를 릴리스하는 작업 일괄 처리를 실행한 다음 릴리스 알림을 보내는 작업 일괄 처리를 실행할 수 있습니다.

use App\Jobs\FlushPodcastCache;
use App\Jobs\ReleasePodcast;
use App\Jobs\SendPodcastReleaseNotification;
use Illuminate\Support\Facades\Bus;
 
Bus::chain([
    new FlushPodcastCache,
    Bus::batch([
        new ReleasePodcast(1),
        new ReleasePodcast(2),
    ]),
    Bus::batch([
        new SendPodcastReleaseNotification(1),
        new SendPodcastReleaseNotification(2),
    ]),
])->dispatch();

일괄 처리에 작업 추가

때로는 일괄 처리된 작업 내에서 일괄 처리에 추가 작업을 추가하는 것이 유용할 수 있습니다. 이 패턴은 웹 요청 중에 발송하는 데 너무 오래 걸릴 수 있는 수천 개의 작업을 일괄 처리해야 하는 경우에 유용할 수 있습니다. 따라서 대신 더 많은 작업으로 일괄 처리를 채우는 초기 "로더" 작업 일괄 처리를 발송할 수 있습니다.

$batch = Bus::batch([
    new LoadImportBatch,
    new LoadImportBatch,
    new LoadImportBatch,
])->then(function (Batch $batch) {
    // 모든 작업이 성공적으로 완료되었습니다...
})->name('Import Contacts')->dispatch();

이 예에서는 LoadImportBatch 작업을 사용하여 일괄 처리에 추가 작업을 채웁니다. 이를 위해 작업의 batch 메서드를 통해 액세스할 수 있는 일괄 처리 인스턴스에서 add 메서드를 사용할 수 있습니다.

use App\Jobs\ImportContacts;
use Illuminate\Support\Collection;
 
/**
 * 작업 실행.
 */
public function handle(): void
{
    if ($this->batch()->cancelled()) {
        return;
    }
 
    $this->batch()->add(Collection::times(1000, function () {
        return new ImportContacts;
    }));
}

일괄 처리 검사

일괄 처리 완료 콜백에 제공되는 Illuminate\Bus\Batch 인스턴스에는 지정된 작업 일괄 처리와 상호 작용하고 검사하는 데 도움이 되는 다양한 속성 및 메서드가 있습니다.

// 일괄 처리의 UUID...
$batch->id;
 
// 일괄 처리의 이름(해당하는 경우)...
$batch->name;
 
// 일괄 처리에 할당된 작업 수...
$batch->totalJobs;
 
// 대기열에서 처리되지 않은 작업 수...
$batch->pendingJobs;
 
// 실패한 작업 수...
$batch->failedJobs;
 
// 지금까지 처리된 작업 수...
$batch->processedJobs();
 
// 일괄 처리의 완료율(0-100)...
$batch->progress();
 
// 일괄 처리 실행 완료 여부 표시...
$batch->finished();
 
// 일괄 처리 실행 취소...
$batch->cancel();
 
// 일괄 처리 취소 여부 표시...
$batch->cancelled();

경로에서 일괄 처리 반환

모든 Illuminate\Bus\Batch 인스턴스는 JSON 직렬화 가능하므로 애플리케이션의 경로 중 하나에서 직접 반환하여 완료 진행률을 포함하여 일괄 처리에 대한 정보가 포함된 JSON 페이로드를 검색할 수 있습니다. 따라서 애플리케이션 UI에서 일괄 처리 완료 진행률에 대한 정보를 표시하는 것이 편리합니다.

ID별로 일괄 처리를 검색하려면 Bus 파사드의 findBatch 메서드를 사용할 수 있습니다.

use Illuminate\Support\Facades\Bus;
use Illuminate\Support\Facades\Route;
 
Route::get('/batch/{batchId}', function (string $batchId) {
    return Bus::findBatch($batchId);
});

일괄 처리 취소

때로는 주어진 일괄 처리의 실행을 취소해야 할 수 있습니다. 이는 Illuminate\Bus\Batch 인스턴스에서 cancel 메서드를 호출하여 수행할 수 있습니다.

/**
 * 작업 실행.
 */
public function handle(): void
{
    if ($this->user->exceedsImportLimit()) {
        return $this->batch()->cancel();
    }
 
    if ($this->batch()->cancelled()) {
        return;
    }
}

이전 예에서 보셨듯이 일괄 처리된 작업은 일반적으로 실행을 계속하기 전에 해당 일괄 처리가 취소되었는지 여부를 확인해야 합니다. 그러나 편의를 위해 대신 작업에 SkipIfBatchCancelled 미들웨어를 할당할 수 있습니다. 이름에서 알 수 있듯이 이 미들웨어는 해당 일괄 처리가 취소된 경우 Laravel이 작업을 처리하지 않도록 지시합니다.

use Illuminate\Queue\Middleware\SkipIfBatchCancelled;
 
/**
 * 작업이 통과해야 하는 미들웨어를 가져옵니다.
 */
public function middleware(): array
{
    return [new SkipIfBatchCancelled];
}

일괄 처리 실패

일괄 처리된 작업이 실패하면 catch 콜백(할당된 경우)이 호출됩니다. 이 콜백은 일괄 처리 내에서 실패한 첫 번째 작업에 대해서만 호출됩니다.

실패 허용

일괄 처리 내에서 작업이 실패하면 Laravel은 자동으로 일괄 처리를 "취소됨"으로 표시합니다. 원하는 경우 작업 실패가 자동으로 일괄 처리를 취소됨으로 표시하지 않도록 이 동작을 비활성화할 수 있습니다. 이는 일괄 처리를 발송하는 동안 allowFailures 메서드를 호출하여 수행할 수 있습니다.

$batch = Bus::batch([
    // ...
])->then(function (Batch $batch) {
    // 모든 작업이 성공적으로 완료되었습니다...
})->allowFailures()->dispatch();

실패한 일괄 처리 작업 재시도

편의를 위해 Laravel은 주어진 일괄 처리에 대해 실패한 모든 작업을 쉽게 재시도할 수 있는 queue:retry-batch Artisan 명령을 제공합니다. queue:retry-batch 명령은 재시도해야 하는 실패한 작업의 일괄 처리 UUID를 허용합니다.

php artisan queue:retry-batch 32dbc76c-4f82-4749-b610-a639fe0099b5

배치 정리

정리하지 않으면 job_batches 테이블에 레코드가 매우 빠르게 누적될 수 있습니다. 이를 완화하려면 queue:prune-batches Artisan 명령을 매일 실행하도록 예약해야 합니다.

use Illuminate\Support\Facades\Schedule;
 
Schedule::command('queue:prune-batches')->daily();

기본적으로 24시간 이상 지난 완료된 모든 배치는 정리됩니다. 명령을 호출할 때 hours 옵션을 사용하여 배치 데이터를 보관할 기간을 결정할 수 있습니다. 예를 들어, 다음 명령은 48시간 전에 완료된 모든 배치를 삭제합니다.

use Illuminate\Support\Facades\Schedule;
 
Schedule::command('queue:prune-batches --hours=48')->daily();

경우에 따라 jobs_batches 테이블에 작업이 실패하고 해당 작업이 성공적으로 다시 시도되지 않은 배치와 같이 성공적으로 완료되지 않은 배치에 대한 배치 레코드가 누적될 수 있습니다. queue:prune-batches 명령에 unfinished 옵션을 사용하여 완료되지 않은 이러한 배치 레코드를 정리하도록 지시할 수 있습니다.

use Illuminate\Support\Facades\Schedule;
 
Schedule::command('queue:prune-batches --hours=48 --unfinished=72')->daily();

마찬가지로, jobs_batches 테이블에 취소된 배치에 대한 배치 레코드가 누적될 수도 있습니다. queue:prune-batches 명령에 cancelled 옵션을 사용하여 취소된 이러한 배치 레코드를 정리하도록 지시할 수 있습니다.

use Illuminate\Support\Facades\Schedule;
 
Schedule::command('queue:prune-batches --hours=48 --cancelled=72')->daily();

DynamoDB에 배치 저장

Laravel은 관계형 데이터베이스 대신 DynamoDB에 배치 메타 정보를 저장하는 기능도 제공합니다. 하지만 모든 배치 레코드를 저장하려면 DynamoDB 테이블을 수동으로 생성해야 합니다.

일반적으로 이 테이블의 이름은 job_batches여야 하지만, 애플리케이션의 queue 구성 파일 내의 queue.batching.table 구성 값에 따라 테이블 이름을 지정해야 합니다.

DynamoDB 배치 테이블 구성

job_batches 테이블에는 application이라는 문자열 기본 파티션 키와 id라는 문자열 기본 정렬 키가 있어야 합니다. 키의 application 부분에는 애플리케이션의 app 구성 파일 내에서 name 구성 값으로 정의된 애플리케이션 이름이 포함됩니다. 애플리케이션 이름이 DynamoDB 테이블 키의 일부이므로 동일한 테이블을 사용하여 여러 Laravel 애플리케이션의 작업 배치를 저장할 수 있습니다.

또한, 자동 배치 정리를 활용하려면 테이블에 ttl 속성을 정의할 수 있습니다.

DynamoDB 구성

다음으로, Laravel 애플리케이션이 Amazon DynamoDB와 통신할 수 있도록 AWS SDK를 설치합니다.

composer require aws/aws-sdk-php

그런 다음 queue.batching.driver 설정 옵션의 값을 dynamodb로 설정하십시오. 또한 batching 설정 배열 내에 key, secret 및 region 설정 옵션을 정의해야 합니다. 이러한 옵션은 AWS 인증에 사용됩니다. dynamodb 드라이버를 사용하는 경우 queue.batching.database 설정 옵션은 불필요합니다.

'batching' => [
    'driver' => env('QUEUE_BATCHING_DRIVER', 'dynamodb'),
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'table' => 'job_batches',
],

DynamoDB에서 배치 정리하기

DynamoDB를 사용하여 작업 배치 정보를 저장하는 경우, 관계형 데이터베이스에 저장된 배치를 정리하는 데 사용되는 일반적인 정리 명령은 작동하지 않습니다. 대신 DynamoDB의 기본 TTL 기능을 활용하여 오래된 배치 레코드를 자동으로 제거할 수 있습니다.

DynamoDB 테이블을 ttl 속성으로 정의한 경우, Laravel에 배치 레코드를 정리하는 방법을 지시하는 구성 매개변수를 정의할 수 있습니다. queue.batching.ttl_attribute 구성 값은 TTL을 보유하는 속성의 이름을 정의하고, queue.batching.ttl 구성 값은 레코드가 마지막으로 업데이트된 시간을 기준으로 DynamoDB 테이블에서 배치 레코드를 제거할 수 있는 시간(초)을 정의합니다.

'batching' => [
    'driver' => env('QUEUE_FAILED_DRIVER', 'dynamodb'),
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'table' => 'job_batches',
    'ttl_attribute' => 'ttl',
    'ttl' => 60 * 60 * 24 * 7, // 7일...
],

클로저 큐에 넣기

작업 클래스를 큐에 디스패치하는 대신, 클로저를 디스패치할 수도 있습니다. 이는 현재 요청 주기 외부에서 실행해야 하는 빠르고 간단한 작업에 유용합니다. 클로저를 큐에 디스패치할 때, 클로저의 코드 내용은 전송 중에 수정할 수 없도록 암호화 서명됩니다.

$podcast = App\Podcast::find(1);
 
dispatch(function () use ($podcast) {
    $podcast->publish();
});

catch 메서드를 사용하면 큐에 넣은 클로저가 큐의 구성된 재시도 횟수를 모두 소진한 후 성공적으로 완료되지 못했을 경우 실행해야 하는 클로저를 제공할 수 있습니다.

use Throwable;
 
dispatch(function () use ($podcast) {
    $podcast->publish();
})->catch(function (Throwable $e) {
    // 이 작업이 실패했습니다...
});

큐 워커 실행하기

queue:work 명령어

Laravel에는 큐 워커를 시작하고 큐에 푸시된 새로운 작업을 처리하는 Artisan 명령어가 포함되어 있습니다. queue:work Artisan 명령어를 사용하여 워커를 실행할 수 있습니다. queue:work 명령어가 시작되면 수동으로 중지하거나 터미널을 닫을 때까지 계속 실행됩니다.

php artisan queue:work

queue:work 명령어를 호출할 때 -v 플래그를 포함하면 처리된 작업 ID가 명령어 출력에 포함됩니다.

php artisan queue:work -v

큐 워커는 수명이 긴 프로세스이며 부트된 애플리케이션 상태를 메모리에 저장합니다. 따라서 큐 워커가 시작된 후에는 코드 베이스의 변경 사항을 감지하지 못합니다. 따라서 배포 과정 중에는 반드시 큐 워커를 재시작해야 합니다. 또한 애플리케이션에서 생성하거나 수정하는 정적 상태는 작업 간에 자동으로 재설정되지 않습니다.

또는 queue:listen 명령을 실행할 수 있습니다. queue:listen 명령을 사용하는 경우 업데이트된 코드를 다시 로드하거나 애플리케이션 상태를 재설정할 때 워커를 수동으로 재시작할 필요가 없습니다. 그러나 이 명령은 queue:work 명령보다 효율성이 훨씬 떨어집니다.

php artisan queue:listen

다중 큐 워커 실행

큐에 여러 워커를 할당하고 작업을 동시에 처리하려면 여러 queue:work 프로세스를 시작해야 합니다. 이는 터미널의 여러 탭을 통해 로컬에서 수행하거나 프로세스 관리자의 구성 설정을 사용하여 프로덕션 환경에서 수행할 수 있습니다. Supervisor를 사용하는 경우 numprocs 구성 값을 사용할 수 있습니다.

연결 및 큐 지정

워커가 사용할 큐 연결을 지정할 수도 있습니다. work 명령에 전달된 연결 이름은 config/queue.php 구성 파일에 정의된 연결 중 하나와 일치해야 합니다.

php artisan queue:work redis

기본적으로 queue:work 명령은 지정된 연결에서 기본 큐에 대한 작업만 처리합니다. 그러나 지정된 연결에 대해 특정 큐만 처리하도록 큐 워커를 더욱 사용자 정의할 수 있습니다. 예를 들어 모든 이메일이 redis 큐 연결의 emails 큐에서 처리되는 경우 다음 명령을 실행하여 해당 큐만 처리하는 워커를 시작할 수 있습니다.

php artisan queue:work redis --queue=emails

지정된 수의 작업 처리하기

--once 옵션은 워커가 큐에서 단일 작업만 처리하도록 지시하는 데 사용할 수 있습니다.

php artisan queue:work --once

--max-jobs 옵션은 워커가 지정된 수의 작업을 처리한 후 종료하도록 지시하는 데 사용할 수 있습니다. 이 옵션은 Supervisor와 함께 사용하여 워커가 지정된 수의 작업을 처리한 후 자동으로 다시 시작되어 누적되었을 수 있는 메모리를 해제하도록 하는 데 유용할 수 있습니다.

php artisan queue:work --max-jobs=1000

대기열에 있는 모든 작업을 처리한 다음 종료하기

--stop-when-empty 옵션은 워커가 모든 작업을 처리한 후 정상적으로 종료하도록 지시하는 데 사용할 수 있습니다. 이 옵션은 큐가 비어있으면 컨테이너를 종료하려는 경우 Docker 컨테이너 내에서 Laravel 큐를 처리할 때 유용할 수 있습니다.

php artisan queue:work --stop-when-empty

지정된 시간(초) 동안 작업 처리하기

--max-time 옵션은 워커가 지정된 시간(초) 동안 작업을 처리한 후 종료하도록 지시하는 데 사용할 수 있습니다. 이 옵션은 Supervisor와 함께 사용하여 워커가 지정된 시간 동안 작업을 처리한 후 자동으로 다시 시작되어 누적되었을 수 있는 메모리를 해제하도록 하는 데 유용할 수 있습니다.

# 한 시간 동안 작업을 처리한 후 종료...
php artisan queue:work --max-time=3600

작업자 Sleep 지속 시간

큐에 작업이 있는 경우, 작업자는 작업 사이에 지연 없이 작업을 계속 처리합니다. 그러나 sleep 옵션은 사용 가능한 작업이 없을 경우 작업자가 몇 초 동안 "잠자는" 시간을 결정합니다. 물론, 잠자는 동안 작업자는 새로운 작업을 처리하지 않습니다.

php artisan queue:work --sleep=3

유지 관리 모드 및 큐

애플리케이션이 유지 관리 모드에 있는 동안에는 큐에 있는 작업이 처리되지 않습니다. 애플리케이션이 유지 관리 모드에서 벗어나면 작업이 정상적으로 처리됩니다.

유지 관리 모드가 활성화된 경우에도 큐 작업자가 작업을 강제로 처리하도록 하려면 --force 옵션을 사용할 수 있습니다.

php artisan queue:work --force

리소스 고려 사항

데몬 큐 작업자는 각 작업을 처리하기 전에 프레임워크를 "재부팅"하지 않습니다. 따라서 각 작업이 완료된 후에는 무거운 리소스를 해제해야 합니다. 예를 들어, GD 라이브러리를 사용하여 이미지 조작을 수행하는 경우 이미지 처리가 완료되면 imagedestroy를 사용하여 메모리를 해제해야 합니다.

큐 우선 순위

큐를 처리하는 방법을 우선 순위화해야 할 경우가 있습니다. 예를 들어, config/queue.php 구성 파일에서 redis 연결에 대한 기본 queue를 low로 설정할 수 있습니다. 그러나 때로는 다음과 같이 high 우선 순위 큐에 작업을 푸시하고 싶을 수도 있습니다.

dispatch((new Job)->onQueue('high'));

low 큐에 있는 작업을 계속하기 전에 high 큐 작업이 모두 처리되었는지 확인하는 작업자를 시작하려면 work 명령에 쉼표로 구분된 큐 이름 목록을 전달하십시오.

php artisan queue:work --queue=high,low

큐 워커 및 배포

큐 워커는 장기 실행 프로세스이므로 재시작하지 않으면 코드 변경 사항을 인식하지 못합니다. 따라서 큐 워커를 사용하는 애플리케이션을 배포하는 가장 간단한 방법은 배포 프로세스 중에 워커를 재시작하는 것입니다. queue:restart 명령을 실행하여 모든 워커를 정상적으로 재시작할 수 있습니다.

php artisan queue:restart

이 명령은 현재 작업을 완료한 후 모든 큐 작업자가 정상적으로 종료되도록 지시하여 기존 작업이 손실되지 않도록 합니다. queue:restart 명령이 실행될 때 큐 작업자가 종료되므로, 큐 작업자를 자동으로 다시 시작하기 위해 Supervisor와 같은 프로세스 관리자를 실행해야 합니다.

작업 만료 및 시간 초과

작업 만료

config/queue.php 구성 파일에서 각 큐 연결은 retry_after 옵션을 정의합니다. 이 옵션은 처리 중인 작업을 재시도하기 전에 큐 연결이 대기해야 하는 시간(초)을 지정합니다. 예를 들어, retry_after 값이 90으로 설정된 경우 작업이 해제되거나 삭제되지 않고 90초 동안 처리 중이면 작업이 다시 큐로 반환됩니다. 일반적으로 retry_after 값은 작업이 처리를 완료하는 데 합리적으로 걸리는 최대 시간(초)으로 설정해야 합니다.

작업자 시간 초과

queue:work Artisan 명령어는 --timeout 옵션을 노출합니다. 기본적으로 --timeout 값은 60초입니다. 작업이 시간 초과 값으로 지정된 시간(초)보다 오래 처리되는 경우, 작업을 처리하는 작업자가 오류와 함께 종료됩니다. 일반적으로 작업자는 서버에 구성된 프로세스 관리자에 의해 자동으로 다시 시작됩니다.

php artisan queue:work --timeout=60

retry_after 설정 옵션과 --timeout CLI 옵션은 서로 다르지만, 작업이 손실되지 않고 작업이 한 번만 성공적으로 처리되도록 함께 작동합니다.

Supervisor 설정

프로덕션 환경에서는 queue:work 프로세스가 계속 실행되도록 유지하는 방법이 필요합니다. queue:work 프로세스는 워커 타임아웃 초과 또는 queue:restart 명령 실행과 같은 다양한 이유로 실행이 중지될 수 있습니다.

이러한 이유로 queue:work 프로세스가 종료될 때 이를 감지하고 자동으로 다시 시작할 수 있는 프로세스 모니터를 구성해야 합니다. 또한 프로세스 모니터를 사용하면 동시에 실행할 queue:work 프로세스 수를 지정할 수 있습니다. Supervisor는 Linux 환경에서 일반적으로 사용되는 프로세스 모니터이며 다음 문서에서 이를 구성하는 방법에 대해 설명합니다.

Supervisor 설치

Supervisor는 Linux 운영 체제용 프로세스 모니터이며, queue:work 프로세스가 실패하면 자동으로 다시 시작합니다. Ubuntu에 Supervisor를 설치하려면 다음 명령을 사용할 수 있습니다.

sudo apt-get install supervisor

Supervisor 구성하기

Supervisor 구성 파일은 일반적으로 /etc/supervisor/conf.d 디렉토리에 저장됩니다. 이 디렉토리 내에서 Supervisor가 프로세스를 모니터링하는 방법을 지시하는 구성 파일을 원하는 만큼 만들 수 있습니다. 예를 들어, queue:work 프로세스를 시작하고 모니터링하는 laravel-worker.conf 파일을 만들어 보겠습니다.

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/forge/app.com/artisan queue:work sqs --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=forge
numprocs=8
redirect_stderr=true
stdout_logfile=/home/forge/app.com/worker.log
stopwaitsecs=3600

이 예에서 numprocs 지시어는 Supervisor에게 8개의 queue:work 프로세스를 실행하고 모두 모니터링하도록 지시하며, 실패할 경우 자동으로 다시 시작합니다. 구성의 command 지시어를 원하는 큐 연결 및 워커 옵션을 반영하도록 변경해야 합니다.

Supervisor 시작하기

구성 파일이 생성되면 다음 명령을 사용하여 Supervisor 구성을 업데이트하고 프로세스를 시작할 수 있습니다.

sudo supervisorctl reread
 
sudo supervisorctl update
 
sudo supervisorctl start "laravel-worker:*"

Supervisor에 대한 자세한 내용은 Supervisor 문서를 참조하십시오.

실패한 작업 처리

때로는 대기열에 있는 작업이 실패할 수 있습니다. 걱정하지 마세요. 모든 일이 계획대로 진행되는 것은 아닙니다! Laravel은 작업을 시도해야 하는 최대 횟수를 지정하는 편리한 방법을 제공합니다. 비동기 작업이 이 시도 횟수를 초과하면 failed_jobs 데이터베이스 테이블에 삽입됩니다. 실패한 동기적으로 디스패치된 작업은 이 테이블에 저장되지 않으며 해당 예외는 애플리케이션에서 즉시 처리됩니다.

failed_jobs 테이블을 생성하는 마이그레이션은 일반적으로 새 Laravel 애플리케이션에 이미 존재합니다. 그러나 애플리케이션에 이 테이블에 대한 마이그레이션이 없는 경우 make:queue-failed-table 명령을 사용하여 마이그레이션을 생성할 수 있습니다.

php artisan make:queue-failed-table
 
php artisan migrate

큐 워커 프로세스를 실행할 때 queue:work 명령에서 --tries 스위치를 사용하여 작업 시도 횟수의 최대값을 지정할 수 있습니다. --tries 옵션에 값을 지정하지 않으면 작업은 한 번만 시도되거나 작업 클래스의 $tries 속성에 지정된 횟수만큼 시도됩니다.

php artisan queue:work redis --tries=3

--backoff 옵션을 사용하면 예외가 발생한 작업을 다시 시도하기 전에 Laravel이 기다려야 하는 시간(초)을 지정할 수 있습니다. 기본적으로 작업은 다시 시도할 수 있도록 즉시 큐에 다시 릴리스됩니다.

php artisan queue:work redis --tries=3 --backoff=3

예외가 발생한 작업을 재시도하기 전에 Laravel이 몇 초 동안 대기해야 하는지 작업별로 구성하려면 작업 클래스에 backoff 속성을 정의하면 됩니다.

/**
 * 작업을 재시도하기 전에 대기할 시간(초)입니다.
 *
 * @var int
 */
public $backoff = 3;

작업의 백오프 시간을 결정하기 위한 더 복잡한 로직이 필요한 경우, 작업 클래스에 backoff 메서드를 정의할 수 있습니다.

/**
* 작업을 재시도하기 전에 대기할 시간(초)을 계산합니다.
*/
public function backoff(): int
{
    return 3;
}

backoff 메서드에서 백오프 값의 배열을 반환하여 "지수" 백오프를 쉽게 구성할 수 있습니다. 이 예시에서 재시도 지연 시간은 첫 번째 재시도 시 1초, 두 번째 재시도 시 5초, 세 번째 재시도 시 10초이며, 시도 횟수가 더 남아 있는 경우 이후 모든 재시도에 대해 10초가 됩니다.

/**
* 작업을 재시도하기 전에 대기할 시간(초)을 계산합니다.
*
* @return array<int, int>
*/
public function backoff(): array
{
    return [1, 5, 10];
}

실패한 작업 후 정리

특정 작업이 실패하면 사용자에게 알림을 보내거나 작업에서 부분적으로 완료된 작업을 되돌려야 할 수 있습니다. 이를 수행하려면 작업 클래스에 failed 메서드를 정의하면 됩니다. 작업 실패를 유발한 Throwable 인스턴스가 failed 메서드로 전달됩니다.

<?php
 
namespace App\Jobs;
 
use App\Models\Podcast;
use App\Services\AudioProcessor;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Throwable;
 
class ProcessPodcast implements ShouldQueue
{
    use Queueable;
 
    /**
     * 새 작업 인스턴스를 생성합니다.
     */
    public function __construct(
        public Podcast $podcast,
    ) {}
 
    /**
     * 작업을 실행합니다.
     */
    public function handle(AudioProcessor $processor): void
    {
        // 업로드된 팟캐스트를 처리합니다...
    }
 
    /**
     * 작업 실패를 처리합니다.
     */
    public function failed(?Throwable $exception): void
    {
        // 실패에 대한 사용자 알림 등을 보냅니다...
    }
}

실패한 작업 재시도

failed_jobs 데이터베이스 테이블에 삽입된 모든 실패한 작업을 보려면 queue:failed Artisan 명령어를 사용할 수 있습니다.

php artisan queue:failed

queue:failed 명령어는 작업 ID, 연결, 큐, 실패 시간 및 작업에 대한 기타 정보를 나열합니다. 작업 ID는 실패한 작업을 재시도하는 데 사용할 수 있습니다. 예를 들어, ID가 ce7bb17c-cdd8-41f0-a8ec-7b4fef4e5ece인 실패한 작업을 재시도하려면 다음 명령을 실행합니다.

php artisan queue:retry ce7bb17c-cdd8-41f0-a8ec-7b4fef4e5ece

필요한 경우 여러 ID를 명령에 전달할 수 있습니다.

php artisan queue:retry ce7bb17c-cdd8-41f0-a8ec-7b4fef4e5ece 91401d2c-0784-4f43-824c-34f94a33c24d

특정 큐에 대해 실패한 모든 작업을 재시도할 수도 있습니다.

php artisan queue:retry --queue=name

실패한 모든 작업을 재시도하려면 queue:retry 명령을 실행하고 ID로 all을 전달합니다.

php artisan queue:retry all

실패한 작업을 삭제하려면 queue:forget 명령을 사용할 수 있습니다.

php artisan queue:forget 91401d2c-0784-4f43-824c-34f94a33c24d

failed_jobs 테이블에서 실패한 모든 작업을 삭제하려면 queue:flush 명령을 사용할 수 있습니다.

php artisan queue:flush

누락된 모델 무시하기

Eloquent 모델을 작업에 주입할 때, 해당 모델은 자동으로 직렬화되어 큐에 배치되고 작업이 처리될 때 데이터베이스에서 다시 검색됩니다. 그러나 작업이 워커에 의해 처리되기를 기다리는 동안 모델이 삭제되었다면, 작업은 ModelNotFoundException과 함께 실패할 수 있습니다.

편의를 위해 작업의 deleteWhenMissingModels 속성을 true로 설정하여 누락된 모델이 있는 작업을 자동으로 삭제하도록 선택할 수 있습니다. 이 속성이 true로 설정되면 Laravel은 예외를 발생시키지 않고 작업을 조용히 폐기합니다.

/**
 * 모델이 더 이상 존재하지 않는 경우 작업을 삭제합니다.
 *
 * @var bool
 */
public $deleteWhenMissingModels = true;

실패한 작업 정리하기

queue:prune-failed Artisan 명령을 호출하여 애플리케이션의 failed_jobs 테이블에서 레코드를 정리할 수 있습니다.

php artisan queue:prune-failed

기본적으로 24시간 이상 된 모든 실패한 작업 레코드가 정리됩니다. 명령에 --hours 옵션을 제공하면 지난 N시간 이내에 삽입된 실패한 작업 레코드만 유지됩니다. 예를 들어 다음 명령은 48시간 전에 삽입된 모든 실패한 작업 레코드를 삭제합니다.

php artisan queue:prune-failed --hours=48

DynamoDB에 실패한 작업 저장하기

Laravel은 관계형 데이터베이스 테이블 대신 DynamoDB에 실패한 작업 기록을 저장하는 기능도 제공합니다. 그러나 실패한 모든 작업 기록을 저장하려면 DynamoDB 테이블을 수동으로 생성해야 합니다. 일반적으로 이 테이블의 이름은 failed_jobs여야 하지만, 애플리케이션의 queue 구성 파일 내의 queue.failed.table 구성 값에 따라 테이블 이름을 지정해야 합니다.

failed_jobs 테이블에는 application이라는 문자열 기본 파티션 키와 uuid라는 문자열 기본 정렬 키가 있어야 합니다. 키의 application 부분에는 애플리케이션의 app 구성 파일 내의 name 구성 값으로 정의된 애플리케이션 이름이 포함됩니다. 애플리케이션 이름이 DynamoDB 테이블 키의 일부이므로 동일한 테이블을 사용하여 여러 Laravel 애플리케이션의 실패한 작업을 저장할 수 있습니다.

또한 Laravel 애플리케이션이 Amazon DynamoDB와 통신할 수 있도록 AWS SDK를 설치해야 합니다.

composer require aws/aws-sdk-php

다음으로, queue.failed.driver 구성 옵션의 값을 dynamodb로 설정합니다. 또한 실패한 작업 구성 배열 내에 key, secret 및 region 구성 옵션을 정의해야 합니다. 이러한 옵션은 AWS로 인증하는 데 사용됩니다. dynamodb 드라이버를 사용하는 경우 queue.failed.database 구성 옵션은 불필요합니다.

'failed' => [
    'driver' => env('QUEUE_FAILED_DRIVER', 'dynamodb'),
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'table' => 'failed_jobs',
],

실패한 작업 저장 비활성화

queue.failed.driver 구성 옵션의 값을 null로 설정하여 실패한 작업을 저장하지 않고 폐기하도록 Laravel에 지시할 수 있습니다. 일반적으로 이는 QUEUE_FAILED_DRIVER 환경 변수를 통해 수행할 수 있습니다.

QUEUE_FAILED_DRIVER=null

실패한 작업 이벤트

작업이 실패할 때 호출될 이벤트 리스너를 등록하려면 Queue 파사드의 failing 메서드를 사용할 수 있습니다. 예를 들어, Laravel에 포함된 AppServiceProvider의 boot 메서드에서 이 이벤트에 클로저를 연결할 수 있습니다.

<?php
 
namespace App\Providers;
 
use Illuminate\Support\Facades\Queue;
use Illuminate\Support\ServiceProvider;
use Illuminate\Queue\Events\JobFailed;
 
class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        // ...
    }
 
    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Queue::failing(function (JobFailed $event) {
            // $event->connectionName
            // $event->job
            // $event->exception
        });
    }
}

큐에서 작업 지우기

기본 연결의 기본 큐에서 모든 작업을 삭제하려면 queue:clear Artisan 명령을 사용하면 됩니다.

php artisan queue:clear

특정 연결 및 큐에서 작업을 삭제하기 위해 connection 인수와 queue 옵션을 제공할 수도 있습니다.

php artisan queue:clear redis --queue=emails

큐 모니터링

큐에 갑자기 많은 작업이 유입되면 과부하되어 작업 완료까지 오랜 시간이 걸릴 수 있습니다. 원하는 경우 Laravel은 큐 작업 수가 지정된 임계값을 초과할 때 알림을 보낼 수 있습니다.

시작하려면 queue:monitor 명령을 매분 실행하도록 예약해야 합니다. 이 명령은 모니터링하려는 큐의 이름과 원하는 작업 수 임계값을 허용합니다.

php artisan queue:monitor redis:default,redis:deployments --max=100

이 명령을 예약하는 것만으로는 큐의 과부하 상태를 알리는 알림을 트리거하기에 충분하지 않습니다. 명령이 임계값을 초과하는 작업 수를 가진 큐를 발견하면 Illuminate\Queue\Events\QueueBusy 이벤트가 발송됩니다. 애플리케이션의 AppServiceProvider 내에서 이 이벤트를 수신하여 본인 또는 개발 팀에게 알림을 보낼 수 있습니다.

use App\Notifications\QueueHasLongWaitTime;
use Illuminate\Queue\Events\QueueBusy;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Notification;
 
/**
 * 모든 애플리케이션 서비스 부트스트랩.
 */
public function boot(): void
{
    Event::listen(function (QueueBusy $event) {
        Notification::route('mail', '[email protected]')
                ->notify(new QueueHasLongWaitTime(
                    $event->connection,
                    $event->queue,
                    $event->size
                ));
    });
}

테스팅

작업을 디스패치하는 코드를 테스트할 때, 작업 코드는 디스패치하는 코드와 별도로 직접 테스트할 수 있으므로 Laravel이 실제 작업을 실행하지 않도록 지시하고 싶을 수 있습니다. 물론, 작업 자체를 테스트하려면 작업 인스턴스를 생성하고 테스트에서 handle 메서드를 직접 호출하면 됩니다.

Queue 파사드의 fake 메서드를 사용하여 대기열에 있는 작업이 실제로 대기열로 푸시되지 않도록 할 수 있습니다. Queue 파사드의 fake 메서드를 호출한 후, 애플리케이션이 작업을 대기열로 푸시하려고 시도했는지 어설션할 수 있습니다.

<?php
 
use App\Jobs\AnotherJob;
use App\Jobs\FinalJob;
use App\Jobs\ShipOrder;
use Illuminate\Support\Facades\Queue;
 
test('주문을 배송할 수 있습니다', function () {
    Queue::fake();
 
    // 주문 배송 수행...
 
    // 아무 작업도 푸시되지 않았는지 어설션...
    Queue::assertNothingPushed();
 
    // 특정 큐에 작업이 푸시되었는지 어설션...
    Queue::assertPushedOn('queue-name', ShipOrder::class);
 
    // 작업이 두 번 푸시되었는지 어설션...
    Queue::assertPushed(ShipOrder::class, 2);
 
    // 작업이 푸시되지 않았는지 어설션...
    Queue::assertNotPushed(AnotherJob::class);
 
    // 클로저가 큐에 푸시되었는지 어설션...
    Queue::assertClosurePushed();
 
    // 푸시된 총 작업 수를 어설션...
    Queue::assertCount(3);
});

<?php
 
namespace Tests\Feature;
 
use App\Jobs\AnotherJob;
use App\Jobs\FinalJob;
use App\Jobs\ShipOrder;
use Illuminate\Support\Facades\Queue;
use Tests\TestCase;
 
class ExampleTest extends TestCase
{
    public function test_orders_can_be_shipped(): void
    {
        Queue::fake();
 
        // 주문 배송 수행...
 
        // 아무 작업도 푸시되지 않았는지 확인...
        Queue::assertNothingPushed();
 
        // 주어진 큐에 작업이 푸시되었는지 확인...
        Queue::assertPushedOn('queue-name', ShipOrder::class);
 
        // 작업이 두 번 푸시되었는지 확인...
        Queue::assertPushed(ShipOrder::class, 2);
 
        // 작업이 푸시되지 않았는지 확인...
        Queue::assertNotPushed(AnotherJob::class);
 
        // 클로저가 큐에 푸시되었는지 확인...
        Queue::assertClosurePushed();
 
        // 푸시된 총 작업 수를 확인...
        Queue::assertCount(3);
    }
}

주어진 "진실 테스트"를 통과하는 작업이 푸시되었는지 확인하기 위해 assertPushed 또는 assertNotPushed 메서드에 클로저를 전달할 수 있습니다. 주어진 진실 테스트를 통과하는 작업이 하나 이상 푸시되면 assertion이 성공합니다.

Queue::assertPushed(function (ShipOrder $job) use ($order) {
    return $job->order->id === $order->id;
});

작업의 하위 집합 페이킹

다른 작업이 정상적으로 실행되도록 하면서 특정 작업만 페이크 처리해야 하는 경우, fake 메서드에 페이크 처리해야 하는 작업의 클래스 이름을 전달할 수 있습니다.

test('orders can be shipped', function () {
    Queue::fake([
        ShipOrder::class,
    ]);
 
    // 주문 배송 수행...
 
    // 작업이 두 번 푸시되었는지 확인...
    Queue::assertPushed(ShipOrder::class, 2);
});

public function test_orders_can_be_shipped(): void
{
    Queue::fake([
        ShipOrder::class,
    ]);
 
    // 주문 배송 수행...
 
    // 작업이 두 번 푸시되었는지 확인...
    Queue::assertPushed(ShipOrder::class, 2);
}

except 메소드를 사용하여 특정 작업 집합을 제외한 모든 작업을 페이크 처리할 수 있습니다:

Queue::fake()->except([
    ShipOrder::class,
]);

작업 체인 테스트하기

작업 체인을 테스트하려면 Bus 파사드의 페이크 기능을 활용해야 합니다. Bus 파사드의 assertChained 메소드를 사용하여 작업 체인이 디스패치되었는지 확인할 수 있습니다. assertChained 메소드는 연결된 작업 배열을 첫 번째 인수로 받습니다.

use App\Jobs\RecordShipment;
use App\Jobs\ShipOrder;
use App\Jobs\UpdateInventory;
use Illuminate\Support\Facades\Bus;
 
Bus::fake();
 
// ...
 
Bus::assertChained([
    ShipOrder::class,
    RecordShipment::class,
    UpdateInventory::class
]);

위 예에서 볼 수 있듯이 연결된 작업 배열은 작업 클래스 이름 배열일 수 있습니다. 그러나 실제 작업 인스턴스 배열을 제공할 수도 있습니다. 이렇게 하면 Laravel은 작업 인스턴스가 동일한 클래스이고 애플리케이션에서 디스패치한 연결된 작업과 동일한 속성 값을 갖는지 확인합니다.

Bus::assertChained([
    new ShipOrder,
    new RecordShipment,
    new UpdateInventory,
]);

assertDispatchedWithoutChain 메소드를 사용하여 작업이 작업 체인 없이 푸시되었는지 확인할 수 있습니다.

Bus::assertDispatchedWithoutChain(ShipOrder::class);

체인 수정 테스트하기

연결된 작업이 기존 체인에 작업을 추가 또는 추가하는 경우, 작업의 assertHasChain 메소드를 사용하여 작업에 예상되는 나머지 작업 체인이 있는지 확인할 수 있습니다.

$job = new ProcessPodcast;
 
$job->handle();
 
$job->assertHasChain([
    new TranscribePodcast,
    new OptimizePodcast,
    new ReleasePodcast,
]);

assertDoesntHaveChain 메서드는 작업의 남은 체인이 비어 있는지 확인하는 데 사용할 수 있습니다.

$job->assertDoesntHaveChain();

체인된 배치 테스트

만약 여러분의 작업 체인에 작업 배치가 포함되어 있다면, 체인된 배치가 여러분의 기대와 일치하는지 확인하기 위해 체인 어설션 내에 Bus::chainedBatch 정의를 삽입할 수 있습니다:

use App\Jobs\ShipOrder;
use App\Jobs\UpdateInventory;
use Illuminate\Bus\PendingBatch;
use Illuminate\Support\Facades\Bus;
 
Bus::assertChained([
    new ShipOrder,
    Bus::chainedBatch(function (PendingBatch $batch) {
        return $batch->jobs->count() === 3;
    }),
    new UpdateInventory,
]);