Sun Mar 29 2026

...

FastComments מוכנה לחלל!

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

מה חדש

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

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

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

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

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

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

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

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

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

איך זה עובד

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

ההבדל מכלים אחרים הוא שזה לא עוקב אחרי ה-oplog. מעקב אחרי ה-oplog, או שימוש בזרמי שינוי, לא יעבוד, מכיוון שהם רק מראים לך את המצב הסופי של האובייקט לאחר הכתיבה, مما يجعل من المستحيل التعامل مع הקונפליקטים. אתה צריך לתפוס כל פעולה $set, $inc ולשכפל את הפעולה עצמה.

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

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

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

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

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

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

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

לחיים!