FastComments מוכן לחלל!

! מאמר זה כולל מושגים טכניים

מה חדש

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

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

קצת היסטוריה, למה השינוי

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

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

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

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

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

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

איך זה עובד

חלק מזה מכוסה בחלק הקודם, אבל TL;DR הוא שזה CRDT-lite. יצרנו פרוקסי (ב-Rust, כי כמובן) שנמצא בין האפליקציה ל-Mongo ועושה אותו רב-מאסטר. הפרוקסי מודע לעמיתים, מנהל צ'קפוינטים, שחזור, ניטור, וסנכרון ראשוני. זהו תחליף רב-מאסטר למערכת השכפול של Mongo, כולל עבור כמה פקודות DDL.

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

זהו פתרון ספציפי לדומיין. זה לא יעבוד עבור כל המוצרים. אפשר לומר שזה תכנון מונחה דומיין :). זה עובד לנו מכיוון desde שהתחלנו מאוד בזהירות רק $set את השדות שאנחנו משנים במסמכים - אנחנו אף פעם לא משתמשים ב-replaceOne של Mongo, לדוגמה. אותו דבר עם מונים. אתה לא עושה SET VOTES = 5. ולאחר מכן, היית כותב INCREMENT VOTES BY 5, מכיוון שזה מאפשר עקביות סופית. נעילות מופצות מנוהלות על ידי אל תעשה. רק צומת אחד לכל קבוצה יש דגל שכיוונו להריץ קרונס. על אף שזה עשוי להיראות מוגבל, אנחנו יכולים לקנות שרתים עם טרה-בייטים של RAM, כך שנוכל לקחת את הפשרה הזו כדי להפחית את הסיכון והמורכבות.

קריאה לכתיבות שלך

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

אתה יכול גם לקבע איזה point-of-presence אתה פוגע. מידע נוסף כאן.

בדיקות וההגירה

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

לסיכום ומה זה אומר עבורכם

FastComments אמור להיות עכשיו מהיר ועמיד יותר מאי פעם, ועכשיו אנו יכולים לחזור לעבודה על תכונות :)

להתראות!