הבנת מתווכים בהודעות. לימוד המכניקה של העברת הודעות עם ActiveMQ וקפקא. פרק 3. קפקא

המשך תרגום של ספר קטן:
הבנת Message Brokers
מחבר: Jakub Korab, מו"ל: O'Reilly Media, Inc., תאריך פרסום: יוני 2017, ISBN: 9781492049296.

החלק המתורגם הקודם: הבנת מתווכים בהודעות. לימוד המכניקה של העברת הודעות עם ActiveMQ וקפקא. פרק 1 - מבוא

פרק 3

קפקא

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

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

• היה מהיר במיוחד
• ספק רוחב פס רב יותר בעת עבודה עם הודעות
• תמיכה במודלים של Publisher-Subscriber ו-Point-to-Point
• אל תאט את הקצב בהוספת צרכנים. לדוגמה, הביצועים של התור וגם של הנושא ב-ActiveMQ יורדים ככל שמספר הצרכנים ביעד גדל.
• להיות ניתן להרחבה אופקית; אם מתווך אחד שממשיך הודעות יכול לעשות זאת רק במהירות הדיסק המקסימלית, אז הגיוני ללכת מעבר למופע מתווך יחיד כדי להגביר את הביצועים
• הגבל את הגישה לאחסון ואחזור מחדש של הודעות

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

מודל יעד מאוחד

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

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

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

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

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

איור 3-1. מחיצות קפקא

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

קריאת הודעות

הלקוח שרוצה לקרוא את ההודעות מנהל מצביע בשם שנקרא קבוצת צרכנים, מה שמצביע על לְקַזֵז הודעות במחיצה. היסט הוא מיקום מצטבר שמתחיל ב-0 בתחילת מחיצה. קבוצת צרכנים זו, המוזכרת ב-API באמצעות group_id המוגדר על ידי המשתמש, תואמת צרכן או מערכת לוגית אחת.

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

בעיית הקריאה יכולה להיות מיוצגת באופן הבא:

• לנושא יש מספר מחיצות
• מספר קבוצות של צרכנים יכולות להשתמש בנושא בו-זמנית
• לקבוצת צרכנים יכולים להיות מספר מופעים נפרדים

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

צרכנים וקבוצות צרכנים

בואו ניקח כנקודת התחלה נושא עם מחיצה אחת (איור 3-2).

איור 3-2. הצרכן קורא ממחיצה

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

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

איור 3-3. שני צרכנים בקבוצות צרכנים שונות קוראים מאותה מחיצה

צרכנים בקבוצת צרכנים

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

איור 3-4. שני צרכנים באותה קבוצת צרכנים קוראים מאותה מחיצה

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

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

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

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

הדרך הקנונית לפתור בעיה זו בקפקא היא להשתמש ב-bОמחיצות נוספות.

מחיצה

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

איור 3-5. צרכן אחד קורא ממספר מחיצות

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

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

איור 3-6. שני צרכנים באותה קבוצת צרכנים קוראים ממחיצות שונות

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

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

כל שעל המתווך של קפקא לעשות הוא להעביר הודעות ברצף לצרכן כאשר האחרון מבקש אותן.

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

שולח הודעות

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

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

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

1. חשבון המשתמש מוגדר.
2. הכסף נזקף לחשבון.
3. מתבצע הימור שמושך כסף מהחשבון.

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

ממשק זה נראה כך:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

כתיבת אסטרטגיית חלוקה משלך

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

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

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

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

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

הסכמי מפיק

חלוקה למחיצות היא לא הדבר היחיד שיש לקחת בחשבון בעת ​​שליחת הודעות. בואו נסתכל על שיטות send() של מחלקת ה-Producer ב-Java API:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

עוד על קריאת הודעות

לקריאת הודעות יש מורכבויות נוספות שיש לשער לגביהן. בניגוד ל-JMS API, שיכול להפעיל מאזין הודעות בתגובה להודעה, ה צרכנות קפקא רק סקרים. בואו נסתכל מקרוב על השיטה מִשׁאָל()משמש למטרה זו:

ConsumerRecords < K, V > poll(long timeout);

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

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

כפי שאמרנו, קבוצת הצרכנים משויכת לקיזוז ביומן. מיקום היומן המשויך לקיזוז זה מתאים להודעה הבאה שתונפק בתגובה מִשׁאָל(). נקודת הזמן שבה הקיזוז הזה גדל היא הקובעת לקריאה.

אם נחזור למודל הקריאה שנדון קודם לכן, עיבוד ההודעות מורכב משלושה שלבים:

1. אחזר הודעה לקריאה.
2. עבד את ההודעה.
3. אשר את ההודעה.

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

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

בקפקא 0.10, קוד הלקוח שונה כך שה-commit מופעל מעת לעת על ידי ספריית הלקוח, כפי שהוגדרה auto.commit.interval.ms. התנהגות זו נמצאת איפשהו בין המצבים JMS AUTO_ACKNOWLEDGE ו-DUPS_OK_ACKNOWLEDGE. בעת שימוש ב-autocommit, הודעות יכולות להתבצע ללא קשר לשאלה אם הן עובדו בפועל - זה יכול לקרות במקרה של צרכן איטי. אם צרכן יבטל, הודעות יתקבלו על ידי הצרכן הבא, החל מהמיקום המחויב, מה שעלול לגרום להודעה שהוחמצה. במקרה הזה, קפקא לא איבד את ההודעות, קוד הקריאה פשוט לא עיבד אותן.

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

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

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

אתה יכול לשלוט בתהליך ההתחייבות הקיזוז הידני ב-Kafka לצרכן API על ידי הגדרת הפרמטר enable.auto.commit ל-false וקריאה מפורשת לאחת מהשיטות הבאות:

void commitSync();
void commitAsync();

אם ברצונך לעבד את ההודעה "לפחות פעם אחת", עליך לבצע את הקיזוז באופן ידני commitSync()על ידי ביצוע פקודה זו מיד לאחר עיבוד ההודעות.

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

• החזר אוטומטית לאחור של הודעה מזויפת. הצרכנים עצמם חייבים לטפל בחריגים הנובעים ממטענים בעייתיים והפסקות בקצה האחורי, מכיוון שהם אינם יכולים לסמוך על המתווך שימסור מחדש הודעות.
• שלח הודעות למספר נושאים בפעולה אטומית אחת. כפי שנראה בקרוב, השליטה על נושאים ומחיצות שונים יכולה להיות במכונות שונות באשכול קפקא שאינן מתאמתות עסקאות בעת שליחתן. בזמן כתיבת שורות אלה, נעשתה עבודה מסוימת כדי לאפשר זאת עם ה-KIP-98.
• שייך קריאת הודעה אחת מנושא אחד לשליחת הודעה אחרת לנושא אחר. שוב, הארכיטקטורה של קפקא תלויה במכונות עצמאיות רבות הפועלות כאוטובוס אחד ולא נעשה ניסיון להסתיר זאת. לדוגמה, אין רכיבי API שיאפשרו לך לקשר צרכן и מפיק בעסקה. ב-JMS, זה מסופק על ידי האובייקט מוֹשָׁבמהם נוצרים מפיקי הודעות и MessageConsumers.

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

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

שיטה לְחַפֵּשׂ() ניתן להשתמש בשיטה
offsetsForTimes(Map חותמות זמן לחיפוש) להריץ לאחור למצב בנקודה מסוימת בעבר.

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

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

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

זמינות גבוהה

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

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

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

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

במקרה הבסיסי, נוצר נושא באשכול קפקא עם המאפיינים הבאים:

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

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

בזמן ריצה עבור כל מחיצת נושא בקר להקצות תפקידים למתווך מַנהִיג (מנהיג, מאסטר, מנחה) ו עוקבים (חסידים, עבדים, כפופים). המתווך, המשמש כמוביל מחיצה זו, אחראי על קבלת כל ההודעות הנשלחות אליו על ידי היצרנים והפצת ההודעות לצרכנים. כאשר הודעות נשלחות למחיצת נושא, הן משוכפלות לכל צמתי המתווך הפועלים כעוקבים עבור אותה מחיצה. כל צומת המכיל יומנים עבור מחיצה נקרא הֶעתֵק מְדוּיָק. ברוקר יכול לשמש כמוביל עבור מחיצות מסוימות וכעוקב עבור אחרות.

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

חלק מתצורת היצרן הוא הפרמטר acks, שקובע כמה העתקים חייבים לאשר (לאשר) קבלה של הודעה לפני שרשור היישום ימשיך לשלוח: 0, 1 או כולם. אם מוגדר ל את כל, לאחר מכן כאשר מתקבלת הודעה, המנהיג ישלח אישור בחזרה למפיק ברגע שהוא יקבל אישורים (אישורים) על הרשומה ממספר רמזים (כולל עצמו) המוגדרים על ידי הגדרת הנושא min.insync.replicas (ברירת מחדל 1). אם לא ניתן לשכפל את ההודעה בהצלחה, המפיק יזרוק חריג יישום (Not EnoughReplicas או NotEnoughReplicasAfterAppend).

תצורה טיפוסית יוצרת נושא עם מקדם שכפול של 3 (מנהיג אחד, 1 עוקבים לכל מחיצה) והפרמטר min.insync.replicas מוגדר ל-2. במקרה זה, האשכול יאפשר לאחד מהברוקרים המנהלים את מחיצת הנושא לרדת מבלי להשפיע על יישומי הלקוח.

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

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

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

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

תוצאות של

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

החלק המתורגם הקודם: הבנת מתווכים בהודעות. לימוד המכניקה של העברת הודעות עם ActiveMQ וקפקא. פרק 1

התרגום נעשה: tele.gg/middle_java

להמשך ...

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם נעשה שימוש בקפקא בארגון שלך?

• כן

• לא

• היה בשימוש בעבר, עכשיו לא

• אנחנו מתכננים להשתמש

38 משתמשים הצביעו. 8 משתמשים נמנעו.

מקור: www.habr.com