RabbitMQ מוסבר- תורי הודעות מעבר לקפקה

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

למה בכלל צריך תור הודעות

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

איך RabbitMQ בפרט עושה את זה

RabbitMQ מיישם דפוס שנקרא message broker - הוא יושב באמצע, בין מי ששולח הודעות (producer) לבין מי שמקבל אותן (consumer), ומנהל את כל התהליך. החוזק המרכזי שלו הוא הגמישות בניתוב - הוא משתמש ברכיב שנקרא exchange, שיכול לנתב הודעות לתורים שונים לפי כללים מורכבים - לפי סוג ההודעה, לפי דפוס בשם, או פשוט לכולם בבת אחת. זה נותן שליטה עדינה מאוד על מי מקבל מה, בלי שהשירות ששולח את ההודעה בכלל צריך לדעת מי מאזין בצד השני.

RabbitMQ גם נותן אישור מפורש - כשsevice מטפל בהודעה בהצלחה, הוא שולח אישור, ורק אז ההודעה נמחקת מהתור. אם השירות נופל באמצע הטיפול, ההודעה חוזרת לתור ומחכה לניסיון נוסף. זה מבטיח שהודעה לעולם לא "פשוט נעלמת" בגלל תקלה זמנית.

אז מה ההבדל האמיתי מול Kafka

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

המשמעות המעשית - אם אתם בונים מערכת שצריכה לעבד אירועים בקנה מידה ענק, לשמור עליהם היסטוריה, או לבנות עליהם ניתוח בזמן אמת, Kafka הוא הכלי הנכון. אם אתם צריכים פשוט לתאם עבודה בין שירותים - "תריץ את זה ברקע", "תעדכן את זה כשמשהו קרה" - RabbitMQ לרוב פשוט יותר להתקין, להבין, ולתחזק.

מתי בכלל מתחילים לחשוב על תור הודעות

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

מאיפה ממשיכים מכאן

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

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

הצטרפו לקהילה בדיסקורד