הזרמת אירועים מול תורי הודעות - מה באמת ההבדל

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

תור הודעות קלאסי - הודעה שנעלמת אחרי שטופלה

בתור הודעות מסורתי, כמו RabbitMQ או Amazon SQS, ההודעה נועדה להיצרך פעם אחת. producer שולח הודעה לתור, consumer מושך אותה, מטפל בה, ומאשר שהוא סיים (acknowledge) - ואז ההודעה נמחקת מהתור. אם יש כמה consumers שמאזינים לאותו תור, כל הודעה מטופלת רק על ידי אחד מהם, בדרך כלל כדי לחלק עומס עבודה ביניהם.

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

הזרמת אירועים - יומן שנשאר, לא הודעה שנעלמת

Event Streaming, כפי ש-Kafka מממש אותו, בנוי אחרת לגמרי. אירועים לא נמחקים אחרי צריכה - הם נשמרים ביומן (log) מסודר לפי זמן, למשך תקופה מוגדרת (למשל שבוע או חודש). כל consumer שומר לעצמו "סימנייה" (offset) - עד איזה מקום ביומן הוא כבר קרא - ויכול לקרוא שוב את אותם אירועים בכל רגע, גם אם אירועים אחרים כבר נצרכו על ידי consumers אחרים.

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

ההבדל שבאמת קובע - עיבוד משימה מול היסטוריה של מה שקרה

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

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

מתי כל אחד מהם מתאים

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

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

המחיר של הזרמת אירועים

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

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

איפה לומדים להבדיל ביניהם בפועל

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

מתלבטים אם הפרויקט שלכם צריך תור הודעות פשוט או משהו כמו Kafka? שאלו בדיסקורד, לרוב התשובה פשוטה יותר ממה שנראה.

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

לסיכום

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