איך קפקא הפך למציאות

היי הבר!

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

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

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

משלוח מובטח ועוד

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

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

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0

אם אתה רוצה להשתמש ב-JMX באפליקציה עם קפקא, זו יכולה להיות בעיה. במקרה זה, עדיף להשתמש בשילוב של שם האפליקציה ובין, למשל, שם הנושא בתור הערך client.id. ניתן לראות את התוצאה של התצורה שלנו בפלט הפקודה קפקא-צרכנים-קבוצות משירותים מ-Confluent:

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

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

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

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

אנו מתקדמים לקראת משלוח פעם אחת בדיוק

ההגדרות המפורטות מאפשרות למפיק שלנו להעביר הודעות עם אחריות גבוהה. בואו נדבר כעת על איך להבטיח שרק עותק אחד של הודעה נכתב לנושא קפקא? במקרה הפשוט ביותר, כדי לעשות זאת, אתה צריך להגדיר את הפרמטר ב-Producer enable.idempotence לאמיתי. אימפוטנציה מבטיחה שרק הודעה אחת נכתבת למחיצה ספציפית של נושא אחד. התנאי המקדים לאפשר אי-דמוטנטיות הוא הערכים acks = all, נסה שוב > 0, max.in.flight.requests.per.connection ≤ 5. אם הפרמטרים האלה לא צוינו על ידי המפתח, הערכים לעיל יוגדרו אוטומטית.

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

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

כמו כן, שימוש במפתח ושליחה אימפוטנטית עם פרמטר max.in.flight.requests.per.connection = 1 נותן לך עיבוד הודעות יעיל עבור הצרכן. כדאי גם לזכור שאם בקרת גישה מוגדרת באשכול שלך, תזדקק להרשאות לכתוב בצורה אידימית לנושא.

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

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

org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.

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

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

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

אבל יש עוד ניואנס אחד. Transactional.id, אותו הגדרנו למעלה, היא למעשה קידומת העסקה. במנהל העסקאות מתווסף לו מספר רצף. המזהה שהתקבל מונפק ל transactional.id.expiration.ms, המוגדר על אשכול קפקא ויש לו ערך ברירת מחדל של "7 ימים". אם במהלך תקופה זו האפליקציה לא קיבלה הודעות כלשהן, כאשר תנסה את השליחה הבאה של העסקה תקבל InvalidPidMappingException. לאחר מכן, רכז העסקה יוציא מספר רצף חדש עבור העסקה הבאה. עם זאת, ההודעה עלולה ללכת לאיבוד אם ה-InvalidPidMappingException לא יטופל כהלכה.

במקום הסיכומים

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

הפקה:

1. acks = הכל
2. ניסיונות חוזרים > 0
3. enable.idempotence = true
4. max.in.flight.requests.per.connection ≤ 5 (1 לשליחה מסודרת)
5. transactional.id = ${application-name}-${hostname}

צרכן:

1. isolation.level = read_committed

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

הנה כמה חומרים ללימוד עצמי:

• KIP-98 - מסירה פעם אחת בדיוק והודעות עסקה
• תיאור ההגדרות

מקור: www.habr.com