BullMQ ותורי עבודה (Queue Workers) ב-Node.js

מאת צוות מדיה דיל · 04.09.2026 · טכנולוגיה · 6 דק׳

Producer/Queue/Worker, Retries עם Backoff, Dead Letter Queue, Concurrency ו-Rate Limiting, אידמפוטנטיות, ומתי BullMQ מספיק ומתי צריך Kafka.

שליחת מייל, יצירת PDF כבד, או קריאה ל-API חיצוני איטי בתוך ה-Request-Response הרגיל של השרת הופכת כל בקשה כזו לצוואר בקבוק — המשתמש מחכה, וכל תקלה זמנית אצל הספק החיצוני הופכת לשגיאה שהוא רואה ישירות. BullMQ פותר את זה על ידי הפרדת "מה צריך לקרות" מ"מתי זה בפועל קורה", דרך תור עבודה שרץ על Redis.

המודל הבסיסי: Producer, Queue, Worker

Producer בקוד האפליקציה מוסיף Job לתור עם payload — נתונים שהעבודה צריכה כדי לרוץ. ה-Job נשמר ב-Redis, לא בזיכרון תהליך, כך שהוא שורד גם אם השרת שיצר אותו קורס לפני שהעבודה בוצעה. Worker נפרד — יכול לרוץ בתהליך אחר לגמרי, ואפילו בשרת אחר — מושך Jobs מהתור ומבצע אותם באופן אסינכרוני, בלי לחסום את התהליך שקיבל את הבקשה המקורית מהמשתמש.

Retries עם Backoff: כשל זמני לא צריך להיות כשל סופי

קריאה ל-API חיצוני שנכשלת בגלל עומס רגעי לא אמורה להפיל את כל התהליך. BullMQ תומך ב-Retries אוטומטיים עם מדיניות Backoff — לדוגמה Exponential, שבו כל ניסיון חוזר מחכה זמן ארוך יותר מהקודם, כדי לא להציף שירות שכבר עמוס. מספר הניסיונות המקסימלי והפער ביניהם מוגדרים ברמת ה-Job, כך שאפשר להתאים מדיניות שונה לפעולה קריטית (הזמנה) מול פעולה שאפשר לוותר עליה (התראה).

Dead Letter Queue: מה קורה כשגם ה-Retry האחרון נכשל

Job שמיצה את כל הניסיונות עובר למצב Failed ונשאר ניתן לבדיקה — לא נעלם בשקט. תבנית נפוצה היא להעביר Jobs כושלים לתור ייעודי (Dead Letter Queue) לבדיקה ידנית או ניתוח מרוכז, כדי להבין אם הכשל נקודתי או מצביע על בעיה מערכתית רחבה יותר, למשל ספק חיצוני שמחזיר שגיאות באופן עקבי.

Concurrency ו-Rate Limiting ברמת התור

אפשר להגדיר כמה Jobs Worker יכול לעבד במקביל, ולהגביל קצב עיבוד כולל של תור שלם — קריטי כשה-Jobs קוראים ל-API חיצוני עם הגבלת קצב משלו, כמו ספק סליקה או שירות שליחת מיילים. הגבלה כזו ברמת התור עצמו, בשילוב עם עקרונות Rate Limiting מלאים, מונעת חסימה מצד הספק החיצוני בגלל עומס רגעי מהתור.

Job Priority ו-Delayed Jobs

לא כל העבודות שוות: BullMQ תומך בסדר עדיפות שבו Job דחוף (למשל שליחת קוד אימות) מתעדף על פני עבודה שאפשר לדחות (עיבוד דוח שבועי). Delayed Jobs מאפשר לתזמן ביצוע עתידי — לשלוח תזכורת בעוד 24 שעות, למשל — בלי לבנות מנגנון Scheduler נפרד מאפס.

אידמפוטנטיות: הכרח, לא נחמד שיהיה

כשל ברשת יכול לגרום ל-Worker לעבד את אותו Job פעמיים — אולי הוא סיים בפועל אבל האישור ל-Redis לא הגיע בזמן. עיבוד חיוב כפול או שליחת מייל כפול הן תוצאות בלתי נסבלות, ולכן כל Job חייב להיות בנוי כך שביצוע חוזר לא יגרום נזק — עקרון שמפורט לעומק בIdempotency ב-API ותקף באותה מידה לעיבוד אסינכרוני.

BullMQ מול Message Queue מלא כמו Kafka

BullMQ מתאים למשימות רקע בתוך אפליקציה אחת או כמה שירותים קרובים, עם Redis שכבר קיים בתשתית. כשהצורך הוא זרם אירועים בין הרבה שירותים עצמאיים, שמירת היסטוריה ארוכת טווח, או Consumer Groups מרובים שקוראים את אותו נתון בקצב שונה — Kafka הוא הכלי הנכון. הבחירה הנכונה תלויה בהיקף ובמורכבות התקשורת בין השירותים, לא רק בעומס.

איפה BullMQ משתלב בארכיטקטורה מבוססת אירועים

תור עבודה הוא רכיב טבעי בארכיטקטורה מבוססת אירועים: בקשת HTTP יוצרת Job, ה-Job מטריגר עיבוד, וסיום העיבוד יכול לפרסם אירוע נוסף שמעורר תגובה נוספת במערכת. ראו ארכיטקטורה מבוססת אירועים להקשר הרחב יותר של דפוס זה ולמתי כדאי להרחיב אותו מעבר לתור עבודה בודד.

מתמודדים עם משימות רקע איטיות שתוקעות את הבקשות שלכם? נשמח לעזור לכם לבנות שכבת תורי עבודה נכונה בוואטסאפ.

תגיות: BullMQ · Queue Workers · Node.js · Redis · Background Jobs

← חזרה לבלוג · צור קשר