איך ולמה כתבנו שירות מדרגי בעומס גבוה עבור 1C: Enterprise: Java, PostgreSQL, Hazelcast

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

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

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

הצהרת הבעיה

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

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

פרדיגמת פיתוח שרת-לקוח

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

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

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

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

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

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

ההפקה עצמה

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

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

Реализация

החלטנו לא לשלב את חלק השרת של SV ישירות בפלטפורמת 1C:Enterprise, אלא ליישם אותו כמוצר נפרד, שניתן לקרוא ל-API שלו מהקוד של פתרונות אפליקציות 1C. זה נעשה ממספר סיבות, שהעיקרית שבהן הייתה שרציתי לאפשר להחליף הודעות בין אפליקציות 1C שונות (למשל בין Trade Management לחשבונאות). אפליקציות 1C שונות יכולות לפעול על גרסאות שונות של פלטפורמת 1C:Enterprise, להיות ממוקמות בשרתים שונים וכו'. בתנאים כאלה, יישום SV כמוצר נפרד הממוקם "בצד" של התקנות 1C הוא הפתרון האופטימלי.

אז החלטנו ליצור SV כמוצר נפרד. אנו ממליצים לחברות קטנות להשתמש בשרת ה-CB שהתקנו בענן שלנו (wss://1cdialog.com) כדי להימנע מהעלויות התקורות הקשורות להתקנה מקומית ותצורה של השרת. לקוחות גדולים עשויים למצוא שמומלץ להתקין שרת CB משלהם במתקנים שלהם. השתמשנו בגישה דומה במוצר SaaS בענן שלנו 1cFresh - הוא מיוצר כמוצר בייצור המוני להתקנה באתרי לקוחות, וגם נפרס בענן שלנו https://1cfresh.com/.

יישום

כדי להפיץ את סבילות העומס והתקלות, נפרוס לא יישום Java אחד, אלא כמה, עם מאזן עומסים לפניהם. אם אתה צריך להעביר הודעה מצומת לצומת, השתמש ב-publish/subscribe ב-Hazelcast.

התקשורת בין הלקוח לשרת היא באמצעות websocket. זה מתאים היטב למערכות בזמן אמת.

מטמון מבוזר

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

עבורנו, Hazelcast הוא:

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

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

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

בחירת DBMS

יש לנו ניסיון רב ומוצלח בעבודה עם PostgreSQL ושיתוף פעולה עם מפתחי ה-DBMS הזה.

זה לא קל עם אשכול PostgreSQL - יש XL, XC, ציטוס, אבל באופן כללי אלה לא NoSQLs שמתרחבים מהקופסה. לא התייחסנו ל-NoSQL כאחסון הראשי; זה היה מספיק שלקחנו את Hazelcast, שלא עבדנו איתו קודם לכן.

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

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

על ריבוי דיירים תוכלו לקרוא למשל באתר Citus Data.

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

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

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

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

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

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

Elasticsearch לחיפוש

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

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

[אלה, tek, tex, text, texts, ek, ex, ext, texts, ks, kst, ksty, st, sty, you],

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

התמונה הגדולה

חזרה על התמונה מתחילת המאמר, אך עם הסברים:

• מאזן שנחשף באינטרנט; יש לנו nginx, זה יכול להיות כל אחד.
• מופעי יישומי Java מתקשרים זה עם זה באמצעות Hazelcast.
• לעבודה עם שקע אינטרנט שאנו משתמשים בו Netty.
• אפליקציית Java כתובה ב-Java 8 ומורכבת מחבילות OSGi. התוכניות כוללות מעבר ל-Java 10 ומעבר למודולים.

פיתוח ובדיקות

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

בדיקת עומסים ודליפות זיכרון

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

• הבדיקה עבדה מספר ימים ולא היו תקלות שירות
• זמן התגובה לפעולות מפתח לא עלה על סף נוח
• הרעה בביצועים בהשוואה לגרסה הקודמת היא לא יותר מ-10%

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

אנו מבצעים בדיקות עומס של מערכת האינטראקציה בשלוש תצורות:

1. מבחן מאמץ
2. חיבורים בלבד
3. רישום מנוי

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

לדוגמה, כך נראה חלק ממבחן המאמץ:

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

  • צ'אט בוט נכנס למערכת (מדמה הודעות מקוד אפליקציה)
    • יש סיכוי של 50% ליצור ערוץ חדש להחלפת נתונים (דיון מיוחד)
    • סבירות של 50% לכתוב הודעה לכל אחד מהערוצים הקיימים

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

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

אנו משתמשים כמחולל עומסים JMeter. זה לא יודע איך לעבוד עם websocket; זה צריך תוסף. הראשונים בתוצאות החיפוש עבור השאילתה "jmeter websocket" הם: מאמרים מ- BlazeMeter, שממליצים תוסף מאת Maciej Zaleski.

שם החלטנו להתחיל.

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

התוסף הוא סיפור גדול נפרד; עם 176 כוכבים, יש לו 132 מזלגות ב-github. הכותב עצמו לא התחייב לזה מאז 2015 (לקחנו את זה ב-2015, אז זה לא עורר חשדות), כמה בעיות github בנוגע לדליפות זיכרון, 7 בקשות משיכה לא סגורות.
אם תחליט לבצע בדיקת עומס באמצעות תוסף זה, אנא שים לב לדיונים הבאים:

1. בסביבת ריבוי חוטים, נעשה שימוש ב-LinkedList רגיל, והתוצאה הייתה NPE בזמן ריצה. ניתן לפתור זאת על ידי מעבר ל-ConcurrentLinkedDeque או על ידי בלוקים מסונכרנים. בחרנו לעצמנו את האפשרות הראשונה (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. דליפת זיכרון; בעת ניתוק, פרטי החיבור לא נמחקים (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. במצב סטרימינג (כאשר ה-websocket אינו סגור בסוף הדגימה, אלא נעשה בו שימוש מאוחר יותר בתוכנית), דפוסי התגובה אינם פועלים (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

זה אחד מאלה ב-github. מה עשינו:

1. נלקח מזלג אלירן קוגן (@elyrank) - זה פותר בעיות 1 ו-3
2. נפתרה בעיה 2
3. המזח מעודכן מ-9.2.14 עד 9.3.12
4. עטוף SimpleDateFormat ב-ThreadLocal; SimpleDateFormat אינו בטוח בשרשור, מה שהוביל ל-NPE בזמן ריצה
5. תוקן דליפת זיכרון נוספת (החיבור נסגר בצורה שגויה בעת ניתוק)

ובכל זאת זה זורם!

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

עברו יומיים...

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

התברר שב-hazelcast 3.4, בעת מחיקת מפה / multiMap (map.destroy()), הזיכרון אינו משוחרר לחלוטין:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

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

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

שִׂיחָה:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

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

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

התרשימים השתפרו.

מה עוד למדנו על בדיקת עומס?

1. JSR223 צריך להיכתב בגרובי ולכלול מטמון קומפילציה - זה הרבה יותר מהיר. קשר.
2. קל יותר להבין גרפים של Jmeter-Plugins מאשר סטנדרטיים. קשר.

על הניסיון שלנו עם Hazelcast

Hazelcast היה מוצר חדש עבורנו, התחלנו לעבוד איתו מגרסה 3.4.1, כעת שרת הייצור שלנו פועל בגרסה 3.9.2 (בזמן כתיבת שורות אלו הגרסה העדכנית ביותר של Hazelcast היא 3.10).

הפקת תעודות זהות

התחלנו עם מזהים שלמים. בואו נדמיין שאנחנו צריכים עוד לונג לישות חדשה. רצף בבסיס הנתונים לא מתאים, הטבלאות מעורבות ברסיסים - מסתבר שיש הודעה ID=1 ב-DB1 והודעה ID=1 ב-DB2, אי אפשר לשים את ה-ID הזה ב- Elasticsearch, וגם לא ב-Hazelcast , אבל הדבר הגרוע ביותר הוא אם אתה רוצה לשלב את הנתונים משני מסדי נתונים לאחד (לדוגמה, להחליט שמסד נתונים אחד מספיק למנויים האלה). אתה יכול להוסיף מספר AtomicLongs ל-Hazelcast ולשמור את המונה שם, ואז הביצועים של השגת מזהה חדש הם incrementAndGet בתוספת הזמן לבקשה ל-Hazelcast. אבל ל-Hazelcast יש משהו אופטימלי יותר - FlakeIdGenerator. ביצירת קשר עם כל לקוח, הם מקבלים טווח תעודת זהות, למשל, הראשון - מ-1 עד 10, השני - מ-000 עד 10 וכן הלאה. כעת הלקוח יכול להנפיק מזהים חדשים בעצמו עד שהטווח שהונפק לו יסתיים. זה עובד מהר, אבל כשמפעילים מחדש את האפליקציה (ואת הלקוח Hazelcast), מתחיל רצף חדש - ומכאן הדילוגים וכו'. בנוסף, מפתחים לא ממש מבינים למה המזהים הם מספרים שלמים, אבל הם כל כך לא עקביים. שקלנו הכל ועברנו ל-UUID.

אגב, למי שרוצה להיות כמו טוויטר, יש ספריית Snowcast כזו - זו יישום של Snowflake על גבי Hazelcast. אתה יכול לצפות בו כאן:

github.com/noctarius/snowcast
github.com/twitter/snowflake

אבל לא הגענו לזה יותר.

TransactionalMap.replace

הפתעה נוספת: TransactionalMap.replace לא עובד. הנה מבחן:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

הייתי צריך לכתוב החלפה משלי באמצעות getForUpdate:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

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

הכנס JAR חדש ללא זמן השבתה

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

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

קרא:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

הכל עובד. ואז החלטנו לבנות אינדקס ב-Hazelcast לחיפוש לפי:

map.addIndex("subscriberId", false);

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

IMap. אנחנו כותבים 5000 חפצים, קוראים אותם. הכל צפוי.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

אבל זה לא עובד בעסקה, אנחנו מקבלים ClassNotFoundException:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

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

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

כיצד אנו מבטיחים ביצועים גבוהים

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

מעבר למטמון עבור נתונים הוא תמיד טוב יותר מאשר מעבר למסד הנתונים, אבל אתה גם לא רוצה לאחסן רשומות שאינן בשימוש. אנחנו משאירים את ההחלטה לגבי מה למטמון עד לשלב האחרון של הפיתוח. כאשר הפונקציונליות החדשה מקודדת, אנו מפעילים רישום של כל השאילתות ב-PostgreSQL (log_min_duration_statement ל-0) ומריצים בדיקות עומס למשך 20 דקות. באמצעות היומנים שנאספו, כלי עזר כמו pgFouine ו-pgBadger יכולים לבנות דוחות אנליטיים. בדוחות, אנו מחפשים בעיקר שאילתות איטיות ותכופות. עבור שאילתות איטיות, אנו בונים תוכנית ביצוע (EXPLAIN) ומעריכים האם ניתן להאיץ שאילתה כזו. בקשות תכופות עבור אותם נתוני קלט משתלבים היטב במטמון. אנו מנסים לשמור שאילתות "שטות", טבלה אחת לכל שאילתה.

ניצול

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

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

הפצת שרת SV מסופקת בצורה של חבילות מקוריות: RPM, DEB, MSI. בנוסף עבור Windows אנו מספקים מתקין יחיד בצורה של EXE יחיד שמתקין את השרת, Hazelcast ו- Elasticsearch על מכונה אחת. בתחילה התייחסנו לגרסה זו של ההתקנה כגרסת "הדגמה", אך כעת התברר כי זוהי אפשרות הפריסה הפופולרית ביותר.

מקור: www.habr.com