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

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

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

פרויקט "חיוב מאוחד"

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

הגידול בפריון של ציוד Hi-End לא עמד בקצב הצמיחה של בסיס המנויים והגידול במספר השירותים; צמיחה נוספת במספר המנויים והשירותים הייתה צפויה עקב M2M, IoT ותכונות סניפים שהובילו להידרדרות בזמן היציאה לשוק. החברה החליטה ליצור מערכת עסקית מאוחדת עם ארכיטקטורה מודולרית ייחודית ברמה עולמית, במקום 8 מערכות חיוב שונות כיום.

MegaFon היא שמונה חברות באחת. בשנת 2009 הושלם הארגון מחדש: סניפים ברחבי רוסיה התמזגו לחברה אחת, MegaFon OJSC (כיום PJSC). לפיכך, לחברה 8 מערכות חיוב עם פתרונות "מותאם אישית" משלהן, תכונות סניפים ומבנים ארגוניים שונים, IT ושיווק.

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

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

קנה מידה אנכי. אפילו החומרה הכי מגניבה באותה תקופה לא ענתה על הצרכים. העבודה השתמשה בציוד Hewlett-Packard מקו Superdome Hi-End, אך הוא לא ענה על הצרכים של אפילו שני סניפים. רציתי קנה מידה אופקי ללא עלויות תפעול גדולות והשקעות הון.

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

אתגרים טכנולוגיים

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

מדרגיות

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

הפכנו להיות דומים בקנה מידה לנגני אינטרנט גדולים כמו Mail.ru או Netflix.

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

גיאוגרפיה של ארצנו העצומה

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

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

סובלנות לתקלות

זה הצד השני של הריכוזיות.

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

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

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

ניסיון עולמי

למרבה ההפתעה, לא מצאנו אף התייחסות אחת בתחום הטלקום העולמי.

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

כדי לנתח את הארכיטקטורה, הרכבנו צוות Dream Team בראשות IBM — אדריכלים מתחומים שונים. האנשים האלה יכלו להעריך בצורה מספקת את מה שאנחנו עושים ולהביא ידע מסוים לארכיטקטורה שלנו.

קנה מידה

כמה מספרים להמחשה.

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

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

2 מיליארד עסקאות היתרה משתנה מדי יום עקב תשלומים, חיובים, שיחות ואירועים אחרים. 200 TB של נתונים משתנה באופן פעיל, לשנות קצת יותר לאט 8 PB של נתונים, וזה לא ארכיון, אלא נתונים חיים בחיוב אחד. קנה מידה לפי מרכז נתונים - 5 אלף שרתים ב-14 אתרים.

ערימת טכנולוגיה

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

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

גמישות זה טוב, אבל בתאגיד גדול אין דרך בלי איחוד.

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

למה טרנטול?

ישנם 4 קריטריונים פשוטים מדוע בחרנו במסד הנתונים הזה.

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

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

Tarantool מכסה את צרכי החברה גם לטווח ארוך.

עלות TCO. תמיכה ב-Couchbase בנפחי MegaFon עולה הון תועפות, אבל עם Tarantool המצב הרבה יותר נחמד, והם דומים בפונקציונליות.

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

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

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

Tarantool-enterprise סיפק אותנו לחלוטין מבחינת אבטחה, אמינות ורישום.

שׁוּתָפוּת

הדבר החשוב ביותר עבורי הוא קשר ישיר עם היזם. זה בדיוק מה שהחבר'ה מ-Tarantool קנו אותי איתו.

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

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

לאנשים רבים יש מפת דרכים ל-2-3 השנים הבאות, וכמעט בלתי אפשרי להשתלב שם, אבל מפתחי Tarantool שובים בפתיחות שלהם, ולא רק עם MegaFon, ומתאימים את המערכת שלהם ללקוח. זה מגניב ואנחנו מאוד אוהבים את זה.

איפה השתמשנו ב-Tarantool

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

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

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

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

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

שירותי מיקרו הם אולי התפקיד העיקרי של Tarantool ב-MegaFon.

איפה אנחנו מתכננים להשתמש ב-Tarantool

אם נשווה את פרויקט החיוב המוצלח שלנו עם תוכניות הטרנספורמציה ב- Deutsche Telekom, Svyazcom, Vodafone India, הוא דינמי ויצירתי באופן מפתיע. בתהליך יישום הפרויקט הזה, לא רק MegaFon והמבנה שלו שונו, אלא גם Tarantool-enterprise הופיעו ב-Mail.ru, והספק שלנו Nexign (לשעבר Peter-Service) - BSS Box (פתרון חיוב בארגז).

זהו, במובן מסוים, פרויקט היסטורי עבור השוק הרוסי. אפשר להשוות אותו למה שמתואר בספרו של פרדריק ברוקס "חודש האדם המיתי". אז, בשנות ה-60, IBM שכרה 360 אנשים כדי לפתח את מערכת ההפעלה החדשה OS/5 למיינפריים. יש לנו פחות - 000, אבל אנחנו באפוד, ובהתחשב בשימוש בקוד פתוח ובגישות חדשות, אנחנו עובדים בצורה פרודוקטיבית יותר.

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

פתח ממשק API

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

אני לא יודע אם SSO דומה ל-Mail.ru - נראה שלחבר'ה יש 1 עסקאות בשנייה. אנחנו מאוד מעוניינים בפתרון שלהם ואנו מתכננים לאמץ את הניסיון שלהם - למשל, יצירת גיבוי SSO פונקציונלי באמצעות Tarantool. כעת המפתחים מ- Mail.ru עושים זאת איתנו.

CRM

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

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

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

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

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

התמונה הקודמת מציגה את התחומים שבהם אנו הולכים להשתמש ב-Tarantool. CRM עצמו, כמובן, רחב יותר ואנחנו הולכים להשתמש בו בליבה עצמה.

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

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

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

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

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

RTO ו-RPO

ישנם שני מונחים ב-IT: RTO и RPO.

יעד זמן התאוששות הוא הזמן שלוקח לשחזר את השירות לאחר תקלה. RTO = 0 אומר שגם אם משהו נכשל, השירות ממשיך לעבוד.

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

משימת טרנטול

בואו ננסה לפתור בעיה עבור Tarantool.

נָתוּן: סל של בקשות שכולם מבינים, למשל באמזון או במקום אחר. נדרש כך שסל הקניות עובד 24 שעות 7 ימים בשבוע, או 99,99% מהזמן. ההזמנות שמגיעות אלינו חייבות להישאר מסודרות, כי איננו יכולים להפעיל או לכבות באופן אקראי את החיבור של המנוי - הכל חייב להיות עקבי בהחלט. המנוי הקודם משפיע על הבא, ולכן הנתונים חשובים - שום דבר לא אמור להעלם.

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

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

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

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

בתחילה אנו בונים פתרון מבוזר גיאוגרפי - סובלנות תקלות חשובה לנו.

אז יש לנו אשכול, אבל מה לגבי RPO = 0 ו- RTO = 0? הפתרון פשוט, תלוי בנושא.

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

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

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

יתר על כן, עם רישום מבוזר של יישומים, אנחנו יכולים גם להרחיב את הכל - יש הרבה שולחים ומבצעים שניגשים למרשם הזה.

קסנדרה וטרנטול ביחד

יש עוד מקרה - "חלון ראווה של איזונים". הנה מקרה מעניין של שימוש משותף בקסנדרה ובטרנטול.

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

קסנדרה מאפשרת לך לשנות אופקית לכל גודל.

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

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

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

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

מסקנה

אלו היו דוגמאות לשימוש ב-Tarantool. אהבנו מאוד את הפתיחות של Mail.ru ואת הנכונות שלהם לשקול מקרים שונים.

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

הדו"ח של אולג ואנדריי הוא אחד הטובים בוועידת טרנטול בשנה שעברה, וב-17 ביוני אולג איבלב ידבר ב- כנס T+ 2019 עם דוח "למה Tarantool בארגונים". אלכסנדר דאולין גם יעביר מצגת מ-MegaFon "מטמונים ושכפול של Tarantool מ-Oracle". בואו לגלות מה השתנה, אילו תוכניות יושמו. הצטרפו - הכנס ללא תשלום, כל שעליכם לעשות הוא להירשם. כל דוחות התקבלו ותוכנית הכנס נוצרה: מקרים חדשים, ניסיון חדש בשימוש ב-Tarantool, ארכיטקטורה, ארגונים, הדרכות ושירותי מיקרו.

מקור: www.habr.com