"האדוופ. ZooKeeper" מסדרת Mail.Ru Group Technostream "שיטות לעיבוד מבוזר של כמויות גדולות של נתונים ב-Hadoop"

אני מציע לך לקרוא את תמליל ההרצאה "Hadoop. ZooKeeper" מתוך הסדרה "שיטות לעיבוד מבוזר של כמויות גדולות של נתונים ב-Hadoop"

מהו ZooKeeper, מקומו במערכת האקולוגית של Hadoop. חוסר אמיתות על מחשוב מבוזר. תרשים של מערכת מבוזרת סטנדרטית. קושי בתיאום מערכות מבוזרות. בעיות קואורדינציה אופייניות. העקרונות מאחורי העיצוב של ZooKeeper. מודל נתונים של ZooKeeper. דגלי znode. הפעלות. לקוח API. פרימיטיבים (תצורה, חברות בקבוצה, מנעולים פשוטים, בחירת מנהיג, נעילה ללא אפקט עדר). ארכיטקטורת ZooKeeper. ZooKeeper DB. ZAB. מטפל בבקשה.

היום נדבר על ZooKeeper. הדבר הזה מאוד שימושי. כמו לכל מוצר Apache Hadoop, יש לוגו. זה מתאר גבר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

והתכנית הזו (למעלה) כנראה מורכבת יותר, אבל אמינה יותר.

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

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

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

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

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

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

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

יש גם תצורה דינמית. אלו הם הפרמטרים שאנו רוצים לשנות תוך כדי כך שהם ייקלטו שם.

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

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

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

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

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

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

כל בקשות הלקוח מעובדות לפי סדר התור הכללי.

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

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

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

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

הלקוח הוא המשתמש המשתמש ב-ZooKeeper.

שרת הוא תהליך ZooKeeper עצמו.

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

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

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

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

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

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

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

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

זנוד רגיל. היא תמיד תחיה ויהיה לה את השם שאנחנו אומרים לה.

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

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

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

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

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

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

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

שלישית, הוא בודק את קיומו של זנוד. מחזירה true אם הצומת קיים, false אחרת.

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

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

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

יש גם SetData. כאן אנו מעבירים גרסה. ואם נעביר את זה הלאה, הנתונים על ה-znode של גרסה מסוימת יתעדכנו.

אתה יכול גם לציין "-1" כדי לא לכלול בדיקה זו.

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

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

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

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

שתי הפעולות שדיברנו עליהן הן עדכון/כתיבה, שמשנות נתונים. אלה הם create, setData, sync, delete. וקרא זה קיים, getData, getChildren.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ממה מורכב ZooKeeper? יש 4 דברים עיקריים. מדובר בתהליכי עיבוד - בקשה. וגם ZooKeeper Atomic Broadcast. ישנו Commit Log שבו כל הפעולות מתועדות. וה-In-memory Replicated DB עצמו, כלומר מסד הנתונים עצמו שבו מאוחסן כל העץ הזה.

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

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

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

ZooKeeper Atomic Broadcast הוא דבר המשמש לשמירה על נתונים משוכפלים.

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

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

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

מקור: www.habr.com