איך בחרנו בספורטמאסטר מערכת מטמון. חלק 1

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

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

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

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

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

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

כאשר מתרחשת משימת שמירה במטמון

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

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

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

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

דרישות בסיסיות למערכת מטמון

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

בואו נשחק את התיק הזה.

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

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

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

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

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

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

ייסורי הבחירה

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

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

מה עשינו:

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

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

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

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

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

הרשימה אינה ממצה, ישנן עשרות מערכות. ואנחנו נדפק רק דבר אחד. בואו ניקח את 5 המערכות הנבחרות ל"תחרות היופי" ונבחר. מי יהיה המנצח?

Redis

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

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

EhCache

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

Redis נשכח, אני מוכן לבחור ב-EhCache.

אבל תחושת פטריוטיות דוחפת אותי לראות מה טוב בטרנטול.

טרנטול

טרנטול - עונה על הכינוי "פלטפורמת שילוב נתונים בזמן אמת". זה נשמע מאוד מסובך, אז אנחנו קוראים את הדף בפירוט ומוצאים אמירה רועשת: "שומר 100% מהנתונים ב-RAM." זה אמור לעורר שאלות - אחרי הכל, יכולים להיות הרבה יותר נתונים מזיכרון. ההסבר הוא שזה אומר ש-Tarantool לא מריץ סדרה כדי לכתוב נתונים לדיסק מהזיכרון. במקום זאת, הוא משתמש בתכונות ברמה נמוכה של המערכת, כאשר הזיכרון פשוט ממופה למערכת קבצים עם ביצועי I/O טובים מאוד. בכלל, הם עשו משהו נפלא ומגניב.

בואו נסתכל על ההטמעות: Mail.ru Corporate Highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

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

אבל בכל מקרה…

להצית

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

יישום: Sberbank, American Airlines, Yahoo! יפן. ואז אני מגלה ש-Ignite לא מיושם רק ב-Sberbank, אלא שצוות SberTech שולח את אנשיו לצוות Ignite עצמו כדי לחדד את המוצר. זה לגמרי שובה לב ואני מוכן לקחת את Ignite.

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

לוז

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

זהו, אני מוכן לקחת את הייזלקאסט.

השוואה

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

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

כאן הם ממוינים: Redis נמצא בפסגה, Hazelcast במקום השני, Tarantool ו-Ignite צוברים פופולריות, EhCache היה ונשאר אותו הדבר.

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

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

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

Hz נגד Redis

אנחנו מוצאים את זה השוואה:


כחול זה Redis, אדום זה Hazelcast. Hazelcast מנצח בכל מקום, ויש לכך רציונל: הוא מרובה הליכי, מותאם מאוד, כל שרשור עובד עם מחיצה משלו, כך שאין חסימה. ו- Redis הוא חוט יחיד; הוא אינו נהנה ממעבדים מרובים ליבות מודרניים. ל- Hazelcast יש I/O אסינכרוני, ל- Redis-Jedis יש שקעים חוסמים. אחרי הכל, Hazelcast משתמשת בפרוטוקול בינארי, ו-Redis מתמקד בטקסט, כלומר הוא לא יעיל.

ליתר בטחון, בואו נפנה למקור אחר להשוואה. מה הוא יראה לנו?

Redis נגד Hz

אחרת השוואה:


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

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

מנער את הבקבוק

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

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

שיטה זו מוסברת היטב בדוגמה זו.

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

יש שיטה כזו, מאוד מהירה ומאוד יעילה.

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

אנחנו מראים משהו זה למישהו: "סריוגה, אתה מבין!?" ואכן, מרחוק זה נראה כמו ספינה. אבל אי אפשר לתת לזה להימשך.

יש דרך אחרת. הם משמשים בחורים מתקדמים יותר, כמו האקרים.

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

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

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

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

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

איפה לחפש צוואר בקבוק

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

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

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

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

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

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

לוז

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

על מנת לשים/לקחת נתונים מ-Hazelcast, קוד הלקוח ניגש (1) ל-API. Hz מאפשר לך להריץ את השרת כמוטמע, ובמקרה זה, הגישה ל-API היא קריאת מתודה בתוך ה-JVM, שיכולה להיחשב בחינם.

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

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

מה ניתן לעשות בתנאים כאלה כדי להגביר את המהירות?

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

עבור פיתול ברמה (6), הרץ מציע שני סוגי אחסון: IMap ו- ReplicatedMap.


ראוי להזכיר כיצד Hazelcast נכנסה לערימת הטכנולוגיה של Sportmaster.

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

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

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

עבור כל הדרישות הללו, Hazelcast בהחלט מתאים לחשבון.

המשך יבוא

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

בינתיים... קוד חדש שמח!

מקור: www.habr.com