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

בחירת טכנולוגיה

האם זה כל כך גרוע? נפרד Redis (Redis עצמאי) בתצורה של 1 מאסטר ו-N עבדים? למה אני קורא לזה טכנולוגיה מיושנת?

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

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

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

מהן האפשרויות?

• הפתרון היקר והעשיר ביותר הוא Redis-Enterprise. זהו פתרון באריזה עם תמיכה טכנית מלאה. למרות העובדה שהוא נראה אידיאלי מבחינה טכנית, הוא לא התאים לנו מסיבות אידיאולוגיות.
• Redis-cluster. מחוץ לקופסה יש תמיכה ב-Master Failover ו-Sharding. הממשק כמעט ואינו שונה מהגרסה הרגילה. זה נראה מבטיח, נדבר על המלכודות מאוחר יותר.
• Tarantool, Memcache, Aerospike ואחרים. כל הכלים האלה עושים כמעט אותו דבר. אבל לכל אחד יש חסרונות משלו. החלטנו לא לשים את כל הביצים שלנו בסל אחד. אנו משתמשים ב-Memcache וב-Tarantool עבור משימות אחרות, ובמבט קדימה, אני אגיד שבתרגול שלנו היו יותר בעיות איתם.

מפרט שימוש

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

• מטמון לפני בקשות לשירותים מרוחקים כמו 2GIS | גולנג
  

  GET SET MGET MSET "בחר DB"

• מטמון לפני MYSQL | PHP
  

  קבל הגדרה MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• האחסון העיקרי לשירות של עבודה עם הפעלות וקואורדינטות דרייברים | גולנג
  

  קבל הגדרה MGET MSET "בחר DB" "הוסף מפתח גיאוגרפי" "קבל מפתח גיאוגרפי" סריקה

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

שיטה
תיאור
תכונות של Redis-cluster
החלטה

הכן
מפתח כתיבה/קריאה

MGET MSET
כתוב/קרא מספר מקשים
המפתחות יהיו בצמתים שונים. ספריות מוכנות יכולות לבצע ריבוי פעולות רק בתוך צומת אחד
החלף את MGET בצינור של N GET פעולות

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

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

GEO
פעולות עם מפתח גיאוגרפי
המפתח הגיאוגרפי אינו מפורק

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

Redis לעומת Redis-cluster

מה אנחנו מפסידים ומה נרוויח במעבר לאשכול?

• חסרונות: אנו מאבדים את הפונקציונליות של מספר מסדי נתונים.
  • אם נרצה לאחסן נתונים לא קשורים מבחינה לוגית באשכול אחד, נצטרך ליצור קביים בצורה של קידומות.
  • אנו מאבדים את כל פעולות ה"בסיס", כגון SCAN, DBSIZE, CLEAR DB וכו'.
  • ריבוי פעולות הפכו להרבה יותר קשות ליישום מכיוון שהן עשויות לדרוש גישה למספר צמתים.
• יתרונות:
  • סובלנות תקלות בצורה של כשל ראשי.
  • שרדינג בצד של Redis.
  • העברת נתונים בין צמתים בצורה אטומית וללא זמן השבתה.
  • הוסף ופזר מחדש קיבולת ועומסים ללא זמן השבתה.

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

מתכוננים לזוז

נתחיל עם הדרישות למעבר דירה:

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

תחזוקת אשכול

רגע לפני המהלך, עלינו לחשוב אם נוכל לתמוך באשכול:

• תרשימים. אנו משתמשים ב-Prometheus ו-Grafana כדי לצייר גרף של עומס מעבד, שימוש בזיכרון, מספר לקוחות, מספר פעולות GET, SET, AUTH וכו'.
• מומחיות. תאר לעצמך שמחר יהיה לך אשכול ענק באחריותך. אם זה נשבר, אף אחד מלבדך לא יכול לתקן את זה. אם הוא יתחיל להאט, כולם ירוצו לקראתך. אם אתה צריך להוסיף משאבים או לפזר מחדש את העומס, חזור אליך. כדי לא להאפיר בגיל 25, רצוי לדאוג למקרים אלו ולבדוק מראש כיצד תתנהג הטכנולוגיה בפעולות מסוימות. בואו נדבר על זה ביתר פירוט בסעיף "מומחיות".
• ניטור והתראות. כאשר אשכול מתקלקל, אתה רוצה להיות הראשון לדעת על זה. כאן הגבלנו את עצמנו להתראה שכל הצמתים מחזירים את אותו מידע על מצב האשכול (כן, זה קורה אחרת). וניתן להבחין בבעיות אחרות מהר יותר על ידי התראות משירותי הלקוחות של Redis.

רילוקיישן

איך נעבור:

• קודם כל, אתה צריך להכין ספרייה לעבוד עם האשכול. לקחנו את go-redis כבסיס לגרסת הגו ושינינו אותה מעט כדי להתאים לעצמנו. הטמענו Multi-methods דרך צינורות, וגם תיקנו מעט את הכללים לבקשות חוזרות. לגרסת ה-PHP היו יותר בעיות, אבל בסופו של דבר הסתפקנו ב-php-redis. לאחרונה הם הציגו תמיכה באשכולות וזה נראה טוב לדעתנו.
• בשלב הבא עליך לפרוס את האשכול עצמו. זה נעשה פשוטו כמשמעו בשתי פקודות המבוססות על קובץ התצורה. נדון בהגדרה ביתר פירוט להלן.
• להזזה הדרגתית אנו משתמשים במצב יבש. מכיוון שיש לנו שתי גרסאות של הספרייה עם אותו ממשק (אחת לגרסה הרגילה, השנייה לאשכול), לא עולה כלום ליצור עטיפה שתעבוד עם גרסה נפרדת ובמקביל תשכפל את כל הבקשות לאשכול, השוו תגובות וכתבו אי התאמות ביומנים (במקרה שלנו ב-NewRelic). לפיכך, גם אם גרסת האשכול תתקלקל במהלך ההפצה, הייצור שלנו לא יושפע.
• לאחר שגלגלנו את האשכול במצב יבש, נוכל להסתכל בשלווה על גרף אי התאמות התגובה. אם שיעור השגיאות לאט אבל בטוח נע לעבר איזה קבוע קטן, אז הכל בסדר. למה עדיין יש פערים? מכיוון שהקלטה בגרסה נפרדת מתרחשת מעט מוקדם יותר מאשר באשכול, ובשל מיקרו-לאג, הנתונים עשויים להתפצל. כל שנותר הוא להסתכל על יומני אי ההתאמה, ואם כולם מוסברים על ידי אי האטומיות של הרשומה, אז נוכל להמשיך הלאה.
• עכשיו אתה יכול להחליף מצב יבש בכיוון ההפוך. נכתוב ונקרא מהאשכול, ונשכפל אותו לגרסה נפרדת. בשביל מה? במהלך השבוע הבא ארצה להתבונן בעבודת האשכול. אם פתאום מתברר שיש בעיות בעומס שיא, או שלא לקחנו משהו בחשבון, תמיד יש לנו חזרה חירום לקוד הישן ולנתונים העדכניים הודות ל-dry-mode.
• כל מה שנותר הוא להשבית את מצב יבש ולפרק את הגרסה הנפרדת.

מומחיות

ראשית, בקצרה על עיצוב האשכול.

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

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

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

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

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

• הדבר הראשון והחשוב ביותר שאנו צריכים הוא פעולת צמתי האשכולות. הוא מחזיר את מצב האשכול, מציג רשימה של צמתים, תפקידיהם, חלוקת משבצות וכו'. מידע נוסף ניתן לקבל באמצעות מידע אשכול וחריצי אשכול.
• זה יהיה נחמד להיות מסוגל להוסיף ולהסיר צמתים. לשם כך יש פעולות מפגש אשכול ואשכול לשכוח. שים לב שיש להחיל את ה-Cluster forget על כל צומת, גם מאסטרים וגם העתקים. ו-Cluster meet צריך להיקרא רק בצומת אחד. ההבדל הזה יכול להיות מטריד, אז עדיף ללמוד על זה לפני שאתה הולך לחיות עם האשכול שלך. הוספת צומת נעשית בצורה בטוחה בקרב ואינה משפיעה על פעולת האשכול בשום צורה (וזה הגיוני). אם אתה מתכוון להסיר צומת מהאשכול, עליך לוודא שלא נותרו בו חריצים (אחרת אתה מסתכן באובדן גישה לכל המפתחות בצומת זה). כמו כן, אל תמחק מאסטר שיש לו עבדים, אחרת תתבצע הצבעה מיותרת לאדון חדש. אם לצמתים אין יותר משבצות, אז זו בעיה קטנה, אבל למה אנחנו צריכים אפשרויות נוספות אם אנחנו יכולים למחוק את העבדים תחילה.
• אם אתה צריך להחליף בכוח את עמדות המאסטר והעבד, אז פקודת הכשל באשכול תתאים. כשקוראים לזה בקרב, אתה צריך להבין שהמאסטר לא יהיה זמין במהלך המבצע. בדרך כלל המעבר מתרחש תוך פחות משנייה, אך אינו אטומי. אתה יכול לצפות שבקשות מסוימות למאסטר ייכשלו במהלך הזמן הזה.
• לפני הסרת צומת מהאשכול, לא אמורים להישאר חריצים עליו. עדיף להפיץ אותם מחדש באמצעות הפקודה cluster reshard. חריצים יועברו ממאסטר אחד למשנהו. הפעולה כולה עשויה להימשך מספר דקות, תלוי בנפח הנתונים המועברים, אך תהליך ההעברה בטוח ואינו משפיע על פעולת האשכול בשום צורה. כך, ניתן להעביר את כל הנתונים מצומת אחד למשנהו ישירות בעומס, ומבלי לדאוג לזמינותם. עם זאת, יש גם דקויות. ראשית, העברת נתונים קשורה לעומס מסוים על צמתי הנמען והשולח. אם צומת הנמען כבר עמוס בכבדות על המעבד, אז אתה לא צריך לטעון אותו עם קבלת נתונים חדשים. שנית, ברגע שלא יישאר חריץ אחד על המאסטר השולח, כל העבדים שלו יעברו מיד אל המאסטר שאליו הועברו המשבצות הללו. והבעיה היא שכל העבדים האלה ירצו לסנכרן נתונים בבת אחת. ותהיה לך מזל אם זה יהיה סנכרון חלקי ולא מלא. קחו זאת בחשבון ושלבו את הפעולות של העברת חריצים והשבתה/העברת עבדים. או מקווה שיש לך מרווח ביטחון מספיק.
• מה עליך לעשות אם במהלך ההעברה אתה מגלה שאיבדת את המשבצות שלך איפשהו? אני מקווה שהבעיה הזו לא משפיעה עליך, אבל אם כן, ישנה פעולת תיקון אשכול. לכל הפחות, היא תפזר את החריצים על פני הצמתים בסדר אקראי. אני ממליץ לבדוק את פעולתו על ידי הסרת תחילה את הצומת עם חריצים מבוזרים מהאשכול. מכיוון שהנתונים במשבצות לא מוקצות כבר אינן זמינות, זה מאוחר מדי לדאוג לגבי בעיות בזמינות של חריצים אלה. בתורו, הפעולה לא תשפיע על משבצות מבוזרות.
• פעולה שימושית נוספת היא מוניטור. זה מאפשר לך לראות בזמן אמת את כל רשימת הבקשות שעוברות לצומת. יתר על כן, אתה יכול לתפוס אותו ולגלות אם יש את התעבורה הדרושה.

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

תְצוּרָה

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

• פסק זמן 0
  זמן שאחריו נסגרים חיבורים לא פעילים (בשניות). 0 - לא לסגור
  לא כל ספרייה שלנו הצליחה לסגור חיבורים בצורה נכונה. על ידי השבתת הגדרה זו, אנו מסתכנים בפגיעה במגבלה של מספר הלקוחות. מצד שני, אם יש בעיה כזו, אז סיום אוטומטי של חיבורים שאבדו יסווה אותה, וייתכן שלא נשים לב. בנוסף, אין להפעיל הגדרה זו בעת שימוש בחיבורים מתמשכים.
• שמור את xy ובתוספת כן
  שמירת תמונת RDB.
  נדון בנושאי RDB/AOF בפירוט להלן.
• stop-writes-on-bgsave-error no & slave-serve-stale-data כן
  אם מופעל, אם תמונת ה-RDB נשברת, המאסטר יפסיק לקבל בקשות שינוי. אם החיבור למאסטר אבד, העבד יכול להמשיך להגיב לבקשות (כן). או יפסיק להגיב (לא)
  אנחנו לא מרוצים מהמצב בו רדיס הופך לדלעת.
• repl-ping-slave-period 5
  לאחר פרק זמן זה, נתחיל לדאוג שהמאסטר התקלקל והגיע הזמן לבצע את הליך הכשל.
  תצטרך למצוא ידנית איזון בין תוצאות חיוביות שגויות לבין הפעלת כשל. בתרגול שלנו זה 5 שניות.
• repl-backlog-size 1024mb ו-epl-backlog-ttl 0
  אנחנו יכולים לאחסן בדיוק כל כך הרבה נתונים במאגר עבור העתק כושל. אם המאגר נגמר, תצטרך לסנכרן לחלוטין.
  התרגול מצביע על כך שעדיף להגדיר ערך גבוה יותר. יש הרבה סיבות מדוע העתק עשוי להתחיל לפגר. אם זה מפגר, סביר להניח שהמאסטר שלך כבר נאבק להתמודד, וסנכרון מלא יהיה הקש האחרון.
• maxclients 10000
  מספר מקסימלי של לקוחות חד פעמיים.
  מניסיוננו, עדיף להגדיר ערך גבוה יותר. Redis מתמודד עם 10k חיבורים בסדר גמור. רק וודא שיש מספיק שקעים במערכת.
• maxmemory-policy volatile-ttl
  הכלל לפיו מפתחות נמחקים כאשר מגיעים למגבלת הזיכרון הפנוי.
  מה שחשוב כאן הוא לא הכלל עצמו, אלא ההבנה איך זה יקרה. ניתן לשבח את Redis על יכולתו לעבוד כרגיל כאשר מגיעים למגבלת הזיכרון.

בעיות RDB ו-AOF

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

• RDB-snapshot - תמונת מצב מלאה של כל הנתונים. הגדר באמצעות תצורת SAVE XY וקורא "שמור תמונת מצב מלאה של כל הנתונים כל X שניות אם לפחות מקשי Y השתנו."
• קובץ הוספה בלבד - רשימה של פעולות לפי סדר ביצוען. מוסיף פעולות נכנסות חדשות לקובץ כל X שניות או כל Y פעולות.
• RDB ו-AOF הם שילוב של השניים הקודמים.

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

ראשית, שמירת תמונת RDB מחייבת קריאה ל- FORK. אם יש הרבה נתונים, זה יכול לתלות את כל Redis לתקופה של כמה אלפיות שניות עד שנייה. בנוסף, המערכת צריכה להקצות זיכרון לתמונת מצב כזו, מה שמוביל לצורך לשמור על אספקה ​​כפולה של זיכרון RAM במכונה הלוגית: אם מוקצים 8 ג'יגה-בייט ל-Redis, אז 16 ג'יגה-בייט אמורים להיות זמינים במחשב הווירטואלי עם זה.

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

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

מסקנה

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

מקור: www.habr.com