חמישה סטודנטים ושלוש חנויות מפתח-ערך מבוזרות

או איך כתבנו ספריית לקוח C++ עבור ZooKeeper, etcd ו-Consul KV

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

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

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

הצלחנו ליצור ספרייה המספקת ממשק משותף לעבודה עם ZooKeeper, etcd ו-Consul KV. הספרייה כתובה ב-C++, אבל יש תוכניות להעביר אותה לשפות אחרות.

מודלים של נתונים

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

ZooKeeper

המפתחות מאורגנים בעץ ונקראים צמתים. בהתאם, עבור צומת אתה יכול לקבל רשימה של הילדים שלו. הפעולות של יצירת znode (create) ושינוי ערך (setData) מופרדות: ניתן לקרוא ולשנות רק מפתחות קיימים. ניתן לצרף שעונים לפעולות בדיקת קיומו של צומת, קריאת ערך וקבלת ילדים. Watch הוא טריגר חד פעמי המופעל כאשר הגרסה של הנתונים התואמים בשרת משתנה. צמתים ארעיים משמשים לאיתור כשלים. הם קשורים לסשן של הלקוח שיצר אותם. כאשר לקוח סוגר הפעלה או מפסיק להודיע ​​ל-ZooKeeper על קיומו, הצמתים הללו נמחקים באופן אוטומטי. עסקאות פשוטות נתמכות - קבוצה של פעולות שכולן מצליחות או נכשלות אם זה לא אפשרי עבור לפחות אחת מהן.

וכו '

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

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

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

קונסול K.V.

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

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

מחברים את הכל ביחד

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

• צמתי רצף, מיכל ו-TTL אינו נתמך
• רשימות ACL אינן נתמכות
• שיטת הסט יוצרת מפתח אם הוא לא קיים (ב-ZK setData מחזירה שגיאה במקרה זה)
• שיטות set ו-cas מופרדות (ב-ZK הן בעצם אותו דבר)
• שיטת המחיקה מוחקת צומת יחד עם תת העץ שלו (ב-ZK מחיקה מחזירה שגיאה אם ​​לצומת יש ילדים)
• לכל מפתח יש רק גרסה אחת - גרסת הערך (ב-ZK יש שלושה מהם)

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

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

דקויות של יישום

בואו נסתכל מקרוב על כמה היבטים של הטמעת ממשק הספרייה במערכות שונות.

היררכיה ב וכו'

שמירה על השקפה היררכית ב-etcd התבררה כאחת המשימות המעניינות ביותר. שאילתות טווח מקלות על אחזור רשימה של מפתחות עם קידומת מוגדרת. לדוגמה, אם אתה צריך כל מה שמתחיל עם "/foo", אתה מבקש טווח ["/foo", "/fop"). אבל זה יחזיר את כל המשנה של המפתח, מה שאולי לא יהיה מקובל אם תת העץ גדול. בהתחלה תכננו להשתמש במנגנון תרגום מרכזי, מיושם ב-zetcd. זה כולל הוספת בייט אחד בתחילת המפתח, שווה לעומק הצומת בעץ. תן לי לתת לך דוגמה.

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

אז קבל את כל הילדים המיידיים של המפתח "/foo" אפשרי על ידי בקשת טווח ["u02/foo/", "u02/foo0"). כן, ב-ASCII "0" עומד מיד אחרי "/".

אבל איך ליישם את הסרת קודקוד במקרה זה? מסתבר שצריך למחוק את כל הטווחים מהסוג ["uXX/foo/", "uXX/foo0") עבור XX מ-01 עד FF. ואז נתקלנו הגבלת מספר הפעולה בתוך עסקה אחת.

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

ואז למחוק את המפתח "/very" הופך למחיקה "/u00very" וטווח ["/very/", "/very0"), וקבלת כל הילדים - בבקשה למפתחות מהמטווח ["/very/u00", "/very/u01").

הסרת מפתח ב-ZooKeeper

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

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

מתרחש ב-ZooKeeper

ב-ZooKeeper ישנן שיטות נפרדות שעובדות עם מבנה העץ (create, delete, getChildren) ועובדות עם נתונים בצמתים (setData, getData) יתרה מכך, לכל השיטות יש תנאים מוקדמים קפדניים: create תחזיר שגיאה אם ​​הצומת כבר נוצר, מחק או setData - אם הוא עדיין לא קיים. היינו צריכים שיטה מוגדרת שאפשר לקרוא לה בלי לחשוב על נוכחות של מפתח.

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

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

פרטים טכניים נוספים

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

כבר מההתחלה ניסינו להשתמש בספריות מוכנות כדי לגשת לשירותים. במקרה של ZooKeeper, הבחירה נפלה על ZooKeeper C++, שבסופו של דבר לא הצליח להדר ב-Windows. עם זאת, זה לא מפתיע: הספרייה ממוקמת כלינוקס בלבד. עבור קונסול האפשרות היחידה הייתה ppconsul. היה צריך להוסיף לו תמיכה הפעלות и עסקאות. עבור etcd, ספרייה מלאה התומכת בגרסה העדכנית ביותר של הפרוטוקול לא נמצאה, אז אנחנו פשוט לקוח grpc שנוצר.

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

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

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

סך הכל

תראה בעצמך: liboffkv.

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

מקור: www.habr.com