מבוא יסודי למערכות מבוזרות

מהי מערכת מבוזרת ומדוע היא כל כך מסובכת?

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

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

מהי מערכת מבוזרת?

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

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

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

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

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

מדוע להפיץ מערכת?

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

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

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

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

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

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

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

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

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

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

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

שינוי גודל המאגר שלנו

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

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

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

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

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

מזל טוב, כעת תוכל לבצע שאילתות קריאה פי 3! זה לא נהדר?

מִכשׁוֹל

Gotcha! איבדנו מיד את ה- C בערבונות ה- ACID של מאגר המידע היחסי שלנו , שמייצג עקביות.

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

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

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

ממשיכים בקנה מידה

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

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

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

בוא נלך עם טכניקה אחרת שנקראת sharding(נקרא גם מחיצה ).

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

גישה אפשרית לכך היא הגדרת טווחים על פי מידע כלשהו על רשומה (למשל משתמשים עם שם AD).

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

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

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

מִכשׁוֹל

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

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

מבוזר לעומת מבוזר

לפני שנמשיך הלאה ברצוני להבחין בין שני המונחים.

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

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

המשמעות היא שרוב המערכות שנעבור עליהן כיום יכולות להיחשב כמערכות ריכוזיות מבוזרות - וזה מה שהן מיועדות להיות.

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

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

קטגוריות מערכת מבוזרות

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

חנויות נתונים מבוזרות

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

קנה מידה ידוע - ידועה כי אפל משתמשת ב 75,000 צמתים של אפאצ'י קסנדרה המאחסנים מעל 10 פטה-בייטים של נתונים, עוד בשנת 2015

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

משפט CAP

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

כמה הגדרות מהירות:

• עקביות - מה שאתה קורא וכותב ברצף הוא מה שצפוי (זוכר את ה- gotcha עם שכפול מסד הנתונים לפני כמה פסקאות?)
• זמינות - המערכת כולה לא מתה - כל צומת שאינו כושל תמיד מחזיר תגובה.
• סובלנות למחיצות - המערכת ממשיכה לתפקד ולשמור על ערבויות העקביות / זמינות שלה למרות מחיצות רשת

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

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

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

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

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

מערכות אלו מספקות מאפייני BASE (בניגוד ל- ACID של מסדי נתונים מסורתיים)

• B asically A vailable - המערכת תמיד מחזירה תגובה
• S חוזר מדינה - המערכת יכולה להשתנות עם זמן, אפילו בתקופות של אי קליט (בשל עקביות סופית)
• E עקבית ventual - בהיעדר הקלט, נתון יתפשטו לכול צומת במוקדם או במאוחר - ובכך להפוך עקבי

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

כמובן שישנן חנויות נתונים אחרות שמעדיפות עקביות חזקה יותר - HBase, Couchbase, Redis, Zookeeper

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

קסנדרה

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

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

בעת הקריאה, תקרא מהצמתים האלה בלבד.

קסנדרה ניתנת להרחבה באופן מסיבי ומספקת תפוקת כתיבה גבוהה באופן אבסורדי.

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

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

קוֹנסֶנזוּס

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

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

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

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

מחשוב מבוזר

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

סולם ידוע - ל- Folding @ Home היו 160,000 מכונות פעילות בשנת 2012

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

MapReduce

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

בואו נסתדר עם דוגמה שוב:

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

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

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

זו פרדיגמה טובה ובאופן מפתיע מאפשרת לך לעשות הרבה עם זה - אתה יכול לשרשר מספר עבודות MapReduce למשל.

טכניקות טובות יותר

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

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

ככאלה נוצרו ארכיטקטורות אחרות העוסקות בסוגיות אלה. כלומר Lambda Architecture (שילוב של עיבוד אצווה ועיבוד זרמים) ו- Kappa Architecture (עיבוד זרם בלבד). ההתקדמות הללו בתחום הביאה כלים חדשים המאפשרים להם - זרמי קפקא, Apache Spark, Apache Storm, Apache Samza.

מערכות קבצים מבוזרות

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

קנה מידה ידוע - יאהו ידועה בהפעלת HDFS בלמעלה מ 42,000 צמתים לאחסון של 600 פטה בייטים של נתונים, כבר בשנת 201

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

HDFS

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

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

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

IPFS

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

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

היא עדיין עוברת פיתוח כבד (v0.4 נכון לכתיבת שורות אלה) אך כבר ראתה פרויקטים המעוניינים לבנות עליה (FileCoin).

מסרים מבוזרים

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

קנה מידה ידוע - אשכול קפקא של לינקדאין עיבד טריליון הודעות ביום עם שיאים של 4.5 מיליון הודעות בשנייה.

במילים פשוטות, פלטפורמת מסרים עובדת באופן הבא:

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

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

הצרכנים יכולים לשלוף מידע מהמתווכים (מודל משיכה) או שהמתווכים ידחפו מידע ישירות אל הצרכנים (מודל הדחיפה).

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

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

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

Apache ActiveMQ - הוותיק שבחבורה, משנת 2004. משתמש ב- JMS API, כלומר מיועד ליישומי Java EE. זה נכתב מחדש כ- ActiveMQ Artemis, המספק ביצועים יוצאי דופן בקנה אחד עם קפקא.

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

יישומים מבוזרים

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

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

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

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

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

סולם ידוע - נחיל BitTorrent של 193,000 צמתים לפרק של משחקי הכס, אפריל 2014

מכונת וירטואלית Erlang

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

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

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

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

BitTorrent

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

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

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

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

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

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

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

ספרים מבוזרים

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

סולם ידוע - רשת Ethereum השיגה 1.3 מיליון עסקאות ביום ב -4 בינואר 2018.

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

בלוקצ'יין

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

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

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

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

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

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

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

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

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

ביטקוין

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

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

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

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

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

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

את'ריום

ניתן לחשוב על Ethereum כפלטפורמת תוכנה מבוססת בלוקצ'יין. יש לה מטבע קריפטוגרפי משלה (Ether) שמזין פריסת חוזים חכמים בבלוקצ'יין שלה.

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

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

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

שימושים נוספים של פנקסים מבוזרים

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

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

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

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

סיכום

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

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

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

זְהִירוּת

תן לי להשאיר אותך עם אזהרת פרידה:

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

[1]

מאבק בהוצאות כפולות באמצעות מערכות P2P שיתופיות, 25-27 ביוני 2007 - פתרון מוצע שבו כל 'מטבע' יכול לפוג ומוקצה לו עד (תוקף) להוצאתו.

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

קריאה נוספת של מערכות מבוזרות:

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

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

Jepsen - בלוג המסביר על הרבה טכנולוגיות מבוזרות (ElasticSearch, Redis, MongoDB וכו ')

תודה שפנית לקרוא את המאמר הארוך הזה (~ 5600 מילים)!

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

~ סטניסלב קוזלובסקי

עדכון

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

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