Action Scheduler کتابخانه‌ای برای زمان‌بندی و اجرای کارهای پس‌زمینه در وردپرس است و ووکامرس و افزونه‌های زیادی از آن استفاده می‌کنند. ارسال webhook، پردازش ایمیل، تمدید، sync و پاک‌سازی می‌تواند به‌صورت action در صف قرار گیرد. بزرگ بودن عدد صف به‌تنهایی خطا نیست؛ وضعیت، سن، hook و سرعت ورود و خروج تعیین می‌کند آیا backlog واقعی دارید.
پاسخ کوتاه: هر action یک hook، زمان اجرا، وضعیت، گروه و آرگومان دارد. runner کارهای آماده را claim و اجرا می‌کند و نتیجه را ثبت می‌کند. اگر producer سریع‌تر از consumer action بسازد، cron اجرا نشود، callback خطا بدهد یا کارها طولانی باشند، صف رشد می‌کند. pendingها را بدون شناخت عملیات تجاری حذف نکنید.
چرا ووکامرس به صف نیاز دارد؟
برخی کارها لازم نیست پاسخ Checkout یا صفحه مدیریت را نگه دارند. صف اجازه می‌دهد عملیات بعداً، با retry و تاریخچه اجرا شود. این جداسازی latency کاربر را کم می‌کند، اما فقط وقتی runner منظم، actionها idempotent و خطاها قابل مشاهده باشند. انتقال هر عملیات به background بدون وضعیت و تضمین تحویل طراحی خوبی نیست.
اجزای اصلی یک Action
| جزء | معنا | کاربرد تشخیصی |
|---|---|---|
| Hook | نام کاری که باید اجرا شود | مالک افزونه و نوع عملیات |
| Arguments | ورودی callback | تشخیص نمونه و تکرار؛ ممکن است حساس باشد |
| Group | دسته منطقی actionها | تفکیک producerها |
| Scheduled date | زمان برنامه‌ریزی | محاسبه سن backlog |
| Status | مرحله چرخه اجرا | تفکیک انتظار، اجرا و شکست |
| Log | رخدادهای lifecycle | زمان claim، completion یا exception |
وضعیت‌ها چه می‌گویند؟
- Pending: برای آینده زمان‌بندی شده یا آماده اجراست.
- In-progress: توسط runner claim شده و در حال پردازش تلقی می‌شود.
- Complete: callback بدون خطای ثبت‌شده پایان یافته است.
- Failed: اجرا exception یا failure ثبت کرده است.
- Canceled: action لغو شده و نباید اجرا شود.
نام و جزئیات وضعیت ممکن است به نسخه رابط وابسته باشد. Complete بودن نیز موفقیت تجاری نهایی را همیشه ثابت نمی‌کند؛ callback شاید بدون exception تمام شود اما API خارجی نتیجه نامطلوب داده باشد.
Runner و Claim چگونه کار می‌کنند؟
runner مجموعه محدودی از actionهای آماده را claim می‌کند تا workerهای دیگر همان کار را هم‌زمان برندارند. سپس callbackها اجرا و وضعیت ثبت می‌شود. اگر process وسط batch متوقف شود، claim یا action در حال اجرا ممکن است نیازمند بازیابی طبق منطق نسخه باشد. حذف lock و claim به‌صورت دستی می‌تواند اجرای هم‌زمان بسازد.
رابطه با WP-Cron
Action Scheduler برای آغاز runner معمولاً به سازوکار زمان‌بندی وردپرس و درخواست‌های سایت متکی است، هرچند معماری hosting می‌تواند cron واقعی داشته باشد. اگر WP-Cron غیرفعال شده ولی جایگزین سیستم‌عامل درست اجرا نمی‌شود، action آماده می‌ماند. مقاله wp-cron و مصرف منابع تفاوت زمان‌بندی و اجرای job را توضیح می‌دهد.
چرا تعداد Complete زیاد می‌شود؟
فروشگاه پرتراکنش طبیعی است که تاریخچه complete زیادی تولید کند. مشکل اصلی می‌تواند retention/cleanup اجرا‌نشده باشد، نه backlog عملیاتی. سن قدیمی‌ترین complete و روند رشد را ببینید. پاک‌سازی باید از مکانیزم پشتیبانی‌شده و با توجه به نیاز audit انجام شود؛ truncate جدول تاریخچه مناسبی نیست.
چرا Pending زیاد می‌شود؟
- زمان اجرای آن‌ها هنوز نرسیده است.
- runner یا cron اجرا نمی‌شود.
- نرخ تولید از ظرفیت مصرف بیشتر است.
- یک hook کند یا قفل‌شده batch را عقب نگه می‌دارد.
- PHP، دیتابیس یا API خارجی اشباع است.
- افزونه معیوب action مشابه را پیوسته schedule می‌کند.
برای incident واقعی، راهنمای هزاران Scheduled Action در حالت Pending مسیر تشخیص مرحله‌ای دارد.
Failedها را چگونه بخوانیم؟
hook، exception، زمان و فراوانی را گروه‌بندی کنید. یک failure ناشی از داده حذف‌شده با هزاران timeout API فرق دارد. retry دستی بدون رفع علت می‌تواند فشار و side effect تکراری ایجاد کند. credential، payload، stock، payment و webhook ممکن است داده حساس داشته باشند؛ log را پیش از اشتراک‌گذاری redact کنید.
Recurring Action با Action تکراری فرق دارد
یک action recurring آگاهانه نمونه بعدی را در بازه مشخص schedule می‌کند. اما افزونه معیوب ممکن است در هر page load همان کار را دوباره بسازد. hook، args و فاصله زمانی را مقایسه کنید. حذف همه نمونه‌ها ممکن است تمدید یا sync لازم را متوقف کند؛ producer و قواعد uniqueness باید اصلاح شوند.
ترتیب و وابستگی عملیات
وجود صف به‌خودی‌خود ترتیب business را تضمین نمی‌کند. اگر action دوم به نتیجه اول وابسته است—برای نمونه sync سفارش پس از تأیید پرداخت—باید شرط وضعیت و رفتار retry روشن باشد. اجرای دستی actionهای عقب‌افتاده خارج از ترتیب می‌تواند داده مقصد را متناقض کند. timestamp تنها معیار وابستگی نیست؛ شناسه سفارش و state نیز باید بررسی شود.
برای کارهای مستقل concurrency مفید است، اما actionهای یک موجودیت ممکن است به قفل یا serialization نیاز داشته باشند. قفل باید timeout و بازیابی مشخص داشته باشد تا crash همه کارهای بعدی را متوقف نکند.
Idempotency چرا حیاتی است؟
runner، retry و failure شبکه می‌توانند callback را بیش از یک بار وارد کنند. عملیات حساس باید با شناسه یکتا و وضعیت فعلی بررسی شود تا موجودی، ایمیل، پرداخت یا webhook دوبار اعمال نشود. «فقط یک بار schedule کردن» به‌تنهایی تضمین نمی‌کند callback هرگز دوبار آغاز نشود.
صف چگونه روی سرعت اثر می‌گذارد؟
jobها با requestهای کاربر CPU، RAM، PHP worker، I/O و دیتابیس مشترک دارند. batch سنگین در ساعت فروش ممکن است Checkout را کند کند. از طرف دیگر کاهش بیش‌ازحد ظرفیت runner backlog را بزرگ می‌کند. concurrency و batch باید بر اساس مدت action، منابع و اولویت business تنظیم شوند.
یک مدل ساده ظرفیت
نرخ ورود action را با نرخ تکمیل در بازه یکسان مقایسه کنید. اگر در هر دقیقه ۱۰۰ action جدید و فقط ۶۰ مورد تکمیل می‌شود، backlog حتی بدون خطا رشد می‌کند. median و p95 مدت hook، نه فقط تعداد، ظرفیت لازم را نشان می‌دهد. گروه‌بندی بر اساس hook مشخص می‌کند یک producer غالب است یا کل سیستم کند شده.
مشاهده از پنل ووکامرس
بخش Scheduled Actions معمولاً امکان فیلتر وضعیت، hook، group و مشاهده log را می‌دهد. ابتدا read-only بررسی و نمونه‌ها را ثبت کنید. اجرای دستی یا cancel گروهی روی production یک عملیات تغییر‌دهنده است و باید اثر business آن مشخص باشد. از نمایش args حساس در screenshot عمومی خودداری کنید.
حریم خصوصی و امنیت داده صف
آرگومان action ممکن است شناسه مشتری، سفارش، URL webhook یا بخشی از payload را نگه دارد. secret و token نباید به‌عنوان آرگومان قابل مشاهده یا log ثبت شوند؛ reference محدود و بازیابی امن credential مناسب‌تر است. دسترسی پنل صف را نیز به نقش‌های لازم محدود کنید، زیرا اجرای دستی یک hook می‌تواند عملیات واقعی ایجاد کند.
WP-CLI و ابزار خط فرمان
قابلیت فرمان‌ها به نسخه Action Scheduler و افزونه‌های نصب‌شده وابسته است؛ قبل از اجرا help همان محیط را ببینید. فرمان‌های فهرست‌کردن برای inventory مفیدند، اما run/delete دسته‌ای می‌تواند بار ناگهانی یا حذف عملیات ایجاد کند. روی clone و با batch محدود آزمایش کنید.
مانیتورینگ درست صف
- تعداد pending آماده اجرا و سن قدیمی‌ترین مورد
- نرخ schedule و complete بر اساس hook
- failed rate و exception غالب
- مدت p50/p95 callbackها
- in-progress قدیمی و claimهای غیرعادی
- PHP queue، DB latency و API خارجی هم‌زمان
هشدار روی «تعداد کل رکورد» نویز زیادی دارد. صدها action برای آینده ممکن است طبیعی باشد، اما ده action حیاتی که دو ساعت از موعدشان گذشته‌اند مشکل مهمی است.
نگهداری امن
- مالک هر hook و اهمیت business را مستند کنید.
- retention complete/failed را تعریف کنید.
- runner و cron را با health check پایش کنید.
- callbackها را idempotent و دارای timeout معقول طراحی کنید.
- بار سنگین را زمان‌بندی و rate-limit کنید.
- پس از update، نرخ خطا و backlog را با baseline مقایسه کنید.
اشتباه‌های رایج
- حذف کل جداول Action Scheduler
- یکی دانستن complete history و pending backlog
- اجرای همه pendingها در یک batch بزرگ
- retry failedها بدون خواندن exception
- دستکاری claim و lock با SQL
- افزایش concurrency بدون ظرفیت PHP/MySQL
- نادیده گرفتن side effect پرداخت و موجودی
چه زمانی کمک تخصصی لازم است؟
اگر صف شامل پرداخت، subscription، موجودی یا sync ERP است و runner عقب افتاده، حذف یا اجرای دستی می‌تواند عملیات را دوبار انجام دهد. پشتیبانی فروشگاه ووکامرس می‌تواند hook، نرخ ورود/خروج، cron و منابع را تحلیل و بازیابی کنترل‌شده طراحی کند.
پرسش‌های متداول
آیا تعداد زیاد Scheduled Action طبیعی است؟
بسته به وضعیت و سن. future و complete history با pending عقب‌افتاده یکسان نیستند.
می‌توان همه Completeها را حذف کرد؟
retention و نیاز audit را بررسی و از cleanup پشتیبانی‌شده استفاده کنید؛ حذف مستقیم توصیه نمی‌شود.
چرا Action دوباره اجرا می‌شود؟
retry، callback تکراری یا producer چندباره ممکن است عامل باشد؛ idempotency callback نیز باید بررسی شود.
آیا Action Scheduler همان WP-Cron است؟
نه؛ صف و lifecycle خود را دارد، اما آغاز runner معمولاً با سازوکار cron وردپرس ارتباط دارد.