Навошта такой карпарацыі, як Мегафон, Tarantool у білінгу? З боку здаецца, што звычайна прыходзіць вендар, прыносіць нейкую вялікую скрынку, утыкае штэкер у разетку - вось і білінг! Калісьці так і было, але зараз гэта архаіка, і такія дыназаўры ўжо вымерлі ці выміраюць. Першапачаткова білінг гэта сістэма для выстаўлення рахункаў - лічылка або калькулятар. У сучасным тэлекоме - гэта сістэма аўтаматызацыі ўсяго жыццёвага цыкла ўзаемадзеяння з абанентам ад заключэння дагавора да скасавання, У тым ліку real-time-тарыфікацыю, прыём плацяжоў і яшчэ шмат чаго. Білінг у тэлекам-кампаніях падобны на баявога робата – вялікага, магутнага і абчэпленага зброяй.
Прычым жа тут Tarantool? Пра гэта раскажуць Алег Іўлеў и Андрэй Князеў. Алег - галоўны архітэктар кампаніі з велізарным досведам працы ў замежных кампаніях, Андрэй - дырэктар па бізнес-сістэмах. З расшыфроўкі іх даклада на вы даведаецеся, навошта патрэбен R&D у карпарацыях, што такое Tarantool, як тупік вертыкальнага маштабавання і глабалізацыя сталі перадумовамі з'яўлення гэтай БД у кампаніі, пра тэхналагічныя выклікі, трансфармацыю архітэктуры, і чым тэхнастэк Мегафон падобны на Netflix, Google і Amazon.
Праект "Адзіны білінг"
Праект, пра які пойдзе гаворка, называецца "Адзіны білінг". Менавіта ў ім Tarantool выявіў свае лепшыя якасці.
Рост прадукцыйнасці Hi-End абсталявання не паспяваў за ростам абаненцкай базы і ростам колькасці паслуг, чакаўся далейшы рост колькасці абанентаў і паслуг за кошт M2M, IoT, ды і філіяльныя асаблівасці прыводзілі да пагаршэння time-to-market. Кампаніяй было прынята рашэнне стварыць адзіную бізнес сістэму з унікальнай модульнай архітэктурай сусветнага ўзроўню, узамен 8 бягучых розных білінгавых сістэм.
Мегафон - гэта восем кампаній у адной. У 2009 годзе завяршылася рэарганізацыя: філіялы па ўсёй Расіі аб'ядналіся ў адзіную кампанію ААТ "Мегафон" (цяпер ПАТ). Такім чынам, у кампаніі з'явілася 8 білінгавых сістэм з уласнымі "кастомнымі" рашэннямі, філіяльнымі асаблівасцямі і рознай арганізацыйнай структурай, ІТ і маркетынгам.
Усё было добра, пакуль не прыйшлося запусціць адзін агульны федэральны прадукт. Тут з'явілася куча складанасцяў: у кагосьці тарыфікацыя з акругленнем у большы бок, у кагосьці ў меншы, а ў кагосьці — па сярэднім арыфметычным. Такіх момантаў тысячы.
Нягледзячы на тое, што версія білінгавай сістэмы адна, адзін пастаўшчык, налады разыходзіліся так, што ляпіць доўга. Мы паспрабавалі скараціць іх лік, і натыкнуліся на другую праблему, якая знаёмая шматлікім карпарацыям.
Вертыкальнае маштабаванне. Нават самае крутое ў той час жалеза не адпавядала патрэбам. У працы выкарыстоўвалі абсталяванне Hewlett-Packard, лінейкі Superdome Hi-End, але яно не цягнула запатрабаванне нават двух філіялаў. Жадалася гарызантальнага маштабавання без вялікіх аперацыйных выдаткаў і капітальных укладанняў.
Чаканне росту колькасці абанентаў і паслуг. Кансультанты даўно прынеслі ў тэлекам-свет апавяданні пра IoT і M2M: надыдуць часы, калі ў кожным тэлефоне і прасе будзе па сім-карце, а ў халадзільніку па дзве. Сёння ў нас адна колькасць абанентаў, а ў найбліжэйшай будучыні іх будзе на парадак больш.
Тэхналагічныя выклікі
Гэтыя чатыры прычыны рухалі нас на сур'ёзныя змены. Быў выбар паміж мадэрнізацыяй сістэмы і праектаваннем з нуля. Доўга думалі, прымалі сур'ёзныя рашэнні, гулялі тэндэры. У выніку вырашылі спраектаваць з самага пачатку, і ўзяліся за цікавыя чэленджы - тэхналагічныя выклікі.
маштабаванасць
Калі раней было, умоўна скажам, 8 білінгаў па 15 млн абанентаў, а цяпер павінна было атрымацца 100 млн абанентаў і больш - Нагрузка на парадак вышэй.
Мы сталі супастаўныя па маштабе з буйнымі інтэрнэт-гульцамі, як Mail.ru ці Netflix.
Але далейшы рух на павелічэнне нагрузкі і абаненцкай базы паставіў перад намі сур'ёзныя задачы.
Геаграфія нашай неабсяжнай краіны
Паміж Калінінградам і Уладзівастокам 7500 км і 10 гадзінных паясоў. Хуткасць святла канчатковая і на такіх адлегласцях затрымкі ўжо значныя. 150 мс на самых стромкіх сучасных аптычных каналах – зашмат для real-time-тарыфікацыі, асабліва такі, як цяпер у тэлекоме ў Расіі. Акрамя таго, неабходна абнаўляцца за адзін працоўны дзень, а з рознымі часавымі паясамі - гэта праблема.
Мы не проста даем паслугі за абаненцкую плату, у нас ёсць складаныя тарыфы, пакеты, розныя мадыфікатары. Нам трэба не проста дазволіць або забараніць абаненту размаўляць, але даць яму пэўную квоту - аблічыць выклікі і дзеянні ў рэжыме рэальнага часу так, каб ён не заўважыў.
адмоваўстойлівасць
Гэта адваротны бок цэнтралізацыі.
Калі мы збіраем усіх абанентаў у адной сістэме, то любыя аварыйныя падзеі і катастрофы сумныя для бізнесу. Таму сістэму праектуем так, каб выключыць уплыў аварый на ўсю абаненцкую базу.
Гэтае следства ізноў-ткі адмовы ад вертыкальнага маштабавання. Калі мы сышлі ў гарызантальнае маштабаванне, то павялічылі колькасць сервераў з сотняў да тысяч. Імі трэба кіраваць і будаваць узаемазаменнасць, аўтаматычна рэзерваваць IT-інфраструктуру і аднаўляць размеркаваную сістэму.
Такія цікавыя выклікі стаялі перад намі. Мы спраектавалі сістэму, і ў гэты момант паспрабавалі знайсці сусветны перадавы вопыт, каб праверыць, наколькі мы ў трэндзе, наколькі прытрымліваемся перадавых тэхналогій.
Сусветны вопыт
Дзіўна, але ў сусветным тэлекоме мы не знайшлі ніводнага рэферэнсу.
Еўропа адпала па колькасці абанентаў і маштабе, ЗША - па плоскасці сваіх тарыфаў. Нешта паглядзелі ў Кітаі, а нешта знайшлі ў Індыі і ўзялі адмыслоўцаў з Vodafone India.
Для аналізу архітэктуры, сабралі Dream Team на чале з IBM – архітэктараў з розных абласцей. Гэтыя людзі маглі адэкватна ацаніць, што мы робім, і прыўнесці ў нашу архітэктуру пэўныя веды.
маштаб
Некалькі лікаў для ілюстрацыі.
Мы праектуем сістэму пад 80 млн абанентаў з запасам на мільярд. Так мы прыбіраем будучыя парогі. Гэта не таму, што мы збіраемся захопліваць Кітай, а з-за напору IoT і M2M.
300 млн дакументаў апрацоўваюцца ў рэальным часе. Хаця ў нас 80 млн абанентаў, але мы працуем і з патэнцыйнымі кліентамі, і з тымі, якія ад нас адышлі, калі трэба спагнаць дэбіторскую запазычанасць. Таму рэальныя аб'ёмы заўважна большыя.
2 млрд транзакцый штодня мяняюць баланс - гэта плацяжы, налічэнні, выклікі і іншыя падзеі. 200 Тб дадзеных мяняюцца актыўна, крыху павольней мяняюцца 8 Пб дадзеных, і гэта не архіў, а жывыя дадзеныя ў адзіным білінгу. Маштаб па ЦАДах - 5 тысяч сервераў на 14 пляцоўках.
Тэхналагічны стэк
Калі спланавалі архітэктуру і ўзяліся збіраць сістэму, то імпартавалі сабе самыя цікавыя і перадавыя тэхналогіі. Атрымаўся тэхналагічны стэк, знаёмы любому гульцу інтэрнэту і карпарацыям, якія робяць высоканагружаныя сістэмы.
Стэк аналагічны стэкам іншых буйных гульцоў: Netflix, Twitter, Viber. Ён складаецца з 6 кампанентаў, але мы жадаем яго скараціць і ўніфікаваць.
Гнуткасць - гэта добра, але ў вялікай карпарацыі без уніфікацыі ніяк.
Мы не збіраемся мяняць той жа Oracle на Tarantool. У рэаліях буйных кампаній гэта ўтопія, ці крыжовы паход на 5-10 гадоў з незразумелым зыходам. Але Cassandra і Couchbase суцэль можна замяніць на Tarantool, і мы да гэтага імкнемся.
Чаму Tarantool?
Ёсць 4 простых крытэрыю, чаму мы выбралі гэтую БД.
Хуткасць. Мы правялі нагрузачныя тэсты на прамысловых сістэмах Мегафон. Tarantool перамог - ён паказаў лепшую прадукцыйнасць.
Нельга сказаць, што іншыя сістэмы не задавальняюць патрэбам Мегафон. Бягучыя memory-рашэнні настолькі прадукцыйныя, што гэтага запасу кампаніі хапае з лішкам. Але нам цікава мець справу з лідэрам, а не з тым, хто пляцецца ў хвасце, у тым ліку па нагрузачным тэсце.
Tarantool закрывае патрэбнасці кампаніі нават у доўгатэрміновай перспектыве.
Кошт TCO. Падтрымка Couchbase на аб'ёмах Мегафон варта касмічных грошай, з Tarantool жа сітуацыя значна прыемней, а па функцыянальнасці яны блізкія.
Яшчэ адна прыемная асаблівасць, якая крыху паўплывала на наш выбар - Tarantool лепш астатніх баз працуе з памяццю. Ён паказвае максімальную эфектыўнасць.
Надзейнасць. Мегафон укладваецца ў надзейнасць, мусіць, як ніхто іншы. Таму, калі мы паглядзелі на Tarantool, то зразумелі, што трэба зрабіць так, каб ён задавальняў нашым патрабаванням.
Мы інвеставалі свой час і фінансы, і разам з Mail.ru стварылі enterprise-версію, якая зараз выкарыстоўваецца ўжо ў некалькіх іншых кампаніях.
Tarantool-enterprise нас поўнасцю задаволіў па бяспецы, надзейнасці, лагіраванні.
Партнёрства
Самае важнае для мяне прамы кантакт з распрацоўшчыкам. Гэта проста тое, чым хлопцы з Tarantool падкупілі.
Калі ты прыходзіш да гульца, асабліва які працуе з якарным кліентам, і кажаш, што табе трэба, каб БД умела гэта, гэта і гэта, звычайна ён адказвае:
- Добра, пакладзеце патрабаванні пад ніз той чаркі - калі-небудзь, мусіць, мы да іх дабяромся.
У многіх ёсць roadmap на бліжэйшыя 2-3 гады, і ўбудавацца туды практычна немагчыма, а распрацоўшчыкі Tarantool падкупляюць адкрытасцю, і не толькі з Мегафон, і адаптуюць сваю сістэму пад заказчыка. Гэта крута, і нам вельмі падабаецца.
Дзе мы ўжылі Tarantool
Мы Tarantool выкарыстоўваецца ў некалькіх элементах. Першы - у пілоту, які мы зрабілі на сістэме адраснага каталога. У свой час хацелася, каб гэта была сістэма, якая падобная да Яндэкс.Карты і Google Maps, але выйшла некалькі інакш.
Напрыклад, адрасны каталог у інтэрфейсе продажаў. На Oracle пошук патрэбнага адраса займае 12-13 з. - некамфортныя лічбы. Калі мы перамыкаемся на Tarantool, падмяняем Oracle на іншую БД у кансолі, і выконваем той жа пошук, тое атрымліваем паскарэнне ў 200 раз! Горад выскоквае пасля трэцяй літары. Цяпер які адаптуецца інтэрфейс, каб гэта адбывалася пасля першай. Тым не менш, хуткасць водгуку зусім іншая – ужо мілісекунды замест секунд.
Другое прымяненне - модная тэма, якая называецца двуххуткасны IT. Усё таму што кансультанты з кожнага праса гавораць, што карпарацыям варта туды ісці.
Тут ёсць пласт інфраструктуры, над ім дамены, напрыклад, білінгавая сістэма, як у тэлекома, карпаратыўныя сістэмы, карпаратыўная справаздачнасць. Гэта ядро, якое чапаць не трэба. Гэта значыць, вядома, можна, але паранаідальна забяспечваючы якасць, таму што гэта прыносіць карпарацыі грошы.
Далей ідзе пласт мікрасэрвісаў – тое, што дыферэнцыруе аператара ці іншага гульца. Мікрасэрвісы можна хутка вырабляць на аснове некаторых кэшаў, паднімаючы туды дадзеныя з розных даменаў. Тут поле для эксперыментаў - калі нешта не атрымалася, зачыніў адзін мікрасэрвіс, адкрыў іншы. Гэта забяспечвае сапраўды падвышаны time-to-market і павялічвае надзейнасць і хуткасць кампаніі.
Мікрасэрвісы – гэта, мабыць, асноўная роля Tarantool у Мегафон.
Дзе плануем прымяніць Tarantool
Калі параўноўваць наш паспяховы праект білінгу з праграмамі трансфармацыі ў Deutsche Telekom, Связькоме, Vodafone India, ён дзіўна дынамічны і крэатыўны. У працэсе рэалізацыі гэтага праекта не толькі трансфармаваўся Мегафон і яго структура, але і з'явіўся Tarantool-enterprise у Mail.ru, а ў нашага вендара Nexign (раней "Петэр-Сэрвіс") – BSS Box (скрынкавае білінгавае рашэнне).
Гэта, у нейкім сэнсе, гістарычны для расейскага рынку праект. Яго можна параўнаць з тым, што апісана ў кнізе Фрэдэрыка Брукса "Міфічны чалавека-месяц". Тады, у 60-х гадах для распрацоўкі новай аперацыйнай сістэмы OS/360 для мэйнфрэймаў IBM прыцягваў 5 000 чалавек. У нас менш — 1 800, але нашы ў цяльняшках, і з улікам выкарыстання апенсорсу і новых падыходаў мы працуем больш прадукцыйна.
Ніжэй адлюстраваны дамены білінгу або, калі казаць шырэй, - бізнес-сістэм. Людзі з enterprise выдатна ведаюць CRM. Іншыя сістэмы павінны быць ужо ва ўсіх: Open API, API Gateway.
Адкрыты API
Давайце зноў паглядзім на лікі і тое, як зараз працуе Open API. Яго нагрузка - 10 000 транзакцый у секунду. Паколькі мы плануем актыўна развіваць пласт мікрасэрвісаў і будаваць публічны API Мегафон, то чакаем большага росту ў будучыні менавіта ў гэтай частцы. 100 000 транзакцый сапраўды будзе.
Не ведаю, ці параўнаемся ў SSO з Mail.ru - у рабят, накшталт, 1 000 0000 транзакцый у секунду. Нам іх рашэнне вельмі цікава і мы плануем пераняць іх вопыт - напрыклад, рабіць функцыянальны рэзерв SSO з дапамогай Tarantool. Цяпер распрацоўшчыкі з Mail.ru гэтым займаюцца ў нас.
CRM
CRM – гэта тыя самыя 80 млн абанентаў, якіх мы хочам давесці да мільярда, таму што ўжо ёсць 300 млн дакументаў, якія ўключаюць трохгадовую гісторыю. Мы сапраўды чакаем новых паслуг, і тут кропка росту - гэта падлучаныя паслугі. Гэта шар, які будзе расці, таму што паслуг будзе ўсё больш і больш. Адпаведна, патрэбная будзе гісторыя, мы не хочам на гэтым спатыкнуцца.
Сам білінг у частцы выстаўлення рахункаў, працы з дэбіторскай запазычанасцю кліентаў трансфармаваўся ў асобны дамен. Каб расшыць прадукцыйнасць, ужыты архітэктурны шаблон даменнай архітэктуры.
Сістэма падзелена на дамены, нагрузка размеркавана і забяспечана адмоваўстойлівасць. Дадаткова правялі работу з размеркаванай архітэктурай.
Усё астатняе - гэта рашэнні ўзроўню enterprise. У сховішчы званкоў 2 млрд у дзень, 60 млрд. у месяц. Часам даводзіцца пералічыць іх за месяц, і лепш хутка. Фінансавы маніторынг – гэта як раз тыя самыя 300 млн, якія ўвесь час растуць і растуць: абаненты часта бегаюць паміж аператарамі, павялічваючы гэтую частку.
Самы тэлекомаўскі кампанент з мабільнай сувязі - гэта анлайнавая тарыфікацыя. Гэта тыя сістэмы, якія дазваляюць вам тэлефанаваць ці не тэлефанаваць, прымаюць рашэнне ў рэальным часе. Тут нагрузка 30 транзакцый у секунду, але з улікам росту перадачы дадзеных мы плануем 250 000 транзакцый, і таму моцна цікавімся Tarantool.
Папярэдні малюнак – гэта тыя дамены, дзе мы збіраемся ўжываць Tarantool. Сам CRM, вядома, шырэй і мы збіраемся прымяняць яго ў самым ядры.
Наша разліковая лічба ТТХ у 100 млн абанентаў мяне бянтэжыць як архітэктара - а што, калі 101 млн? Ізноў усё перарабляць? Каб такога не дапусціць, мы ўжываем кэшы, заадно паднімаючы даступнасць.
У цэлым існуе два падыходу прымянення Tarantool. Першы - пабудаваць усе кэшы на ўзроўні мікрасэрвісаў. Наколькі я разумею, па гэтым шляху ідзе Вымпелком, ствараючы кэш кліентаў.
Мы ж менш залежым ад вендараў, змяняем ядро BSS, таму ў нас адзіная картатэка кліентаў ужо са скрынкі. Але мы жадаем яе расшыць. Таму ўжываем крыху іншы падыход — які робіцца кэшы ўнутр сістэм.
Так менш рассінхрона - адна сістэма адказвае і за кэш, і за асноўны майстар-крыніца.
Спосаб добра кладзецца ў падыход Tarantool з транзакцыйным шкілетам, калі абнаўляюцца толькі часткі, якія датычацца апдэйтаў, гэта значыць змены дадзеных. Усё астатняе можна захоўваць недзе яшчэ. Няма вялізнага data lake, некіраванага глабальнага кэша. Кэшы праектуюцца пад сістэму, альбо пад прадукты, альбо пад кліентаў, альбо, каб аблегчыць жыццё абслугоўванню. Калі тэлефануе засмучаны якасцю абанент, хочацца якасна яго абслужыць.
RTO і RPO
У IT існуе два тэрміны - OTR и РПО.
Recovery time objective - гэты час аднаўлення сэрвісу пасля збою. RTO = 0 значыць, што нават калі нешта ўпала, сервіс працягвае працаваць.
Recovery point objective - Гэта час аднаўлення дадзеных, колькі дадзеных мы можам страціць за нейкі перыяд часу. RPO = 0 значыць, што мы не губляем даныя.
Задача па Tarantool
Давайце паспрабуем вырашыць для Tarantool задачу.
Дана: усім зразумелы кошык заявак, напрыклад, у Амазоне ці яшчэ дзе-небудзь. патрабуецца каб кошык працаваў 24 гадзіны 7 дзён у тыдзень, ці 99,99% часу. Заказы, якія да нас прыходзяць, павінны захоўваць парадак, таму што мы не можам хаатычна ўключаць або адключаць абаненту сувязь - усё павінна быць строга паслядоўна. Папярэдняя падпіска ўплывае на наступную, таму дадзеныя важныя - нішто не павінна знікнуць.
рашэнне. Можна паспрабаваць вырашаць у лоб і спытаць распрацоўшчыкаў БД, але задача матэматычна не вырашаецца. Можна ўспамінаць тэарэмы, законы захавання, квантавую фізіку, але навошта - яе немагчыма вырашыць на ўзроўні БД.
Тут працуе стары добры архітэктурны падыход - трэба добра ведаць прадметную вобласць і за яе кошт дазволіць гэты рэбус.
Наша рашэнне: ствараем размеркаваны рэестр заявак на Tarantool - геаразмеркаваны кластар. На схеме гэта тры розных цэнтра апрацоўкі дадзеных - два да Урала, адзін за Уралам, і мы размяркоўваем усе заяўкі па гэтых цэнтрах.
У Netflix, які зараз лічыцца адным з лідэраў у IT, да 2012 года быў усяго адзін ЦАД. Напярэдадні каталіцкіх Калядаў 24 снежня гэты ЦАД лёг. Карыстальнікі Канады і ЗША засталіся без сваіх любімых фільмаў, моцна знерваваліся і ў сацсетках аб гэтым напісалі. Зараз у Netflix тры ЦАДа на заходне-ўсходнім узбярэжжы і адзін у заходняй Еўропе.
Мы першапачаткова будуем геаразмеркаванае рашэнне - нам важная адмоваўстойлівасць.
Такім чынам, у нас ёсць кластар, але што рабіць з RPO = 0 і RTO = 0? Рашэнне простае, якое залежыць ад прадметы.
Што важна ў заяўках? Дзве часткі: накідванне кошыка ДА прыняцця рашэння аб куплі, і ПАСЛЯ. Частка ДА у тэлекоме звычайна называюць order capturing або order negotiation. У тэлекоме гэта можа быць значна складаней, чым у інтэрнэт-краме, таму што тамака кліента трэба абслужыць, прапанаваць 5 варыянтаў, і гэта ўсё адбываецца нейкі час, але кошык напаўняецца. У гэты момант збой магчымы, але гэта не страшна, бо адбываецца ў інтэрактыўным рэжыме пад наглядам чалавека.
Калі Маскоўскі ЦАД раптам выйдзе са строю, то пераключыўшыся аўтаматычна на іншы ЦАД, мы працягнем працу. Тэарэтычна можа згубіцца адзін прадукт у кошыку, але вы гэта бачыце, дапаўняеце кошык зноў і працягваеце працаваць. У гэтым выпадку RTO = 0.
У той жа момант ёсць другі варыянт: калі мы націснулі "submit", то жадаем, каб дадзеныя не згубіліся. З гэтага моманту пачынае працаваць аўтаматыка – гэта ўжо RPO = 0. Ужыванне гэтых двух розных патэрнаў у адным выпадку гэта можа быць проста геаразмеркаваны кластар з адным які перамыкаецца майстрам, у іншым выпадку які-небудзь кворумны запіс. Шаблоны могуць вар'іравацца, але мы вырашаем праблему.
Далей, маючы размеркаваны рэестр заявак, мы можам яшчэ і маштабаваць гэта ўсё - мець шмат дыспетчараў і выканаўцаў, якія звяртаюцца да гэтага рэестру.
Cassandra і Tarantool разам
Ёсць яшчэ адзін кейс - «вітрына балансаў». Тут якраз цікавы выпадак сумеснага прымянення Cassandra і Tarantool.
Мы ўжываем Cassandra, таму што 2 млрд званкоў у дзень – не мяжа, і іх будзе больш. Маркетолагі любяць размалёўваць трафік па крыніцах, з'яўляецца ўсё больш дэталяў па сацсетках, напрыклад. Гэта ўсё павялічвае гісторыю.
Cassandra дазваляе гарызантальна маштабавацца на любыя аб'ёмы.
Мы сябе адчуваем камфортна з Cassandra, але ў яе ёсць адна праблема яна не добрая на чытанні. На запісы ўсё ОК, 30 000 у секунду не праблема праблема ў чытанні.
Таму з'явілася тэма з кэшам, і мы заадно вырашылі наступную праблему: ёсць стары традыцыйны кейс, калі абсталяванне ад камутатара ад анлайн-тарыфікацыі прыходзіць у файлы, якія мы загружаем у Cassandra. Мы пазмагаліся з праблемай надзейнай загрузкі гэтых файлаў, ужылі нават па радзе IBM manager file transfer – ёсць такія рашэнні, якія кіруюць перадачай файлаў эфектыўна, выкарыстаючы пратакол UDP, напрыклад, а не TCP. Гэта добра, але ўсё роўна хвіліны, і мы пакуль гэта ўсё не прагрузім, аператар у кол-цэнтры не можа адказаць кліенту, што ж здарылася з яго балансам – трэба чакаць.
Каб гэтага не адбылося, мы ужывальны раўналежны функцыянальны рэзерв. Калі мы адпраўляем падзею праз Kafka у Tarantool, пералічваючы агрэгаты ў рэальным часе, напрыклад, за сёння, то атрымліваем кэш балансаў, Які можа аддаваць балансы з любой хуткасцю, напрыклад, 100 тысяч транзакцый у секунду і тыя самыя 2 секунды.
Мэта ў тым, каб пасля званка ўжо праз 2 секунды ў асабістым кабінеце быў не толькі зменены баланс, але інфармацыя пра тое, чаму ён змяніўся.
Заключэнне
Гэта былі прыклады выкарыстання Tarantool. Нам вельмі спадабалася адкрытасць Mail.ru, іх гатоўнасць разглядаць розныя кейсы.
Кансультантам з BCG ці McKinsey, Accenture ці IBM ужо складана нас здзівіць чымсьці новым – шмат з таго, што яны прапануюць, мы альбо ўжо робім, альбо зрабілі, альбо плануем рабіць. Думаю, што Tarantool у нашым тэхналагічным стэку зойме годнае месца і заменіць мноства ўжо існых тэхналогій. Мы ў актыўнай фазе развіцця гэтага праекту.
Даклад Алега і Андрэя - адзін з лепшых на Tarantool Conference мінулага года, а ўжо 17 чэрвеня Алег Іўлеў выступіць на з дакладам . Таксама ад Мегафона выступіць Аляксандр Дзяулін з дакладам. . Даведаемся, што змянілася, якія планы ўдалося рэалізаваць. Далучайцеся - канферэнцыя бясплатная, трэба толькі . усе і праграма канферэнцыі сфарміравана: новыя кейсы, новы вопыт выкарыстання Tarantool, архітэктура, энтэрпрайз, тутарыялы і мікрасэрвісы.
Крыніца: habr.com