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

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

אורז. 1. ארבעה חלקים מחולקים בין שלושה מתווכים

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

כשל במחיצה

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

ברוקר 3 עוזב את הרשת, ומנהיג חדש נבחר לסעיף 2 בברוקר 2.

אורז. 2. ברוקר 3 נפטר ועוקבו בברוקר 2 נבחר למנהיג החדש של מחיצה 2

ואז ברוקר 1 עוזב וגם סעיף 1 מאבד את המנהיג שלו, שתפקידו עובר לברוקר 2.

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

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

אורז. 4. מנהיגים נשארים בברוקר 2

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

אורז. 5. מיקום לא מאוזן של מנהיגים לאחר שיקום המתווכים 1 ו-3

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

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

כדי לתקן זאת, קפקא מציע שתי אפשרויות:

• אפשרות auto.leader.rebalance.enable=true מאפשר לצומת הבקר להקצות מחדש את המנהיגים באופן אוטומטי להעתקים מועדפים ובכך לשחזר הפצה אחידה.
• המנהל יכול להריץ את הסקריפט kafka-preferred-replica-election.sh להקצאה מחדש ידנית.

אורז. 6. העתקים לאחר איזון מחדש

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

העתקים מסונכרנים (ISR)

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

עוקב מוסר מקבוצת ה-ISR אם הוא:

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

עוקבים מבצעים בקשות דגימה בפרק הזמן replica.fetch.wait.max.ms, אשר ברירת המחדל היא 500ms.

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

• acks=0, האישור לא נשלח
• acks=1, אישור נשלח לאחר שהמנהיג כתב הודעה ליומן המקומי שלו
• acks=all, אישור נשלח לאחר שכל העתקים ב-ISR כתבו את ההודעה ללוגים המקומיים

בטרמינולוגיה של קפקא, אם ה-ISR שמר הודעה, היא "מחויבת". Acks=all היא האפשרות הבטוחה ביותר, אך גם מוסיפה עיכוב נוסף. הבה נסתכל על שתי דוגמאות לכישלון וכיצד אפשרויות ה'acks' השונות מתקשרות עם מושג ה-ISR.

Acks=1 ו-ISR

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

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

אורז. 7. ISR עם שלושה העתקים

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

אורז. 8. הודעות אובדות כשהוא קורס

בתצורה bootstrap.servers ליצרן יש כמה מתווכים רשומים והוא יכול לשאול מתווך אחר מי הוא מוביל המדור החדש. לאחר מכן הוא יוצר חיבור לברוקר 1 וממשיך לשלוח הודעות.

אורז. 9. שליחת הודעות מתחדשת לאחר הפסקה קצרה

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

אורז. 10. עוקב בברוקר 3 מוסר מה-ISR

ברוקר 1 יורד ותפקיד המנהיגות עובר לברוקר 3 עם אובדן של 15286 הודעות! היצרן מקבל הודעת שגיאה בחיבור. המעבר למנהיג מחוץ לרשות היה אפשרי רק בשל המסגרת unclean.leader.election.enable=true. אם הוא מותקן ב שקר, אז המעבר לא יתרחש וכל בקשות הקריאה והכתיבה יידחו. במקרה זה, אנו מחכים שהברוקר 1 יחזור עם הנתונים שלו ללא פגע בהעתק, אשר ישתלט שוב ​​על ההנהגה.

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

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

אורז. 12. לאחר הפסקה קצרה נשלחות שוב הודעות לסעיף 0

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

Acks=all and ISR

בואו נחזור על התרחיש הזה שוב, אבל עם acks=הכל. לברוקר 3 יש חביון ממוצע של ארבע שניות. היצרן שולח הודעה עם acks=הכל, וכעת אינו מקבל מענה מהיר. המנהיג ממתין שההודעה תישמר על ידי כל ההעתקים ב-ISR.

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

לאחר ארבע שניות של עיכוב נוסף, ברוקר 2 שולח ack. כל ההעתקים מעודכנים כעת במלואם.

אורז. 14. כל העתקים שומרים הודעות ושולחים ack

ברוקר 3 נופל כעת יותר מאחור ומוסר מה-ISR. האחזור מופחת באופן משמעותי מכיוון שלא נותרו העתקים איטיים ב-ISR. ברוקר 2 ממתין כעת רק לברוקר 1, ויש לו פיגור ממוצע של 500 אלפיות השנייה.

אורז. 15. העתק על ברוקר 3 מוסר מה-ISR

ואז ברוקר 2 נופל והמנהיגות עוברת לבוקר 1 ללא אובדן הודעות.

אורז. 16. נופל ברוקר 2

היצרן מוצא מנהיג חדש ומתחיל לשלוח לו הודעות. ההשהיה מצטמצמת עוד יותר מכיוון שה-ISR מורכב כעת מעתק אחד! לכן האופציה acks=הכל לא מוסיף יתירות.

אורז. 17. העתק על ברוקר 1 לוקח את ההובלה מבלי לאבד הודעות

ואז ברוקר 1 קורס והפנייה עוברת לבוקר 3 עם אובדן של 14238 הודעות!

אורז. 18. ברוקר 1 מת ומעבר מנהיגות עם הגדרה לא נקייה מביא לאובדן נתונים נרחב

לא הצלחנו להתקין את האפשרות טמא.מנהיג.בחירות.לאפשר לתוך משמעות נָכוֹן. כברירת מחדל זה שווה שקר. הגדרות acks=הכל с unclean.leader.election.enable=true מספק נגישות עם אבטחת נתונים נוספת. אבל כפי שאתה יכול לראות, אנחנו עדיין יכולים לאבד הודעות.

אבל מה אם אנחנו רוצים להגביר את אבטחת המידע? אתה יכול לשים unclean.leader.election.enable = שקר, אבל זה לא בהכרח יגן עלינו מפני אובדן נתונים. אם המנהיג נפל חזק ולקח איתו את הנתונים, אז ההודעות עדיין אבודות, בנוסף הזמינות אובדת עד שמנהל המערכת ישחזר את המצב.

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

Acks=all, min.insync.replicas ו-ISR

עם תצורת נושא min.insync.replicas אנחנו מגבירים את רמת אבטחת המידע. בואו נעבור שוב על החלק האחרון של התרחיש הקודם, אבל הפעם עם min.insync.replicas=2.

אז לברוקר 2 יש מוביל העתק והעוקב בברוקר 3 מוסר מה-ISR.

אורז. 19. ISR משני העתקים

ברוקר 2 נופל והמנהיגות עוברת לברוקר 1 ללא אובדן הודעות. אבל כעת ה-ISR מורכב מעתק אחד בלבד. זה לא עומד במספר המינימלי לקבלת רשומות, ולכן המתווך מגיב לניסיון הכתיבה בשגיאה Not EnoughReplicas.

אורז. 20. מספר ה-ISRs נמוך באחד מהמצוין ב-min.insync.replicas

תצורה זו מקריבה זמינות למען עקביות. לפני שמאשרים הודעה, אנו מוודאים שהיא נכתבת לשתי העתקים לפחות. זה נותן ליצרן הרבה יותר ביטחון. כאן, אובדן הודעה אפשרי רק אם שני העתקים נכשלים בו זמנית בפרק זמן קצר עד שההודעה משוכפלת לעוקב נוסף, וזה לא סביר. אבל אם אתה סופר פרנואיד, אתה יכול להגדיר את מקדם השכפול ל-5, ו min.insync.replicas עד 3. כאן שלושה מתווכים חייבים ליפול בו זמנית כדי לאבד את השיא! כמובן, אתה משלם עבור מהימנות זו בהשהייה נוספת.

כאשר נגישות נחוצה לאבטחת מידע

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

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

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

המשמעות של ISR

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

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

RabbitMQ הוא פשוט סט של מראות שצריך לשכפל. מראות איטיות מציגות זמן השהייה נוסף, ומראות מתות יכולות להמתין עד שהמנות שבודקות את הזמינות של כל צומת (נטו טיק) להגיב. ISR היא דרך מעניינת להימנע מבעיות חביון אלו. אבל אנחנו מסתכנים באיבוד יתירות מכיוון שה-ISR יכול רק להתכווץ למנהיג. כדי למנוע סיכון זה, השתמש בהגדרה min.insync.replicas.

אחריות לחיבור לקוח

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

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

ארכיטקטורת קונצנזוס של קפקא

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

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

Zookeeper מאחסן את מצב האשכול:

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

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

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

עבור כל בקר מקטע:

• מעדכן מידע ב-Zookeeper על ISR ומנהיג;
• שולח LeaderAndISRCommand לכל ברוקר המארח העתק של מחיצה זו, ומודיע למתווכים על ISR והמנהיג.

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

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

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

אורז. 21. קונצנזוס קפקא

פרוטוקול שכפול

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

שאילתות דגימה, Offset Log End (LEO) ו-Highwater Mark (HW)

שקלנו שעוקבים שולחים מעת לעת בקשות אחזור למנהיג. מרווח ברירת המחדל הוא 500ms. זה שונה מ-RabbitMQ בכך שב-RabbitMQ שכפול לא יזום על ידי מראה התור אלא על ידי המאסטר. המאסטר דוחף שינויים למראות.

המנהיג וכל העוקבים שומרים את ה-Log End Offset (LEO) ואת התווית Highwater (HW). סימן LEO מאחסן את ההיסט של ההודעה האחרונה בהעתק המקומי, וה-HW מחזיק את ההיסט של ה-commit האחרון. זכור שלצורך סטטוס התחייבות, ההודעה חייבת להימשך בכל ההעתקים של ISR. המשמעות היא ש-LEO בדרך כלל מקדים מעט את HW.

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

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

כישלון מנהיג

כאשר מנהיג נופל, Zookeeper מודיע לבקר, והוא בוחר העתק מנהיג חדש. המנהיג החדש קובע תו HW חדש בהתאם ל-LEO שלו. לאחר מכן, העוקבים מקבלים מידע על המנהיג החדש. בהתאם לגרסה של קפקא, העוקב יבחר באחד משני תרחישים:

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

ייתכן שעוקב יצטרך לקצץ את היומן מהסיבות הבאות:

• כאשר מנהיג נכשל, העוקב הראשון בקבוצת ה-ISR הרשום ב-Zookeeper מנצח בבחירות והופך למנהיג. ייתכן שכל העוקבים ב-ISR, למרות שנחשבו "מסונכרנים", לא קיבלו עותקים של כל ההודעות מהמנהיג לשעבר. בהחלט ייתכן שלעוקב המוצג אין את העותק המעודכן ביותר. קפקא מבטיח שלא תהיה הבדל בין העתקים. לפיכך, כדי למנוע פערים, כל חסיד חייב לקצץ את היומן שלו לערך HW של המנהיג החדש בזמן בחירתו. זו סיבה נוספת למה הגדרה acks=הכל כל כך חשוב לעקביות.
• הודעות נכתבות מעת לעת לדיסק. אם כל צמתי האשכול נכשלים בו-זמנית, אזי יישמרו על הדיסקים העתקים עם היסטים שונים. ייתכן שכאשר מתווכים יחזרו לאינטרנט, המנהיג החדש שייבחר יהיה מאחורי העוקבים שלו כי הוא נשמר לדיסק לפני האחרים.

מפגש מחודש עם האשכול

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

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

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

אובדן קישוריות

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

להלן מספר תרחישי כשל בקישוריות:

• תרחיש 1: העוקב לא רואה את המנהיג, אבל עדיין רואה את שומר החיות.
• תרחיש 2: המנהיג לא רואה עוקבים, אבל עדיין רואה את Zookeeper.
• תרחיש 3: העוקב רואה את המנהיג, אבל לא רואה את שומר החיות.
• תרחיש 4: המנהיג רואה את העוקבים, אבל לא רואה את שומר החיות.
• תרחיש 5: העוקב נפרד לחלוטין מצמתי קפקא אחרים ומשומר גן החיות.
• תרחיש 6: המנהיג נפרד לחלוטין מצמתי קפקא אחרים ומשומר גן החיות.
• תרחיש 7: צומת הבקר של קפקא לא יכול לראות צומת קפקא אחר.
• תרחיש 8: בקר קפקא לא רואה את Zookeeper.

לכל תרחיש התנהגות משלו.

תרחיש 1: העוקב לא רואה את המנהיג, אבל עדיין רואה את Zookeeper

אורז. 22. תרחיש 1: ISR של שלושה העתקים

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

אורז. 23. תרחיש 1: הברוקר מוסר מה-ISR אם לא מתקבלת ממנו בקשת אחזור בתוך מרווח replica.lag.time.max.ms

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

תרחיש 2: מנהיג לא רואה עוקבים, אבל עדיין רואה את Zookeeper

אורז. 24. תרחיש 2. מנהיג ושני חסידים

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

אורז. 25. תרחיש 2. ISR הצטמק רק למנהיג

תרחיש 3. העוקב רואה את המנהיג, אך אינו רואה את שומר החיות

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

אורז. 26. תרחיש 3: העוקב ממשיך לשלוח בקשות אחזור למנהיג

תרחיש 4. מנהיג רואה עוקבים, אבל לא רואה את שומר גן החיות

אורז. 27. תרחיש 4. מנהיג ושני חסידים

המנהיג מופרד מ-Zookeeper, אבל לא מהברוקרים עם העוקבים.

אורז. 28. תרחיש 4: מנהיג מבודד מ- Zookeeper

לאחר זמן מה, Zookeeper ירשום כשל מתווך ויודיע על כך לבקר. הוא יבחר מנהיג חדש מבין חסידיו. עם זאת, המנהיג המקורי ימשיך לחשוב שהוא המנהיג וימשיך לקבל ערכים ממנו acks=1. העוקבים כבר לא שולחים לו בקשות אחזור, אז הוא יחשיב אותם כמתים וינסה לכווץ את ה-ISR לעצמו. אבל מכיוון שאין לו קשר ל-Zookeeper, הוא לא יוכל לעשות זאת, ובשלב זה יסרב לקבל ערכים נוספים.

Сообщения acks=הכל לא יקבל אישור כי ה-ISR מפעיל תחילה את כל ההעתקים, והודעות לא מגיעות אליהם. כאשר המנהיג המקורי ינסה להסיר אותם מה-ISR, הוא לא יוכל לעשות זאת ויפסיק לקבל הודעות כלל.

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

אורז. 29. תרחיש 4. המוביל בברוקר 1 הופך לעוקב לאחר שחזור הרשת

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

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

אורז. 30. תרחיש 5: עוקב מבודד מוסר מ-ISR

תרחיש 6: המנהיג נפרד לחלוטין מצמתי קפקא אחרים ומשומר גן החיות

אורז. 31. תרחיש 6. מנהיג ושני חסידים

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

אורז. 32. תרחיש 6: בידוד המנהיג מצמתים אחרים של קפקא ושומר גן החיות

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

בינתיים, Zookeeper יסמן את הברוקר המבודד כמת והבקר יבחר מנהיג חדש.

אורז. 33. תרחיש 6. שני מנהיגים

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

אורז. 34. תרחיש 6: היצרנים עוברים למנהיג חדש

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

אורז. 35. תרחיש 6: המנהיג המקורי הופך לעוקב לאחר שהקישוריות לרשת משוחזרת

במצב זה, הפרדה לוגית עלולה להתרחש לתקופה קצרה, אך רק אם acks=1 и min.insync.replicas גם 1. הפרדה לוגית מסתיימת אוטומטית או לאחר שחזור הרשת, כאשר המנהיג המקורי מבין שהוא כבר לא המנהיג, או כאשר כל הלקוחות מבינים שהמנהיג התחלף ומתחילים לכתוב למנהיג החדש - מה שיקרה קודם. בכל מקרה, חלק מההודעות יאבדו, אבל רק עם acks=1.

יש גרסה נוספת של התרחיש הזה, שבו, רגע לפני שהרשת התפצלה, העוקבים נקלעו לפיגור והמנהיג דחק את ה-ISR רק לעצמו. לאחר מכן הוא הופך מבודד עקב אובדן קישוריות. מנהיג חדש נבחר, אבל המנהיג המקורי ממשיך לקבל ערכים, אפילו acks=הכל, כי אין עוד איש ביש"ר חוץ ממנו. רשומות אלה יאבדו לאחר שחזור הרשת. הדרך היחידה להימנע מהאפשרות הזו היא min.insync.replicas = 2.

תרחיש 7: צומת בקר קפקא לא יכול לראות עוד צומת קפקא

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

תרחיש 8: בקר קפקא לא רואה את Zookeeper

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

מסקנות מהתרחישים

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

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

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

סיכום הודעות אבודות

בואו נפרט את כל הדרכים שבהן אתה יכול לאבד נתונים בקפקא:

• כל כשל במנהיג אם אושרו הודעות באמצעות acks=1
• כל מעבר טמא של הנהגה, כלומר לחסיד מחוץ לרשות, אפילו עם acks=הכל
• בידוד המנהיג מ-Zookeeper אם הודעות אושרו באמצעות acks=1
• בידוד מוחלט של המנהיג שכבר כיווץ את קבוצת ה-ISR לעצמו. כל ההודעות יאבדו, אפילו acks=הכל. זה נכון רק אם min.insync.replicas=1.
• כשלים בו זמנית של כל צמתי המחיצה. מכיוון שהודעות מאושרות מהזיכרון, ייתכן שחלקן עדיין לא נכתבו לדיסק. לאחר אתחול מחדש של השרתים, ייתכן שחלק מההודעות חסרות.

ניתן להימנע ממעברי מנהיגות לא טהורים על ידי איסור או הבטחת שתי פיטורים לפחות. התצורה העמידה ביותר היא שילוב acks=הכל и min.insync.replicas מעל 1.

השוואה ישירה של המהימנות של RabbitMQ וקפקא

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

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

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

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com