תור משימה ואיזון

1) מדוע תורים למשימה

• שייק פסגות: חוצץ בין החלק הקדמי ומערכות משנה כבדות.
• מייצב את SLA: סדרי עדיפויות ובידוד של כיתות עומס.
• מפשט סובלנות אשמה: מגשים מחדש, DLQ, היערכות מחדש.
• מאזניים אופקיים: הוסף עובדים מבלי לשנות את API.

תחומים טיפוסיים: עיבוד תשלומים, הודעות, דוח/מדיה דור, בדיקת דואר ETL/ML, אינטגרציה עם API חיצוני.

2) מודל ומושגים בסיסיים

מפיק: מפרסם את המשימה (pactore + metadata: idempotency key, עדיפות, מועד אחרון).
תור/נושא: buffer/log של משימות.
פועל: לוקח משימה, תהליכים, מאשר (ack) או חוזר עם שגיאה.
Recevity Timeout/Lease: ”שכירות” משימות למשך העיבוד, לאחר - אוטומטי-redelivery.
DLQ (תור אותיות מתות): משימות קבורה לאחר הגבול של ניסיונות/שגיאות קטלניות.
הגבלת קצב/קונקורנסי: לכל עובד/תור/לכל דייר מגבלות צריכה.

• משוך: העובד עצמו מבקש את המשימה (מנה את העומס).
• לדחוף: ברוקר פלופס; זקוק להגנה מפני ”מילוי” עובדים חלשים.

3) משלוח ואישור סמנטיקה

לכל היותר-פעם: אין מגשים מחדש; מהר יותר, אבל הפסד אפשרי.
לפחות פעם אחת (ברירת מחדל לרוב התורים): כפילויות הן אפשריות.
ביעילות בדיוק פעם אחת: הושג ברמת היישום (idempotency, dedup, transfactions/outbox). ברוקר יכול לעזור, אבל לא ”כדור קסם”.

• אק/נאק: תוצאה ברורה.
• Requeue/Retry: backback + jitter.
• הודעת רעל - שלח לדי-אל-קיו.

4) איזון ותכנון

4. רצף ואלגוריתמים 1

פשוט וצפוי.
תור עדיפות: כיתות עדיפות (P0... P3).
WRR/WSR (Round-Robin/Random): CPU חולק/transput בין המעמדות.
WFQ/DR (מקביל לתורים ”הוגנים” ברשתות): מניות לדייר/לקוח.
מועד אחרון/EDF: למשימות עם מועדים.
חלק הוגן: מגביל ”שכנים רועשים” (מכסות לכל דייר).

4. 2 זרימות עיבוד

מעוף אחד/פחם: תשכפל משימות מפתח.
Currency Caps: מגבלות קפדניות על מקביליות על ידי סוג משימה/אינטגרציה (API חיצוני).

4. 3 גיאו ושרדינג

Shards by key (terant/id) # locality of data, סדר יציב בתוך שברים.
מטמונים דביקים/משאבים: ניתוב חשיש לעובדים עם ”מצורף” מדינה.

5) רטריי, אחורה ו ־ DLQ

גיבוי מעריכי + jitter: ”base 2 ıtense night ready”.
ניסיונות מקסימליים ומועד אחרון (זמן למות) לכל משימה.
סיווג שגיאות: ”retryable” (רשת/הגבלה), ”non-restryable” (אימות/איסור עסקי).
תור חניה/עיכוב: משימות דחויות (לדוגמה, חזור אחרי 15 דקות).
מדיניות DLQ: יש לציין היכן ובאילו תנאים מקבל המסר ”הרעיל”; לספק מעבד מחדש.

6) אידמפוטנטיות ושכפול

• נצפה בדילוג/מיזוג/מטמון תוצאה.
• מפתחות טבעיים: השתמש ב- 'order _ id/ payment_id' במקום UUID אקראי.
• Outbox - רשום את העובדה של המשימה ואת מעמדו בעסקת מסד נתונים אחת עם עסקה עסקית.
• בדיוק-פעם אחת בכחול: 'UPSERT' על ידי מפתח, versioning, ”לפחות-פעם אחת” בתור + אידמפוטנטיות במסד הנתונים.

7) כיתות רב-שכבתיות ו ־ SLA

תורים/זרמים נפרדים לפי רמה: ”קריטי”, ”סטנדרטי”, ”גדול”.
מכסות וסדרי עדיפויות לדייר (זהב/כסף/ברונזה).
בידוד: להקדיש בריכות של עובדים תחת P0; רקע - באשכול/צמתים נפרדים.
בקרת כניסה: לא לקבל יותר ממה שאתה יכול לעבד במועדים.

8) עובדי סימון אוטומטי

מדדים למידה: עומק תור, קצב הגעה, זמן עיבוד, מועדי הגעה ל-SLA.
KEDA/Horizontal Pod Autoscaler: SQS/Rabbit/Kafka lag degress.
גורמי הרחקה: קצב חיצוני מגביל את API, מסד נתונים (לא להרוס את הקצה האחורי).

9) אפשרויות טכנולוגיה ודפוסים

9. 1 RabbitMQ/AMQP

החלפות: ישיר/נושא/פנוט; תורים על גבי תורים/ttl/DLQ (החלפת אותיות מתות).
Prefetch (QOS) מסדיר ”כמה משימות יש על הפועל”.

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.failed x-message-ttl=60000

9. 2 SQS (ואנלוגים)

Timeout Visibility, Second, Redriveveals Policy (DLQ).
Idempotence - על היישום (שולחן דידאפ).
גבולות: בוצ 'ס 1-10 הודעות; להתמקד בחבורות אידמפוטנטיות.

9. 3 קפקא/NATS JetStream

עבור צינורות בקנה מידה גדול: תפוקה גבוהה, שימור/שידור חוזר.
תור משימה מעל יומנים: משימה אחת = הודעה אחת; עובד אחד לכל בקרת מפתח דרך/נושא מחיצה.
רטריי: נושאים אישיים/נושאים-חופפים עם גיבוי.

9. 4 תורים של רדיס (Sidekiq/Resque/Bull/Celery-Redis)

איחור נמוך מאוד; שימו לב ליציבות (RDB/AOF), מפתחות מחדש ומפתחות מנעול לטיסה אחת.
מתאים למשימות ”אור”, לא להשבה לטווח ארוך.

9. 5 מסגרות

סלרי (פייתון), סיידקיק (רובי), RQ/BullMQ (Node), Huey/Resque - מגשים מוכנים, לוחות זמנים, תוכנות בינוניות, מטריצות.

10) ניתוב ואיזון מזימות

סיבוב-רובין: באופן שווה אבל לא לוקח בחשבון את ”חומרת” המשימות.
RR משוקלל: הפצה על ידי קיבולת עובדים/בריכה.
Fair/Backpressure מודע: העובד מרים משימה חדשה רק כאשר מוכן.
נתיבי עדיפות: תורים נפרדים לכל כיתה; העובדים קוראים לפי סדר [ P0. # Pn ] אם הוא זמין.
ניתוב: ”חשיש (מפתח)% רסיסים” - לעיבוד סטטוטורי/מטמון.

11) פסקי זמן, מועדים ותאריכי סל "ה

פר-משימת פסק זמן: ”חכירה” פנימית של העבודה (בקוד העובד) מציינת את זמן הראות של הברוקר.
תאריך יעד גלובלי: המשימה אינה הגיונית לאחר זמן T - NACK # DLQ.
תקציב מודע: הפחתת העבודה (brownout) כאשר המועד האחרון מתקרב (תוצאות חלקיות).

12) יכולת תצפית וניהול

12. 1 מדדים

'quue _ עומק', 'הגעה _ קצב', 'שירות _ קצב', 'לג' (קפקא), 'בלתי נראה _ הודעות' (SQS).
'הצלחה/כישלון/בדימוס/סה "כ', 'retry _ ניסיונות', 'diq _ in _ total', 'עיבוד _ time _ ms _ p50, p95, p99'.
'idepotency _ hit _ rate', 'dedup _ drops _ total', 'roison _ total'.

12. 2 יומנים/איתור

קורלציה: ”job _ id',” correlation _ id', dauplication key.
סימן 'retry/backoff/dlq' כאירועים; מקשר מהבקשה הראשונית.

12. 3 לוחות מחוונים/התראות

גורמים: עומק> X, p99> SLO, גידול DLQ, משימות תקועות (ראות שפגה> N), מפתחות חמים.

13) בטיחות וציות

בידוד דייר: תורים בודדים/מרחבי מפתח, ACLs, מכסות.
הצפנה על תחבורה ו/או ”במנוחה”.
מזעור PII במטען; חשיש/תעודת זהות במקום מח "ש גסה.
סודות: אל תשים אסימונים בגוף המשימה, השתמש בכספת/שיפוצים.

14) אנטי דפוסים

רטריי ללא אידמפוטנטיות * שכפול פעולות/כסף ”פעמיים”.
תור אחד ענק לכל דבר. אין בידוד, עיכובים בלתי צפויים.
רטריי אינסופי ללא DLQ * משימות נצחיות ”ארסיות”.
זמן ראות <זמן עיבוד = כפולים מפוספסים.
מטען גדול בתור # לחץ רשת/זיכרון; עדיף לאחסן בדוכן חפצים ולהעביר קישור.
לדחוף מודל ללא תרמילאים * עובדים נחנקים.
ערבוב משימות קריטיות ונפח במאגר אחד של עובדים.

15) רשימת מימושים

[ ] סיווג משימות על ידי SLA (P0/P1/P2) ונפח.

[ ] בחר ברוקר/מסגרת עם הסמנטיקה והשמירה הרצויה.

[ ] מפתחות עיצוב, סדר עדיפויות וניתוב (חשיש/רסיסים/נתיבי עדיפות).

[ ] אפשר גיבוי + ג 'יטר מגשים ומדיניות DLQ.

[ ] ליישם אידמפוטנטיות (מפתחות, עייפים, מתים עם TTL).

[ ] קבע את פר-משימה, ראות ופסקי זמן כלליים.

[ ] להגביל את הקונקרנסי וקצב על ידי אינטגרציה/דיירים.

[ ] עומק/לג אוטומטי עם נתיכים.

[ ] מטריצות/איתור/התראות; ספרים על ”סערה” ו-DLQ עולים על גדותיהם.

[ מבחני ] נכשלים: נפילת העובד, המסר ”הרעיל”, עומס יתר, משימות ארוכות.

16) תצורות וקוד לדוגמה

16. 1 סלרי (רדיס/ארנב) - זרימת בסיס

python app = Celery("jobs", broker="amqp://...", backend="redis://...")
app.conf.task_acks_late = True        # ack после выполнения app.conf.broker_transport_options = {"visibility_timeout": 3600}
app.conf.task_default_retry_delay = 5 app.conf.task_time_limit = 300        # hard timeout

@app.task(bind=True, autoretry_for=(Exception,), retry_backoff=True, retry_jitter=True, max_retries=6)
def process_order(self, order_id):
if seen(order_id): return "ok"      # идемпотентность do_work(order_id)
mark_seen(order_id)
return "ok"

16. 2 RabbitMQ - DLQ/TTL

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.dlq x-message-ttl=600000   # 10 минут x-max-priority=10

16. 3 קפקא - מגשים לפי רמה

orders -> orders.retry.5s -> orders.retry.1m -> orders.dlq

(העברה עם העברה מאוחרת באמצעות לוחות זמנים/קרון-צרכן.)

16. 4 NATS JetStream - גיבוי צרכני

bash nats consumer add JOBS WORKERS --filter "jobs.email" \
--deliver pull --ack explicit --max-deliver 6 \
--backoff "1s,5s,30s,2m,5m"

17) FAQ

ש: מתי לבחור דחיפה מול משיכה?
א. משיכה נותנת תרמיל גב טבעי ואיזון ”ישר”; דחיפה קלה יותר במהירויות נמוכות וכאשר יש צורך ב-TFB מינימלי, אבל דורשת מגבלות.

קיו: כיצד להימנע ממפתח חם? ‏

A: Shard by composite key ('order _ id% N'), buffer and batch-process, הזן גבולות לכל מפתח.

קיו: האם זה אפשרי ל ”פעם אחת בדיוק”?
א ": כמעט - באמצעות אידוי ותיבת עסקאות. באופן מלא ”מתמטי” בדיוק-פעם אחת הוא נדיר בר השגה ויקר כל הדרך.

ש: היכן לאחסן מצורפים משימות גדולות? ‏

A: באחסון אובייקטים (S3/GCS), ובמשימה - קישור/זיהוי; מפחית את הלחץ על הברוקר והרשת.

Q: כיצד לבחור את הראות/TTL?
A: Evisibility Westery p99 poxing time × stock 2-3 ×. משימות טי-טי-אל, פחות דד-ליין עסקי.

18) סיכומים

מערכת תורים חזקה היא איזון בין סמנטיקה מסירה, סדר עדיפויות, ואילוצים. עיצוב מפתחות וניתוב, הבטחת אידמפוטנטיות, מגש מחדש עם גיבוי ו-DLQ, הקצאת משאבים לשיעורי SLA וניטור מדדים. ואז תהליכי הרקע שלך יהיו צפויים, יציבים ומספקים - אין הפתעות מתחת לפסגות.