مقدمه: چرا پردازش پس‌زمینه در نرم‌افزارهای تحت وب حیاتی است؟

در یک نرم‌افزار تحت وب حرفه‌ای، همه کارها نباید هم‌زمان با درخواست کاربر انجام شوند. وقتی کاربر روی دکمه ثبت سفارش، ارسال فرم، بارگذاری فایل، پرداخت، ثبت‌نام یا دریافت گزارش کلیک می‌کند، انتظار دارد سیستم سریع پاسخ بدهد. اما در پشت صحنه ممکن است کارهای زیادی لازم باشد: ارسال ایمیل، ارسال پیامک، تولید فاکتور، ساخت فایل PDF، بررسی موجودی، اتصال به API خارجی، ثبت لاگ، به‌روزرسانی آمار، Sync با CRM، پردازش تصویر یا تولید گزارش‌های سنگین.

اگر همه این کارها در همان لحظه و داخل همان Request اجرا شوند، کاربر باید منتظر بماند. این انتظار ممکن است چند ثانیه، ده‌ها ثانیه یا حتی بیشتر طول بکشد. نتیجه آن می‌تواند تجربه کاربری ضعیف، Timeout، فشار روی سرور، کاهش نرخ تبدیل و حتی از دست رفتن مشتری باشد.

در Laravel برای حل این مسئله از Job و Queue استفاده می‌شود. Job نماینده یک کار مشخص است و Queue صفی است که این کارها در آن قرار می‌گیرند تا بعداً توسط Workerها پردازش شوند. به زبان ساده، به جای اینکه کار زمان‌بر را همان لحظه انجام دهیم، آن را به صف می‌فرستیم و سریع به کاربر پاسخ می‌دهیم.

برای مثال، بعد از ثبت سفارش، لازم نیست کاربر منتظر ارسال ایمیل، پیامک، تولید فاکتور و اطلاع‌رسانی به انبار بماند. سیستم می‌تواند سفارش را ثبت کند، پاسخ موفقیت را برگرداند و کارهای جانبی را در پس‌زمینه انجام دهد.

در پروژه‌هایی که شرکت‌هایی مانند اسمارتی اپ (SmartyApp) برای طراحی سایت، تولید نرم‌افزار اختصاصی و برنامه‌نویسی نرم‌افزارهای تحت وب اجرا می‌کنند، استفاده درست از Job و Queue در Laravel فقط یک قابلیت فنی نیست؛ بلکه بخشی از طراحی معماری نرم‌افزار برای سرعت، پایداری و مقیاس‌پذیری است.

Job و Queue در Laravel چیست؟

برای درک بهتر این موضوع، ابتدا باید دو مفهوم اصلی را جدا کنیم: Job و Queue.

Job چیست؟

Job در Laravel یک کلاس است که یک کار مشخص را انجام می‌دهد. این کار می‌تواند ساده یا پیچیده باشد. مثلاً:

• ارسال ایمیل خوشامدگویی
• ارسال پیامک تأیید سفارش
• ساخت فاکتور PDF
• پردازش فایل Excel
• فشرده‌سازی تصویر
• Sync اطلاعات با API خارجی
• محاسبه آمار فروش
• بررسی پرداخت
• ارسال Notification
• تولید خروجی گزارش

یک Job معمولاً در مسیر زیر قرار می‌گیرد:

app/Jobs

برای ساخت Job می‌توان از دستور Artisan زیر استفاده کرد:

php artisan make:job SendOrderSmsJob

نمونه ساده Job:

<?php namespace App\Jobs; use App\Models\Order; use App\Services\SmsService; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Foundation\Queue\Queueable; class SendOrderSmsJob implements ShouldQueue {    use Queueable;    public function __construct(        public Order $order    ) {}    public function handle(SmsService $smsService): void    {        $smsService->send(            $this->order->user->mobile,            'سفارش شما با موفقیت ثبت شد.'        );    } }

در این نمونه، کلاس Job مسئول ارسال پیامک سفارش است. چون این کلاس ShouldQueue را پیاده‌سازی کرده، Laravel آن را به‌عنوان کاری قابل اجرا در صف می‌شناسد.

Queue چیست؟

Queue یا صف، محلی است که Jobها در آن قرار می‌گیرند تا در زمان مناسب پردازش شوند. به جای اجرای فوری یک کار زمان‌بر، آن کار به صف فرستاده می‌شود و یک Worker آن را بعداً اجرا می‌کند.

طبق مستندات رسمی Laravel، Queueها امکان انتقال کارهای زمان‌بر به پس‌زمینه را فراهم می‌کنند تا برنامه بتواند به درخواست‌های وب سریع‌تر پاسخ دهد و تجربه کاربری بهتری ایجاد کند. Laravel همچنین API یکپارچه‌ای برای Driverهای مختلف صف مثل Database، Redis و Amazon SQS ارائه می‌دهد. برای مطالعه بیشتر می‌توانید به مستندات رسمی Laravel درباره Queues مراجعه کنید.

چرا باید از Queue استفاده کنیم؟

استفاده از Queue فقط برای پروژه‌های بسیار بزرگ نیست. حتی در پروژه‌های متوسط نیز بسیاری از کارها بهتر است در پس‌زمینه اجرا شوند.

افزایش سرعت پاسخ‌گویی

فرض کنید ثبت سفارش شامل ارسال ایمیل، پیامک، تولید فاکتور و اطلاع‌رسانی به انبار است. اگر همه این کارها همان لحظه انجام شوند، کاربر چند ثانیه منتظر می‌ماند. اما اگر این کارها به Queue منتقل شوند، پاسخ ثبت سفارش سریع‌تر برمی‌گردد.

جلوگیری از Timeout

پردازش فایل‌های حجیم، تولید گزارش‌های سنگین یا فراخوانی APIهای خارجی ممکن است بیشتر از زمان مجاز Request طول بکشد. Queue کمک می‌کند این کارها خارج از Request اصلی اجرا شوند.

کنترل بهتر منابع سرور

Workerهای Queue را می‌توان جداگانه مدیریت کرد. مثلاً می‌توان تعداد Workerها را افزایش داد، برای صف‌های مختلف اولویت تعریف کرد یا پردازش‌های سنگین را از درخواست‌های کاربر جدا نگه داشت.

افزایش پایداری سیستم

اگر ارسال ایمیل یا ارتباط با یک API خارجی موقتاً با خطا مواجه شود، Job می‌تواند دوباره تلاش کند. در نتیجه، خطای موقت باعث شکست کامل فرآیند اصلی نمی‌شود.

مناسب برای مقیاس‌پذیری

وقتی پروژه رشد می‌کند، تعداد درخواست‌ها و پردازش‌ها بیشتر می‌شود. Queue کمک می‌کند بار پردازشی بهتر توزیع شود و سیستم برای رشد آماده‌تر باشد.

جدول کاربردهای رایج Job و Queue در Laravel

تفاوت اجرای مستقیم و اجرای صفی

فرض کنید بعد از ثبت سفارش می‌خواهید پیامک ارسال کنید.

اجرای مستقیم

public function store(StoreOrderRequest $request, SmsService $smsService) {    $order = Order::create($request->validated());    $smsService->send($order->user->mobile, 'سفارش شما ثبت شد.');    return response()->json([        'message' => 'سفارش با موفقیت ثبت شد.'    ]); }

در این حالت، کاربر باید منتظر ارسال پیامک بماند. اگر سرویس پیامک کند باشد، پاسخ سایت هم کند می‌شود.

اجرای صفی با Job

public function store(StoreOrderRequest $request) {    $order = Order::create($request->validated());    SendOrderSmsJob::dispatch($order);    return response()->json([        'message' => 'سفارش با موفقیت ثبت شد.'    ]); }

در این حالت، پیامک به صف فرستاده می‌شود و پاسخ سریع‌تر به کاربر برمی‌گردد.

ساخت Job در Laravel؛ قدم‌به‌قدم

قدم اول: ساخت Job

php artisan make:job ProcessInvoiceJob

Laravel فایلی در مسیر app/Jobs ایجاد می‌کند.

<?php namespace App\Jobs; use App\Models\Order; use App\Services\InvoiceService; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Foundation\Queue\Queueable; class ProcessInvoiceJob implements ShouldQueue {    use Queueable;    public function __construct(        public Order $order    ) {}    public function handle(InvoiceService $invoiceService): void    {        $invoiceService->createForOrder($this->order);    } }

قدم دوم: Dispatch کردن Job

ProcessInvoiceJob::dispatch($order);

این خط Job را به Queue می‌فرستد.

قدم سوم: اجرای Worker

برای پردازش Jobها باید Worker اجرا شود:

php artisan queue:work

تا زمانی که Worker فعال نباشد، Jobها در صف باقی می‌مانند و اجرا نمی‌شوند.

Queue Driver در Laravel

Laravel از Driverهای مختلفی برای Queue پشتیبانی می‌کند. Driver مشخص می‌کند Jobها کجا ذخیره شوند و چگونه پردازش شوند.

تنظیم Queue معمولاً از طریق فایل .env انجام می‌شود:

QUEUE_CONNECTION=database

یا:

QUEUE_CONNECTION=redis

Laravel در فایل config/queue.php تنظیمات اتصال‌های مختلف Queue را نگهداری می‌کند.

Driverهای رایج Queue

برای پروژه‌های کوچک، database می‌تواند شروع خوبی باشد. برای پروژه‌های جدی‌تر و پرترافیک، Redis معمولاً انتخاب بهتری است، مخصوصاً اگر بخواهید از Laravel Horizon استفاده کنید.

راه‌اندازی Queue با Database Driver

اگر می‌خواهید Jobها در دیتابیس ذخیره شوند، ابتدا مقدار .env را تنظیم کنید:

QUEUE_CONNECTION=database

سپس جدول‌های لازم را بسازید:

php artisan queue:table php artisan migrate

حالا Jobها در جدول jobs ذخیره می‌شوند.

برای اجرای Worker:

php artisan queue:work

Database Driver برای شروع ساده و قابل فهم است، اما در پروژه‌های پرترافیک ممکن است Redis عملکرد بهتری داشته باشد.

راه‌اندازی Queue با Redis

Redis یک ذخیره‌ساز درون‌حافظه‌ای سریع است که برای Queueهای پرترافیک بسیار مناسب است. برای استفاده از Redis باید مقدار Queue Connection را تغییر دهید:

QUEUE_CONNECTION=redis

Laravel در مستندات Queue خود Redis را یکی از Driverهای پشتیبانی‌شده معرفی می‌کند. برای پروژه‌هایی که تعداد Job زیاد دارند یا نیاز به سرعت بالاتر دارند، Redis گزینه‌ای رایج و حرفه‌ای است.

در محیط Production، اگر Redis استفاده می‌کنید، بهتر است از Laravel Horizon برای مانیتورینگ و مدیریت صف‌ها کمک بگیرید.

Laravel Horizon چیست و چه کاربردی دارد؟

Laravel Horizon یک ابزار رسمی برای مانیتورینگ و مدیریت Queueهای مبتنی بر Redis است. Horizon داشبوردی گرافیکی و تنظیمات کدمحور برای Queueها فراهم می‌کند و امکان مشاهده شاخص‌هایی مثل تعداد Jobها، زمان اجرا، شکست‌ها و Throughput را می‌دهد. برای اطلاعات بیشتر می‌توانید مستندات رسمی Laravel Horizon را مطالعه کنید.

در پروژه‌های Production، فقط اجرا شدن Queue کافی نیست. شما باید بدانید:

• چه تعداد Job در صف مانده است؟
• کدام Jobها شکست خورده‌اند؟
• زمان متوسط اجرای Jobها چقدر است؟
• کدام صف بیشترین فشار را دارد؟
• آیا Workerها درست کار می‌کنند؟
• آیا Jobهای مهم با تأخیر پردازش می‌شوند؟

Horizon برای پاسخ به همین سؤال‌ها طراحی شده است.

نصب Horizon

composer require laravel/horizon

انتشار فایل تنظیمات:

php artisan horizon:install php artisan migrate

اجرای Horizon:

php artisan horizon

Horizon مخصوص Redis Queue است و برای Database Driver استفاده نمی‌شود.

Queue Worker چیست؟

Worker فرایندی است که Jobها را از Queue برمی‌دارد و اجرا می‌کند. اگر Job را به صف بفرستید اما Worker فعال نباشد، هیچ اتفاقی نمی‌افتد.

فرمان اصلی:

php artisan queue:work

Worker معمولاً در محیط Production باید همیشه فعال باشد. برای این کار از ابزارهایی مثل Supervisor، systemd یا ابزارهای مدیریت Process استفاده می‌شود.

اجرای Worker برای یک صف خاص

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

در این مثال، Worker ابتدا صف high را پردازش می‌کند، سپس default و بعد low.

چرا اولویت‌بندی صف‌ها مهم است؟

همه Jobها ارزش و فوریت یکسان ندارند. مثلاً:

• تأیید پرداخت باید سریع پردازش شود.
• ارسال ایمیل تبلیغاتی می‌تواند با تأخیر انجام شود.
• تولید گزارش‌های سنگین نباید صف‌های حساس را قفل کند.

بنابراین می‌توان Queueهای مختلف تعریف کرد:

VerifyPaymentJob::dispatch($payment)->onQueue('high'); SendNewsletterJob::dispatch($campaign)->onQueue('low');

Retry و مدیریت خطا در Jobها

یکی از مزایای مهم Queue در Laravel، امکان تلاش مجدد در صورت شکست Job است.

فرض کنید Job شما به یک API خارجی متصل می‌شود. اگر API برای چند لحظه در دسترس نباشد، نباید کل فرآیند برای همیشه شکست بخورد. می‌توان تعیین کرد Job چند بار تلاش کند.

class SyncCustomerToCrmJob implements ShouldQueue {    use Queueable;    public int $tries = 3;    public function handle(CrmService $crmService): void    {        $crmService->sync($this->customer);    } }

تعیین Backoff

Backoff یعنی فاصله بین تلاش‌های مجدد:

public function backoff(): array {    return [60, 300, 900]; }

یعنی تلاش اول بعد از ۶۰ ثانیه، تلاش دوم بعد از ۵ دقیقه و تلاش سوم بعد از ۱۵ دقیقه انجام شود.

متد failed

اگر Job بعد از تلاش‌های مشخص همچنان شکست بخورد، می‌توان از متد failed استفاده کرد:

public function failed(Throwable $exception): void {    report($exception);    // ارسال هشدار به تیم فنی یا ثبت لاگ اختصاصی }

این روش برای پروژه‌های حساس مثل پرداخت، مالی، رزرو و Sync داده بسیار مهم است.

Failed Jobs در Laravel

گاهی Jobها با خطا مواجه می‌شوند و بعد از تعداد تلاش مجاز شکست می‌خورند. Laravel امکان ذخیره و مدیریت Failed Jobها را فراهم می‌کند.

برای ساخت جدول Failed Jobs:

php artisan queue:failed-table php artisan migrate

مشاهده Jobهای شکست‌خورده:

php artisan queue:failed

اجرای مجدد یک Job شکست‌خورده:

php artisan queue:retry JOB_ID

حذف همه Failed Jobها:

php artisan queue:flush

در پروژه‌های Production، بررسی Failed Jobها باید بخشی از مانیتورینگ روزانه یا هفتگی تیم فنی باشد.

Delayed Jobs؛ اجرای Job با تأخیر

گاهی لازم است Job نه فوراً، بلکه بعد از مدتی اجرا شود.

مثلاً:

• ارسال پیامک یادآوری یک ساعت قبل از نوبت
• ارسال ایمیل پیگیری بعد از ۲۴ ساعت
• بررسی وضعیت پرداخت بعد از چند دقیقه
• آزاد کردن رزرو پرداخت‌نشده بعد از ۱۵ دقیقه

نمونه:

SendReminderSmsJob::dispatch($reservation)    ->delay(now()->addHour());

یا:

ReleaseUnpaidOrderJob::dispatch($order)    ->delay(now()->addMinutes(15));

Delayed Job برای کسب‌وکارهایی که فرآیندهای زمان‌محور دارند بسیار کاربردی است.

Job Batching در Laravel

گاهی لازم است مجموعه‌ای از Jobها به‌صورت گروهی اجرا شوند. مثلاً پردازش ۱۰ هزار ردیف فایل Excel، تولید گزارش برای چند شعبه یا ارسال پیامک گروهی.

Laravel از Batch Jobها پشتیبانی می‌کند. با Batch می‌توان مجموعه‌ای از Jobها را اجرا و وضعیت کلی آن‌ها را پیگیری کرد.

use Illuminate\Support\Facades\Bus; Bus::batch([    new ProcessImportRowJob($row1),    new ProcessImportRowJob($row2),    new ProcessImportRowJob($row3), ])->dispatch();

Batchها برای پردازش‌های حجیم بسیار مناسب هستند، چون می‌توان وضعیت کل عملیات را کنترل کرد و در صورت پایان یا شکست، اقدام مناسب انجام داد.

Queue و ارسال ایمیل در Laravel

یکی از رایج‌ترین کاربردهای Queue، ارسال ایمیل است. ارسال ایمیل ممکن است به SMTP یا سرویس‌های خارجی وابسته باشد و گاهی چند ثانیه طول بکشد.

Laravel یک API ساده برای ارسال ایمیل فراهم می‌کند و از Driverهایی مثل SMTP، Mailgun، Postmark، Resend، Amazon SES و Sendmail پشتیبانی می‌کند. برای جزئیات بیشتر می‌توانید به مستندات رسمی Laravel درباره Mail مراجعه کنید.

برای Queue کردن ایمیل، می‌توان Mailable را Queue کرد:

Mail::to($user->email)->queue(new WelcomeMail($user));

یا اگر Mailable شما ShouldQueue را پیاده‌سازی کند، حتی ارسال عادی هم می‌تواند صفی شود.

class WelcomeMail extends Mailable implements ShouldQueue {    // ... }

در پروژه‌های واقعی، ارسال ایمیل‌های زیر بهتر است از طریق Queue انجام شود:

• ایمیل خوشامدگویی
• ایمیل تأیید سفارش
• ایمیل بازیابی رمز عبور
• ارسال فاکتور
• ایمیل اطلاع‌رسانی وضعیت سفارش
• ایمیل گزارش دوره‌ای
• ایمیل‌های کمپین بازاریابی

Queue و ارسال پیامک

در بسیاری از کسب‌وکارهای ایرانی، پیامک نقش مهمی دارد؛ از تأیید شماره موبایل گرفته تا اطلاع‌رسانی سفارش و یادآوری نوبت.

نمونه Job ارسال پیامک:

class SendVerificationCodeJob implements ShouldQueue {    use Queueable;    public function __construct(        public string $mobile,        public string $code    ) {}    public function handle(SmsService $smsService): void    {        $smsService->send($this->mobile, "کد تأیید شما: {$this->code}");    } }

Dispatch:

SendVerificationCodeJob::dispatch($mobile, $code);

در این ساختار، اگر سرویس پیامک کند یا موقتاً قطع باشد، تجربه اصلی کاربر کمتر آسیب می‌بیند و امکان Retry وجود دارد.

مثال واقعی: ثبت سفارش در فروشگاه اینترنتی

فرض کنید یک فروشگاه اینترنتی با Laravel دارید. بعد از ثبت سفارش، چند کار باید انجام شود:

1. ثبت سفارش در دیتابیس
2. کم کردن موجودی
3. ساخت فاکتور
4. ارسال ایمیل سفارش
5. ارسال پیامک به مشتری
6. اطلاع‌رسانی به انبار
7. Sync با نرم‌افزار حسابداری

همه این کارها نباید داخل Controller اجرا شوند. ساختار بهتر:

class OrderController extends Controller {    public function store(StoreOrderRequest $request, CheckoutService $checkoutService)    {        $order = $checkoutService->createOrder($request->validated());        GenerateInvoiceJob::dispatch($order);        SendOrderEmailJob::dispatch($order);        SendOrderSmsJob::dispatch($order);        SyncOrderWithAccountingJob::dispatch($order);        return response()->json([            'message' => 'سفارش شما با موفقیت ثبت شد.',            'order_id' => $order->id,        ], 201);    } }

در این معماری، کاربر سریع پاسخ می‌گیرد و عملیات جانبی در پس‌زمینه انجام می‌شود.

برای کسب‌وکارهای فروشگاهی، این موضوع مستقیماً روی سرعت سایت، نرخ تبدیل و رضایت مشتری اثر دارد.

مثال واقعی: پردازش فایل Excel در CRM

فرض کنید یک CRM دارید و مدیر فروش می‌خواهد فایل Excel شامل چند هزار مشتری بالقوه را وارد سیستم کند. اگر پردازش فایل در همان Request انجام شود، احتمال Timeout بسیار زیاد است.

راه‌حل بهتر:

class ImportLeadsController extends Controller {    public function store(ImportLeadsRequest $request)    {        $path = $request->file('file')->store('imports');        ImportLeadsJob::dispatch($path, $request->user()->id);        return response()->json([            'message' => 'فایل دریافت شد و پردازش آن در پس‌زمینه آغاز شد.'        ]);    } }

Job پردازش فایل:

class ImportLeadsJob implements ShouldQueue {    use Queueable;    public function __construct(        public string $path,        public int $userId    ) {}    public function handle(LeadImportService $service): void    {        $service->import($this->path, $this->userId);    } }

در پایان پردازش می‌توان یک Notification برای کاربر ارسال کرد. این مدل برای CRM، ERP، سیستم‌های آموزشی، مالی و پنل‌های مدیریتی بسیار کاربردی است.

مثال واقعی: تولید گزارش‌های سنگین

در نرم‌افزارهای مدیریتی، گزارش‌گیری یکی از بخش‌های مهم است. اما برخی گزارش‌ها سنگین‌اند؛ مثلاً:

• گزارش فروش سالانه
• گزارش عملکرد شعب
• گزارش مالی ماهانه
• گزارش کاربران فعال
• خروجی Excel چندصدهزار رکوردی
• گزارش سفارش‌های دارای مغایرت

اجرای چنین گزارش‌هایی داخل Request اصلی می‌تواند باعث کندی یا Timeout شود. بهتر است درخواست گزارش ثبت شود و Job آن را در پس‌زمینه تولید کند.

GenerateSalesReportJob::dispatch($reportRequest);

بعد از آماده شدن گزارش، سیستم می‌تواند لینک دانلود را در پنل کاربر نمایش دهد یا از طریق ایمیل ارسال کند.

مثال واقعی: Sync با API خارجی

بسیاری از نرم‌افزارهای تحت وب باید با سرویس‌های خارجی ارتباط داشته باشند:

• CRM
• ERP
• نرم‌افزار حسابداری
• سامانه پیامک
• درگاه پرداخت
• سرویس حمل‌ونقل
• سرویس انبارداری
• سامانه‌های دولتی یا سازمانی

ارتباط با API خارجی همیشه قابل پیش‌بینی نیست. ممکن است کند باشد، خطا بدهد یا موقتاً در دسترس نباشد. Queue کمک می‌کند این ارتباط‌ها از جریان اصلی کاربر جدا شوند.

SyncCustomerToCrmJob::dispatch($customer)->onQueue('integrations');

استفاده از صف جدا برای Integrationها باعث می‌شود اختلال یک سرویس خارجی کل سیستم را کند نکند.

در پروژه‌های تولید نرم‌افزار اختصاصی، اسمارتی اپ (SmartyApp) معمولاً چنین پردازش‌هایی را از Request اصلی جدا می‌کند تا نرم‌افزار هم سریع‌تر باشد و هم در برابر خطاهای سرویس‌های بیرونی مقاوم‌تر عمل کند.

ارتباط Job و Queue با Service Layer

Job نباید محل انباشت منطق سنگین کسب‌وکار باشد. Job بهتر است کار را به Service مناسب بسپارد.

نمونه نامناسب:

public function handle(): void {    // ده‌ها خط کد مربوط به ساخت فاکتور، محاسبه مالیات،    // ذخیره رکوردها، ارسال پیامک و ... }

نمونه بهتر:

public function handle(InvoiceService $invoiceService): void {    $invoiceService->createForOrder($this->order); }

در معماری تمیز Laravel، Job فقط مسئول اجرای پس‌زمینه یک Use Case است. منطق اصلی بهتر است در Service Layer قرار بگیرد تا هم از Controller، هم از Command، هم از Job قابل استفاده باشد.

Event و Listener در کنار Queue

گاهی به‌جای اینکه مستقیم چند Job را Dispatch کنیم، بهتر است یک Event منتشر شود و Listenerها کارهای جانبی را انجام دهند.

مثلاً بعد از ثبت سفارش:

OrderCreated::dispatch($order);

Listenerها:

• SendOrderSmsListener
• SendOrderEmailListener
• GenerateInvoiceListener
• NotifyWarehouseListener

Listenerها نیز می‌توانند Queue شوند. این روش برای سیستم‌های رویدادمحور مناسب است و وابستگی مستقیم بین بخش‌ها را کمتر می‌کند.

زمان‌بندی Jobها با Laravel Scheduler

گاهی لازم است Jobها طبق برنامه زمانی اجرا شوند؛ مثلاً:

• ارسال گزارش روزانه
• بررسی سفارش‌های پرداخت‌نشده
• آزادسازی رزروهای منقضی‌شده
• ارسال یادآوری تمدید اشتراک
• Sync دوره‌ای با API خارجی

Laravel ابزار Scheduler را برای تعریف کارهای زمان‌بندی‌شده ارائه می‌دهد. طبق مستندات رسمی Laravel، می‌توان وظایف زمان‌بندی‌شده را با Closure، Command، Job یا Artisan Command مدیریت کرد. برای مطالعه بیشتر می‌توانید مستندات رسمی Laravel درباره Task Scheduling را ببینید.

نمونه:

use Illuminate\Support\Facades\Schedule; Schedule::job(new SendSubscriptionRenewalRemindersJob)->daily();

یا:

Schedule::command('orders:release-unpaid')->everyFiveMinutes();

ترکیب Scheduler و Queue برای فرآیندهای زمان‌محور کسب‌وکار بسیار ارزشمند است.

مزایای Job و Queue در Laravel

1. افزایش سرعت پاسخ‌گویی نرم‌افزار

کاربر سریع‌تر پاسخ می‌گیرد، چون کارهای زمان‌بر به پس‌زمینه منتقل می‌شوند.

2. بهبود تجربه کاربری

وقتی ثبت سفارش، ثبت‌نام یا ارسال فرم سریع انجام شود، کاربر حس بهتری نسبت به نرم‌افزار پیدا می‌کند.

3. کاهش احتمال Timeout

پردازش‌های سنگین خارج از Request اصلی انجام می‌شوند و محدودیت زمان اجرای Request کمتر مشکل‌ساز می‌شود.

4. مدیریت بهتر خطا

Jobها می‌توانند Retry شوند و Failed Jobها قابل بررسی و اجرای مجدد هستند.

5. مقیاس‌پذیری بهتر

می‌توان Workerهای بیشتری اجرا کرد، صف‌های جدا ساخت و بار پردازشی را بهتر توزیع کرد.

6. جداسازی مسئولیت‌ها

Controllerها و Serviceها تمیزتر می‌مانند و کارهای پس‌زمینه در کلاس‌های مشخص مدیریت می‌شوند.

7. مناسب برای اتصال به سرویس‌های خارجی

ارتباط با APIهای کند یا ناپایدار از مسیر اصلی کاربر جدا می‌شود.

8. مناسب برای پروژه‌های سازمانی و SaaS

نرم‌افزارهای تحت وب جدی معمولاً پردازش‌های زیادی دارند که باید در پس‌زمینه اجرا شوند.

چالش‌های Job و Queue در Laravel

1. نیاز به مانیتورینگ

Queue بدون مانیتورینگ می‌تواند خطرناک باشد. ممکن است Jobها در صف بمانند، شکست بخورند یا Worker متوقف شود و تیم متوجه نشود.

2. پیچیدگی در Production

در محیط واقعی باید Workerها همیشه فعال باشند. این موضوع نیاز به Supervisor، systemd، Docker Process Manager یا Horizon دارد.

3. خطاهای پنهان

اگر Failed Jobها بررسی نشوند، ممکن است بخشی از سیستم به ظاهر کار کند، اما پردازش‌های پس‌زمینه شکست خورده باشند.

4. مشکل Race Condition

اگر چند Job هم‌زمان روی یک داده کار کنند، ممکن است تداخل ایجاد شود. در این شرایط باید از Lock، Transaction یا طراحی مناسب استفاده کرد.

5. وابستگی به سرویس‌های بیرونی

اگر Job به API خارجی وابسته است، باید Retry، Timeout و مدیریت خطا به‌خوبی طراحی شود.

6. Serializing مدل‌ها

وقتی Model به Job پاس داده می‌شود، باید دقت کرد داده در زمان اجرای Job ممکن است تغییر کرده یا حذف شده باشد. در برخی موارد بهتر است فقط ID مدل پاس داده شود و داخل Job دوباره از دیتابیس خوانده شود.

7. صف‌های بدون اولویت‌بندی

اگر همه Jobها در یک صف باشند، کارهای سنگین ممکن است کارهای فوری را عقب بیندازند.

بهترین روش‌ها برای استفاده حرفه‌ای از Job و Queue

1. Jobها را کوچک و مشخص طراحی کنید

هر Job بهتر است یک مسئولیت مشخص داشته باشد. مثلاً:

SendOrderSmsJob GenerateInvoicePdfJob SyncCustomerToCrmJob ProcessUploadedExcelJob

از Jobهای خیلی کلی مثل ProcessDataJob یا HandleEverythingJob پرهیز کنید.

2. منطق کسب‌وکار را در Service نگه دارید

Job باید اجرای پس‌زمینه را مدیریت کند، نه اینکه تمام منطق کسب‌وکار را در خود نگه دارد.

3. Queueهای جدا تعریف کنید

برای کارهای مختلف صف‌های متفاوت بسازید:

high default emails sms reports integrations low

4. Retry و Backoff مناسب تنظیم کنید

برای Jobهای وابسته به API خارجی، Retry منطقی و Backoff مرحله‌ای تعریف کنید.

5. Failed Jobها را جدی بگیرید

Failed Job فقط یک خطای فنی نیست. ممکن است به معنی ارسال نشدن پیامک، Sync نشدن سفارش یا تولید نشدن فاکتور باشد.

6. در Production از مانیتورینگ استفاده کنید

اگر Redis Queue دارید، Laravel Horizon گزینه بسیار مناسبی است. برای Database Queue هم باید Log، Alert و بررسی Failed Jobs داشته باشید.

7. Workerها را با Process Manager اجرا کنید

اجرای دستی php artisan queue:work برای Production کافی نیست. باید از ابزارهای پایدارسازی Process استفاده شود.

8. Jobها را Idempotent طراحی کنید

یعنی اگر Job دوبار اجرا شد، نتیجه خراب نشود. مثلاً اگر Job ساخت فاکتور دوبار اجرا شود، نباید دو فاکتور تکراری بسازد.

9. Timeout را تنظیم کنید

برای Jobهای سنگین، زمان اجرای مناسب تعیین کنید و نگذارید Job بی‌نهایت اجرا شود.

10. داده حساس را مستقیم در Job ذخیره نکنید

بهتر است اطلاعات حساس یا حجیم را مستقیم در Payload صف قرار ندهید. در بسیاری از موارد، ارسال ID و خواندن داده از دیتابیس بهتر است.

امنیت در Job و Queue

Queue هم مثل سایر بخش‌های نرم‌افزار نیاز به رعایت امنیت دارد.

داده‌های حساس را در Payload صف قرار ندهید

Payload Queue ممکن است در دیتابیس، Redis یا سرویس خارجی ذخیره شود. بنابراین نباید رمز عبور، Token حساس یا اطلاعات محرمانه غیرضروری داخل Job ذخیره شود.

ورودی Job را اعتبارسنجی کنید

اگر Job از داده‌های ورودی کاربر استفاده می‌کند، بهتر است قبل از Dispatch داده اعتبارسنجی شده باشد؛ مثلاً با Form Request.

سطح دسترسی را در لحظه مناسب بررسی کنید

اگر Job قرار است عملیاتی حساس انجام دهد، باید مطمئن شوید کاربر یا فرآیند مربوطه مجوز لازم را دارد. البته باید توجه کرد که اجرای Job ممکن است دیرتر از درخواست اصلی انجام شود و شرایط دسترسی تغییر کرده باشد.

خطاها را بدون افشای اطلاعات حساس لاگ کنید

Logها نباید شامل اطلاعات محرمانه کاربر، Tokenها یا داده‌های امنیتی باشند.

معماری پیشنهادی برای Queue در پروژه‌های Laravel

برای پروژه‌های متوسط و بزرگ، ساختار زیر می‌تواند مناسب باشد:

app/ ├── Jobs/ │   ├── Orders/ │   │   ├── GenerateInvoiceJob.php │   │   ├── SendOrderSmsJob.php │   │   └── SyncOrderWithAccountingJob.php │   ├── Reports/ │   │   └── GenerateSalesReportJob.php │   ├── Integrations/ │   │   └── SyncCustomerToCrmJob.php │   └── Notifications/ │       └── SendBulkSmsJob.php ├── Services/ │   ├── Order/ │   ├── Invoice/ │   ├── Report/ │   └── Integration/

این پوشه‌بندی باعث می‌شود Jobها با دامنه کسب‌وکار دسته‌بندی شوند و پروژه در طول زمان قابل نگهداری‌تر بماند.

Queue در پروژه‌های API، موبایل و SPA

در پروژه‌های API محور، اپلیکیشن موبایل یا Frontendهای React و Vue، Queue اهمیت زیادی دارد. کاربر در اپلیکیشن موبایل انتظار پاسخ سریع دارد. اگر Backend برای هر درخواست چند کار زمان‌بر انجام دهد، تجربه کاربری به‌شدت افت می‌کند.

سناریوهای مناسب Queue در API:

• ارسال کد تأیید
• ثبت Device Token
• ارسال Notification
• Sync داده با سرویس خارجی
• ساخت گزارش کاربر
• پردازش عکس پروفایل
• ارسال Webhook
• تولید خروجی PDF

در این نوع پروژه‌ها، API باید سبک، سریع و قابل اعتماد باشد. Queue کمک می‌کند کارهای جانبی از پاسخ اصلی جدا شوند.

Queue و طراحی نرم‌افزارهای مقیاس‌پذیر

در نرم‌افزارهای اختصاصی، رشد معمولاً تدریجی است. ابتدا شاید روزانه چند ده درخواست وجود داشته باشد، اما بعد از مدتی تعداد کاربران، سفارش‌ها، فایل‌ها، پیامک‌ها و گزارش‌ها چند برابر می‌شود. اگر از ابتدا همه پردازش‌ها در Request اصلی نوشته شده باشند، توسعه آینده پرهزینه خواهد شد.

Job و Queue در Laravel کمک می‌کند:

• پردازش‌ها مستقل‌تر شوند.
• ظرفیت پردازش قابل افزایش باشد.
• صف‌های مختلف برای کارهای مختلف تعریف شود.
• سیستم در برابر خطاهای موقت مقاوم‌تر باشد.
• تجربه کاربر حتی در زمان پردازش‌های سنگین حفظ شود.

اسمارتی اپ (SmartyApp) در طراحی نرم‌افزارهای تحت وب اختصاصی، Queue را یکی از ابزارهای مهم برای ساخت سامانه‌های سریع، قابل رشد و قابل نگهداری می‌داند؛ مخصوصاً در پروژه‌هایی که با گزارش‌گیری، پرداخت، پیامک، فایل، APIهای خارجی یا فرآیندهای سازمانی سروکار دارند.

چه زمانی نباید از Queue استفاده کنیم؟

هر کاری نیاز به Queue ندارد. استفاده بی‌دلیل از Queue می‌تواند پیچیدگی پروژه را بیشتر کند.

کارهای خیلی سریع و ساده

اگر کاری بسیار سریع و بدون وابستگی خارجی است، شاید اجرای مستقیم آن ساده‌تر باشد.

کارهایی که نتیجه آن فوراً لازم است

اگر پاسخ کاربر به نتیجه همان پردازش وابسته است، نمی‌توان آن را بدون طراحی مناسب به پس‌زمینه برد. مثلاً اگر کاربر باید همان لحظه نتیجه محاسبه قیمت را ببیند، آن محاسبه باید قبل از پاسخ انجام شود.

پروژه‌های بسیار کوچک و موقت

برای پروژه‌های کوچک، استفاده از Queue ممکن است در شروع ضروری نباشد. اما اگر پروژه قرار است رشد کند، بهتر است معماری از ابتدا قابلیت اضافه شدن Queue را داشته باشد.

اشتباهات رایج در استفاده از Job و Queue

1. فعال نکردن Worker

بسیاری از توسعه‌دهندگان Job را Dispatch می‌کنند، اما فراموش می‌کنند Worker باید اجرا شود.

2. استفاده از sync در Production

اگر QUEUE_CONNECTION=sync باشد، Jobها همان لحظه اجرا می‌شوند و عملاً پس‌زمینه‌ای وجود ندارد. این مقدار برای Development مناسب است، نه Production واقعی.

3. بی‌توجهی به Failed Jobs

اگر Failed Jobها بررسی نشوند، ممکن است خطاهای مهم کسب‌وکار پنهان بمانند.

4. قرار دادن منطق زیاد در Job

Job نباید به God Class تبدیل شود. بهتر است منطق اصلی در Service باشد.

5. نبود Queue Priority

اگر کارهای فوری و سنگین در یک صف باشند، پردازش‌های مهم ممکن است عقب بیفتند.

6. طراحی نکردن Retry

Jobهای وابسته به API خارجی بدون Retry و Backoff مناسب، در برابر خطاهای موقت ضعیف هستند.

7. نداشتن مانیتورینگ

Queue بدون نظارت مثل یک اتاق تاریک است. ممکن است خطا وجود داشته باشد، اما دیر متوجه شوید.

FAQ: سوالات متداول درباره Job و Queue در Laravel

1. Job در Laravel چیست؟

Job یک کلاس است که یک کار مشخص را انجام می‌دهد؛ مثل ارسال ایمیل، ارسال پیامک، پردازش فایل یا تولید گزارش. اگر Job رابط ShouldQueue را پیاده‌سازی کند، می‌تواند در صف اجرا شود.

2. Queue در Laravel چیست؟

Queue صفی برای نگهداری Jobهاست. Jobها به صف فرستاده می‌شوند و Workerها آن‌ها را در پس‌زمینه اجرا می‌کنند.

3. چرا باید از Queue استفاده کنیم؟

برای افزایش سرعت پاسخ‌گویی، جلوگیری از Timeout، مدیریت بهتر پردازش‌های سنگین، اجرای Retry و بهبود مقیاس‌پذیری نرم‌افزار.

4. آیا همه Jobها باید Queue شوند؟

خیر. فقط کارهای زمان‌بر، وابسته به سرویس خارجی، قابل تأخیر یا مناسب اجرای پس‌زمینه بهتر است Queue شوند.

5. Queue Worker چیست؟

Worker فرآیندی است که Jobها را از صف برمی‌دارد و اجرا می‌کند. بدون Worker، Jobهای صفی اجرا نمی‌شوند.

6. بهترین Queue Driver برای Laravel چیست؟

برای شروع، Database Driver ساده و مناسب است. برای پروژه‌های Production و پرترافیک، Redis معمولاً انتخاب حرفه‌ای‌تری است، مخصوصاً همراه با Laravel Horizon.

7. Laravel Horizon چیست؟

Horizon ابزار رسمی Laravel برای مانیتورینگ و مدیریت Queueهای Redis است. با آن می‌توان وضعیت Jobها، صف‌ها، Workerها و خطاها را مشاهده کرد.

8. Failed Job چیست؟

Failed Job کاری است که بعد از تعداد تلاش مجاز همچنان با خطا مواجه شده است. Laravel امکان مشاهده، اجرای مجدد و حذف Failed Jobها را فراهم می‌کند.

9. آیا Queue برای ارسال ایمیل مناسب است؟

بله. ارسال ایمیل یکی از رایج‌ترین کاربردهای Queue است، چون ارتباط با سرویس ایمیل ممکن است کند یا ناپایدار باشد.

10. آیا Queue برای پردازش فایل Excel مناسب است؟

بله. پردازش فایل‌های حجیم بهتر است در پس‌زمینه انجام شود تا Request اصلی دچار Timeout نشود.

11. تفاوت Job و Event چیست؟

Event نشان‌دهنده رخداد است، مثل ثبت سفارش. Job نماینده کاری است که باید اجرا شود، مثل ارسال پیامک سفارش. Listenerها می‌توانند بعد از Event اجرا شوند و خودشان Queue شوند.

12. آیا Queue باعث پیچیدگی پروژه می‌شود؟

اگر درست استفاده شود، پیچیدگی را مدیریت می‌کند. اما استفاده بی‌دلیل، نبود مانیتورینگ و طراحی نامناسب می‌تواند پروژه را سخت‌تر کند.

جمع‌بندی: Job و Queue در Laravel برای نرم‌افزارهای حرفه‌ای ضروری است

Job و Queue در Laravel یکی از ابزارهای کلیدی برای ساخت نرم‌افزارهای سریع، پایدار و قابل توسعه است. با استفاده از Queue می‌توان پردازش‌های زمان‌بر را از مسیر اصلی درخواست کاربر جدا کرد و تجربه کاربری بهتری ساخت.

ارسال ایمیل، ارسال پیامک، تولید فاکتور، پردازش فایل، ساخت گزارش، اتصال به APIهای خارجی، ارسال Webhook و اجرای عملیات زمان‌بندی‌شده نمونه‌هایی هستند که معمولاً بهتر است در پس‌زمینه اجرا شوند.

البته Queue باید با طراحی درست استفاده شود. Jobهای کوچک و مشخص، Service Layer تمیز، Retry و Backoff مناسب، Failed Job Management، مانیتورینگ و اولویت‌بندی صف‌ها از اصول مهم استفاده حرفه‌ای از Queue هستند.

برای کسب‌وکارهایی که نرم‌افزار اختصاصی، فروشگاه اینترنتی، CRM، ERP، سامانه رزرو، پلتفرم آموزشی یا محصول SaaS توسعه می‌دهند، توجه به معماری Queue از همان ابتدای پروژه می‌تواند هزینه توسعه آینده را کاهش دهد و کیفیت محصول را افزایش دهد.

اسمارتی اپ (SmartyApp) در طراحی سایت، تولید نرم‌افزار اختصاصی و برنامه‌نویسی نرم‌افزارهای تحت وب، استفاده از ابزارهایی مثل Job و Queue در Laravel را بخشی از مسیر ساخت نرم‌افزارهای سریع، قابل اعتماد و آماده رشد می‌داند.

CTA: برای طراحی نرم‌افزار تحت وب سریع و مقیاس‌پذیر مشاوره بگیرید

اگر نرم‌افزار شما با ارسال ایمیل، پیامک، گزارش‌گیری، پرداخت، پردازش فایل، اتصال به APIهای خارجی یا عملیات زمان‌بر سروکار دارد، احتمالاً به معماری درست Queue نیاز دارید.

طراحی نادرست پردازش‌های پس‌زمینه می‌تواند باعث کندی نرم‌افزار، خطاهای پنهان، فشار روی سرور و تجربه کاربری ضعیف شود. اما یک معماری حرفه‌ای با Job و Queue در Laravel می‌تواند نرم‌افزار شما را سریع‌تر، پایدارتر و آماده رشد کند.

برای بررسی نیازهای فنی پروژه، انتخاب معماری مناسب، طراحی پردازش‌های پس‌زمینه و دریافت مشاوره در زمینه تولید نرم‌افزارهای تحت وب، می‌توانید با تیم اسمارتی اپ (SmartyApp) تماس بگیرید و مسیر توسعه محصول خود را دقیق‌تر برنامه‌ریزی کنید.

منابع رسمی

1. مستندات رسمی Laravel درباره Queues
2. مستندات رسمی Laravel درباره Laravel Horizon
3. مستندات رسمی Laravel درباره Mail
4. مستندات رسمی Laravel درباره Task Scheduling
5. مستندات رسمی Laravel درباره Events
6. مستندات رسمی Laravel درباره Notifications
7. مستندات رسمی Laravel درباره Redis