תעמדו בתור!
למה בכלל
אז מה זה בכלל תור הודעות? ולמה זה רכיב? בואו נדמיין רגע מערכת שנתן לה שם רנדומלי, נניח אוגוסטוס. המערכת הזו מקבלת הודעות ומבצעת עליהם עיבוד שהוא די כבד, ולוקח נניח 10 שניות להודעה. אוגוסטוס מאוד פופולארית, והיא מקבלת בסביבות המליון בקשות לשעה. זה לא שהבקשות מאוזנות ואנחנו מקבלים אלף הודעות בכל שנייה, אלא מי ששולח לנו אותן די מחופרן, ממש ממז"ר, ויכול לשלוח חצי מליון בדקה ספציפית, ואת החצי מליון הנותרות בשאר השעה. המצב הזה מעלה כמה בעיות,
הבעיות
- טיימאווטים - בדקת הפיק הספציפית המערכות לא יעמדו בעומס, לא נגיע לחלק מהבקשות בזמן, והם יקבלו
Timeout. - קריסה - במידה ושרת כלשהו קורס, בין אם בגלל העומס או באופן כללי, כל הבקשות הממתינות לעיבוד באותו השרת ייפלו גם הם, מה שיכול למחוק חלק מהנתונים המתקבלים.
- ביזור עומסים - נניח ובשביל להתמודד עם פיק הבקשות אנחנו צריכים 19 שרתים שונים של אוגוסטוס, אחרי הפיק יהיו לנו עדיין את אותם ה19 שרתים שמתוכם אנחנו צריכים רק 3 כדי להתמודד עם העומס הרגיל. ו16 ישבו ככה בלי לעשות כלום.
הפתרון
הפתרון לכל הבעיות האלו הוא, שכל ההודעות יפסיקו להתנהג כמו הישראלי המצוי, ויעמדו בתור מסודר. ואנחנו נקח מהתור הודעות לפי הקצב שלנו.
למה זה יפתור את הכל?
- טיימאווטים - כשנשלח לתור, זה יהיה בתצורת שגר ושכח. כתוצאה מכך, אמנם מי ששלח את הבקשה לא ידע מה קרה איתה כמו ב
HTTPשזה חסרון, אך גם לא יחטוף טיימאווט כי המערכת לא הגיעה להודעה בזמן. - קריסה - ההודעות נמצאות בתוך התור ולא אל מול שרת, אז במידה ושרת כלשהו קורס הן נשמרות.
- ביזור עומסים - תורים מאפשרים לנו לבזר את העומסים לאורך זמן, וכך גם אם יש לנו פיק בדקה מסויימת, נוכל לגרור את עיבוד ההודעות למשך חמש דקות ולצמצם את השימוש במשאבים.
הסוגים
ישנם שני סוגים עיקריים של מנהלי תורי הודעות, מנהל מבוסס דיסק - למשל Kafka, ומנהל מבוסס ראם - למשל RabbitMQ.
נעבור על היתרונות והחסרונות של כל סוג.
לצפייה
אז לסיכום, נשתמש ב:
RabbitMQ- כאשר זה יהיה בסדר אם הודעות שלא נקראו יימחקו במידה והשירות ייפול. נרצה למקסם את התעבורה, וסדר ההודעות הנקראות לא משנה לנו.Kafka- כאשר נרצה שההודעות שלא נקראו ישמרו במידה והשירות ייפול, ואם אכפת לנו שסדר ההודעות הנקראות יהיה תואם לסדר הכניסה שלהן.
עכשיו, שאנחנו מבינים את ההבדלים הבסיסיים, נעמיק בכל אחד מהם.
קפקא
נבין איך קפקא, מבוסס הדיסק, עובד מבחינת המבנה הפנימי יותר לעומק, ואת פרקטיקת השימוש בו.
לצפייה
נסכם כמה נקודות,
- קפקא כותב את ההודעות על הדיסק, המתחלקות לפי תור -> פארטישן, ויכולות להיות רפליקייטד על כמה ברוקרים.
- את הלוגים כותבים פרודיוסרים, וצורכים קונסיומר גרופס, כך שכל פארטישן מקושר לקונסיומר אחד הצורך ממנו. כלומר, אם יש לי יותר פארטישנים מקונסיומרס קונסיומר אחד יקרא הודעות מכמה פארטישנים, אבל אם יש לי יותר קונסיומרס מפארטישנס, העודפים ישבו בפינה יבכו ולא יקראו כלום. ולכן כדאי לשים לב שיש לנו מספר פארטישנס מספק.
- ההודעות נשמרות גם לאחר שהן נקראות, לטווח זמנים מוגדר מראש.
ראביט
אופצייה למנהל תורים מבוסס זיכרון, הוא ראביט, נסקור את פרקטיקת השימוש בו.
לצפייה
אז ראביט בעצם בנוי בתצורה של אקסציינג'ים, המעבירים הודעות מהפרודיוסרים לתורים לפי מפתח מוגדר. ע"ב המפתח, ההודעה יכולה להיות מועברת לתור יחיד, מס תורים, או כלל התורים. מהתורים קוראים הקונסיומרים.
לאלו מביננו שלא מסתפקים בהשוואות תיאורטיות ורוצים פרקטיקה, להלן השוואת ביצועים בין קפקא לראביט.
לצפייה
רדיס
יוסי - "כל הקונסיומרים האלו, אקסציינג'ים, פארטישנים לא מבין מה אני צריך את כל זה אני רוצה פשוט לבנות שירות העברת הודעות פשוט, לא חללית."
יוסי, אתה צודק! יש פתרון הרבה יותר טוב אם נרצה מנהל תורים פשוט - רדיס.
יוסי - "מה רדיס הרגע אמרת שזה דיבי. תסגר על עצמך."
נכון נכון, זה אמנם דיבי, אבל הוא תומך בדאטא טייפ שמתאים לתור בשם List. שכבר הוזכר בסיכום על בסיסי הנתונים. כעת נראה ביותר מיקרו טקטיקה כיצד להשתמש ברשימות ברדיס כתור.
לצפייה
עוד משהו שרדיס יכול לשמש אותנו בו, הוא ליצור תור ממויין. לדוגמא, מה אם נרצה שההודעות מהתור לא ייקראו לפי סדר ההכנסה, אלא לפי דחיפות?
ניתן להשתמש בSorted Set ולשייך לכל הודעה ציון, וכך הקוראים מהתור יפרקו מהסט לפי הציון של ההודעה ולא לפי זמן הכניסה שלה. השימוש בכללי בו יראה כך, למרות שהסרטון לא מכוון לתור, ניתן לגזור ממנו כיצד לבנות אחד.
לצפייה
מנהלי התורים הללו הם עוד כלים לסט שלנו, ונדרש בכל סיטואציה של שימוש, להעריך את המתאים ביותר.
אין תגובות:
הוסף רשומת תגובה