retryUntil メソッドをタスク クラスに追加します。

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

{tip}

retryUntil メソッドをキュー イベント リスナー retryUntil

メソッドを使用します。

{note} timeout 機能は、PHP 7.1 および pcntl

PHP で利用できます。拡張機能 Optimized.

同様に、タスク実行の最大秒数の値は、Artisan コマンド ラインの --timeout

php artisan queue:work --tries=3

<?phpnamespace App\Jobs;class ProcessPodcast implements ShouldQueue{    
     /**
     * 任务可以尝试的最大次数。
     *
     * @var int
     */    
    public $tries = 5;}

周波数制限

{note} この機能を使用するには、アプリケーションが Redis サーバーを使用できる必要があります。

アプリケーションが Redis を使用している場合は、時間や同時実行性を渡すことができます。キュータスクの制限。この機能は、キュー タスクがレート制限のある API を介して消費される場合に役立ちます。

たとえば、throttle メソッドを使用すると、特定のタイプのタスクの実行を 60 秒ごとに 10 回のみに制限できます。ロックが取得されない場合は、通常、後で再試行できるようにタスクをキューに戻す必要があります。

/**
 * 定义任务超时时间
 *
 * @return \DateTime
 */
 public function retryUntil(){
     return now()->addSeconds(5);
  }

{tip} 上記の例では、key には、頻度を制限するタスク タイプを識別する任意の文字列を指定できます。たとえば、タスク クラス名、またはウィジェットが動作する Eloquent モデルの ID に基づいてウィジェットのキーを使用します。

{note} 制限されたジョブをキューに解放しても、ジョブの合計数は 試行 によって増加します。

同時に実行できるタスクの最大数を指定することもできます。これは、キュー内のタスクが、一度に 1 つのタスクしか変更できないリソースを変更している場合に便利です。たとえば、funnel メソッドを使用すると、特定のタイプのタスクを一度に 1 つのプロセッサでのみ実行するように制限できます。

php artisan queue:work --timeout=30

{tip} 周波数制限を使用する場合、タスクの実行 成功した試行回数を判断するのは難しい場合があります。したがって、頻度制限と 時間制限を組み合わせると便利です。

queue:work Artisan コマンドの --tries オプション、またはタスク クラスで定義されます。実行キュー ハンドラーの詳細については、以下の を参照してください。

<?php
    namespace App\Jobs;class ProcessPodcast implements ShouldQueue{  
     /**
     * 任务可以执行的最大秒数 (超时时间)。
     *
     * @var int
     */   
    public $timeout = 120;}

実行キュープロセッサ

Laravelには、キューにプッシュされたタスクを実行するためのキュープロセッサが含まれています。 queue:work Artisan コマンドを使用してプロセッサを実行できます。 queue:work コマンドの実行が開始されると、手動で停止するかターミナルを閉じるまで実行が継続されることに注意してください。

Redis::throttle('key')->allow(10)->every(60)->then(function () {
    // 任务逻辑...
  },
 function () { 
   // 无法获得锁...    
  return $this->release(10);
});

{ヒント} queue:work プロセスをバックグラウンドで実行し続けるには、Supervisor などのプロセス マネージャーを使用して、キュー プロセッサは実行を停止しません。

キュー プロセッサは常駐プロセスであり、開始されたアプリケーションの状態をメモリに保存することに注意してください。したがって、起動後にコードが変更されたことに気づくことはありません。そのため、再デプロイメント中は、キュー ハンドラーを再起動することを忘れないでください。

接続とキューを指定する

どのキュー接続を指定することもできます。キュープロセッサが使用する必要があります。 work に渡される接続名は、config/queue.php 構成ファイルで定義されている接続の 1 つと一致する必要があります。

Redis::funnel('key')->limit(1)->then(function () {
    // 任务逻辑...},
    function () {  
      // 无法获得锁...   
     return $this->release(10);
 });

接続で指定されたキューのみを実行するようにキュー ハンドラーをカスタマイズすることもできます。たとえば、すべての電子メールが redis 接続の emails キューによって処理される場合、次のコマンドを使用してこのキューのみを実行するプロセッサを起動できます:

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

単一タスクの実行

--once オプションは、キュー プロセッサがキュー内の 1 つのタスクのみを処理するようにするために使用されます。

php artisan queue:work

キューに登録されたすべてのタスクを処理してから終了します。

--stop-when-empty オプションを使用して、キュー プロセッサを処理することができます。すべてのジョブを実行し、正常に終了します。このオプションは、Docker コンテナで Laravel キューを実行するときに、キューが空になった後にコンテナをシャットダウンしたい場合に便利です:

php artisan queue:work redis

リソース ノート

バックグラウンド常駐残りのキュー ハンドラーは、各タスクの実行後にフレームワークを「再起動」しません。したがって、各タスクが完了したら、過剰なリソースを解放する必要があります。たとえば、GD ライブラリを使用して画像処理を実行している場合は、終了時に imagedestroy を使用してメモリを解放する必要があります。

キューの優先順位

キューの実行に優先順位を付けたい場合があります。たとえば、config/queue.php で、redis に接続されている queue キューの優先度を default から ## に設定できます。 ＃ 低い＃＃＃。ただし、場合によっては、次のようにタスクを high キューにプッシュすることもできます。

php artisan queue:work redis --queue=emails

キュー内のタスクが実行されていることを確認します。 in all high キュー タスクの完了後にのみ実行を継続するには、キュー名のカンマ区切りリストを引数として work コマンドに渡すことができます。

php artisan queue:work --once

queue:restart

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

Supervisor などのプロセス マネージャーを実行してキュー プロセッサを自動的に再起動する必要があります。 {ヒント} キューはキャッシュを使用して再起動信号を保存するため、この機能を使用する前にキャッシュ ドライバーを必ず設定する必要があります。

タスクの有効期限とタイムアウト

オプションが定義されています。このオプションは、キュー接続がタスクを再試行するまで待機する時間を指定します。たとえば、

の値が 90 に設定されている場合、タスクは実行の 90 秒後に削除されずにキューに戻されます。一般に、retry_after の値は、タスクの実行に最も時間がかかると思われる値に設定する必要があります。 {note} retry_after 値は Amazon SQS にのみ存在するわけではありません。 SQS は、AWS コンソールで設定されたデフォルトの表示タイムアウト値に基づいてタスクを再試行します。

プロセッサ タイムアウト

queue:work Artisan コマンドには --timeout オプションが含まれています。 --timeout オプションは、タスクを実行している子プロセスを中止する前に、Laravel のキューマスタープロセスが待機する時間を指定します。場合によっては、外部 HTTP リクエストへの応答の失敗など、さまざまな理由で子プロセスが「フリーズ」することがあります。 --timeout オプションは、指定された時間より長くフリーズされたプロセスを削除します。

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

retry_after 構成項目と --timeout コマンドライン構成は同じではありませんが、同時に使用することでタスクが失われることはありません。また、タスクは 1 回だけ正常に実行されます。

{note} --timeout の値は、retry_after で設定した値より少なくとも数秒短くする必要があります。これにより、タスクを再試行する前にプロセッサが常に中止されることが保証されます。 --timeout 値が retry_after の値より長い場合、タスクが 2 回実行される可能性があります。

キュー プロセスのスリープ時間

タスクがキュー内にある場合、プロセッサは間隔を置かずに常にタスクを処理します。ただし、sleep オプションは、新しいタスクがない場合にプロセッサが「スリープ」する時間を定義します。プロセッサがスリープしている間は、新しいタスクは処理されません。タスクは、キュー プロセッサが再度起動されると実行されます。

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

スーパーバイザーの構成

スーパーバイザーのインストール

スーパーバイザーは Linux ですqueue:work がハングしたときに自動的に再起動できるオペレーティング システム上のプロセス モニター。 Ubuntu に Supervisor をインストールするには、次のコマンドを使用できます:

php artisan queue:restart

{ヒント} Supervisor の構成が難しい場合は、Laravel Forge の使用を検討できます。 Laravel プロジェクト用に Supervisor を自動的にインストールして設定します。

スーパーバイザーの設定

スーパーバイザー設定ファイルは通常、/etc/supervisor/conf.d ディレクトリにあります。このディレクトリには、スーパーバイザがプロセスを監視する方法を制御するために、任意の数の構成ファイルを作成できます。たとえば、laravel-worker.conf ファイルを作成して、queue:work プロセスを開始および監視します。

php artisan queue:work --timeout=60

この例では、numprocs ディレクティブは、8 つの queue:work プロセスを実行して監視し、ハングした場合に自動的に再起動するようにスーパーバイザーを指定します。必要なキュー接続を表すように、command オプションの queue:work sqs 部分を変更する必要があります。

Start Supervisor

設定ファイルが作成されたら、次のコマンドを使用してスーパーバイザ設定を更新し、プロセスを開始できます:

php artisan queue:work --sleep=3

スーパーバイザの詳細については、次のコマンドを使用して確認できます。 Supervisor Documentation.

失敗したタスクの処理

キューに入れられたタスクの実行が失敗することがあります。 。心をリラックスしてください。良いことは時間内にのみやって来ます。 Laravel には、タスクを試行する最大回数を指定する便利なメソッドが含まれています。ジョブが最大試行回数に達した場合、そのジョブは failed_jobs データベース テーブルに挿入されます。 failed_jobs データベース移行テーブルを作成するには、queue:failed-table コマンドを使用できます。

sudo apt-get install supervisor

次に、queue worker# を実行します。 ##、queue:work コマンドで --tries スイッチを使用して、タスクの実行を試行する最大回数を指定する必要があります。 --tries オプションに値が指定されていない場合、無限ループによってタスクの実行が試行されます:

[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
autostart=true
autorestart=true
user=forge
numprocs=8
redirect_stderr=true
stdout_logfile=/home/forge/app.com/worker.log

タスク失敗後のクリーンアップ

タスク クラスで直接

failed メソッドを定義すると、タスクが失敗したときにタスクのクリーンアップ作業を実行できます。これは、ユーザーにアラートを送信したり、タスクによって実行されたアクションを再開したりするのに最適な場所です。タスクを失敗させる Exception は、failed メソッドに渡されます:

sudo supervisorctl reread

sudo supervisorctl update

sudo supervisorctl start laravel-worker:*

タスク失敗イベント

タスクが失敗したときに呼び出し可能なイベントを登録したい場合は、

Queue::failing メソッドを使用できます。このイベントは、メールまたは Slack でチームに通知するのに最適な機会です。たとえば、Laravel の AppServiceProvider にコールバック イベントを添付できます:

php artisan queue:failed-table

php artisan migrate

失敗したタスクを再試行

failed_jobs データ テーブルに配置されているすべてのタスクを表示するには、Artisan コマンド queue:failed:

php artisan queue:work redis --tries=3

を使用できます。 queue:failed このコマンドにより、タスク ID、キュー、および失敗時間がリストされます。タスク ID は、失敗したタスクを再試行するために使用できます。たとえば、タスク ID 5 のタスクを再試行するには、次のコマンドを使用します。

<?php
    namespace App\Jobs;
    use Exception;use App\Podcast;
    use App\AudioProcessor;
    use Illuminate\Bus\Queueable;
    use Illuminate\Queue\SerializesModels;
    use Illuminate\Queue\InteractsWithQueue;
    use Illuminate\Contracts\Queue\ShouldQueue;
    class ProcessPodcast implements ShouldQueue{ 
       use InteractsWithQueue, Queueable, SerializesModels;    
       protected $podcast;   
     /**
     * 创建任务实例
     *
     * @param  Podcast  $podcast
     * @return void
     */   
     public function __construct(Podcast $podcast)  
       {       
        $this->podcast = $podcast;  
        }   
    /**
     * 执行任务
     *
     * @param  AudioProcessor  $processor
     * @return void
     */  
     public function handle(AudioProcessor $processor) 
        {     
           // 上传播客……   
         }  
    /**
     * 任务失败的处理过程
     *
     * @param  Exception  $exception
     * @return void
     */   
     public function failed(Exception $exception) 
        {     
          // 给用户发送任务失败的通知，等等……   
         }
      }

失敗したすべてのタスクを再試行するには、

queue:retry コマンドを実行し、Pass all を ID として使用します:

<?php
    namespace App\Providers;
    use Illuminate\Support\Facades\Queue;
    use Illuminate\Queue\Events\JobFailed;
    use Illuminate\Support\ServiceProvider;
    class AppServiceProvider extends ServiceProvider{   
     /**
     * 启动任意服务。
     *
     * @return void
     */    
    public function boot()   
     {       
      Queue::failing(function (JobFailed $event) {     
             // $event->connectionName            
             // $event->job            
             // $event->exception        
           }); 
       }    
    /**
     * 注册服务提供者。
     *
     * @return void
     */    
    public function register()    { 
           //   
           }
    }

失敗したタスクを削除する場合は、

queue:forget コマンドを使用します:

php artisan queue:failed

失敗したすべてのタスクについては、

queue:flush コマンドを使用します:

php artisan queue:retry 5

不足しているモデルを無視する

Eloquent モデルをタスクに挿入すると、モデルはキューに入れられる前に自動的にシリアル化され、タスクの実行時に復元されます。ただし、タスクの実行待機中にモデルが削除された場合、タスクは ModelNotFoundException で失敗する可能性があります。

便宜上、タスクの deleteWhenMissingModels プロパティを true に設定して、モデルが欠落しているタスクを自動的に削除することを選択できます。

php artisan queue:retry all

タスク イベント

Queue ファサードで before# を使用する## メソッドと after メソッドでは、キュー タスクの実行前後にコールバックを指定できます。これらのコールバックは、ログを追加したり、統計を増やしたりする絶好の機会となります。通常、これらのメソッドはサービス プロバイダーで呼び出す必要があります。たとえば、Laravel の AppServiceProvider を使用できます。

php artisan queue:forget 5

Queue ファサードの looping メソッドを使用して、プロセッサがコールバックを実行する前にコールバックを実行します。タスクを取得します。たとえば、クロージャを使用して、以前に失敗したタスクによってまだクローズされていないトランザクションをロールバックすることができます。

php artisan queue:flush

この記事は、

LearnKu.com Web サイトに初めて掲載されました。