Kodėl tokiai korporacijai kaip „MegaFon“ atsiskaitant reikia „Tarantool“? Iš išorės atrodo, kad dažniausiai ateina pardavėjas, atneša kažkokią didelę dėžutę, įkiša kištuką į lizdą - ir tai atsiskaitymas! Kažkada taip buvo, bet dabar tai archajiška, o tokie dinozaurai jau išnyko arba nyksta. Iš pradžių atsiskaitymas yra sąskaitų faktūrų išrašymo sistema – skaičiavimo mašina arba skaičiuotuvas. Šiuolaikinėse telekomunikacijose taip yra automatizavimo sistema per visą sąveikos su abonentu gyvavimo ciklą nuo sutarties sudarymo iki nutraukimo, įskaitant atsiskaitymą realiuoju laiku, mokėjimų priėmimą ir daug daugiau. Atsiskaitymas telekomunikacijų įmonėse yra kaip kovinis robotas – didelis, galingas ir apkrautas ginklais.
Ką su tuo turi „Tarantool“? Jie apie tai kalbės Olegas Ivlevas и Andrejus Knyazevas. Olegas yra įmonės vyriausiasis architektas Andrejus, turintis didelę darbo užsienio įmonėse patirtį, yra verslo sistemų direktorius. Iš jų pranešimo nuorašo apie Sužinosite, kodėl korporacijose reikalingi MTEP, kas yra Tarantool, kaip šios duomenų bazės atsiradimo įmonėje prielaidomis tapo vertikalaus mastelio keitimo ir globalizacijos aklavietė, apie technologinius iššūkius, architektūrinę transformaciją ir kuo MegaFon technostack panašus į Netflix. , Google ir Amazon.
Projektas „Vieningas atsiskaitymas“
Aptariamas projektas vadinamas „Vieningu atsiskaitymu“. Būtent čia Tarantool pademonstravo geriausias savo savybes.
Hi-End įrangos produktyvumo augimas neatsiliko nuo abonentų skaičiaus ir paslaugų skaičiaus augimo, tikimasi tolesnio abonentų ir paslaugų skaičiaus augimo dėl M2M, IoT ir filialų funkcijų. pablogėjo laikas iki patekimo į rinką. Įmonė nusprendė sukurti vieningą verslo sistemą su unikalia pasaulinio lygio moduline architektūra, o ne 8 dabartines skirtingas atsiskaitymo sistemas.
„MegaFon“ yra aštuonios įmonės vienoje. 2009 m. buvo baigta reorganizacija: filialai visoje Rusijoje sujungti į vieną bendrovę „MegaFon OJSC“ (dabar PJSC). Taigi, įmonė turi 8 atsiskaitymo sistemas su savo „užsakomaisiais“ sprendimais, filialų ypatybėmis ir skirtingomis organizacinėmis struktūromis, IT ir rinkodara.
Viskas buvo gerai, kol neturėjome išleisti vieno bendro federalinio produkto. Čia iškilo daug keblumų: vieniems tarifai suapvalinami, kitiems – žemyn, tretiems – pagal aritmetinį vidurkį. Tokių akimirkų yra tūkstančiai.
Nepaisant to, kad buvo tik viena atsiskaitymo sistemos versija, vienas tiekėjas, nustatymai taip išsiskyrė, kad juos sudėti reikėjo ilgai. Pabandėme sumažinti jų skaičių ir susidūrėme su antra problema, pažįstama daugeliui korporacijų.
Vertikalus mastelio keitimas. Net pati šauniausia aparatūra tuo metu neatitiko poreikių. Naudojome „Hewlett-Packard“ įrangą iš „Superdome Hi-End“ linijos, tačiau ji neatitiko net dviejų filialų poreikių. Norėjau horizontalaus mastelio be didelių eksploatacinių išlaidų ir kapitalo investicijų.
Tikimasi abonentų ir paslaugų skaičiaus augimo. Konsultantai jau seniai į telekomunikacijų pasaulį atnešė istorijas apie daiktų internetą ir M2M: ateis laikas, kai kiekvienas telefonas ir lygintuvas turės SIM kortelę, o šaldytuve – dvi. Šiandien turime tiek pat prenumeratorių, bet artimiausiu metu jų bus daug daugiau.
Technologiniai iššūkiai
Šios keturios priežastys paskatino mus imtis rimtų pokyčių. Buvo galima rinktis tarp sistemos atnaujinimo ir projektavimo nuo nulio. Ilgai galvojome, priėmėme rimtus sprendimus, žaidėme konkursus. Dėl to nusprendėme projektuoti nuo pat pradžių, ėmėmės įdomių iššūkių – technologinių iššūkių.
Mastelis
Jei tai buvo anksčiau, sakykime, sakykime 8 atsiskaitymai 15 milijonų abonentų, ir dabar tai turėjo veikti 100 milijonų prenumeratorių ir daugiau - apkrova yra eilės tvarka didesnė.
Savo mastu tapome panašūs į didelius interneto grotuvus, tokius kaip Mail.ru ar Netflix.
Tačiau tolesnis judėjimas siekiant didinti apkrovą ir abonentų bazę mums iškėlė rimtų iššūkių.
Mūsų didžiulės šalies geografija
Tarp Kaliningrado ir Vladivostoko 7500 km ir 10 laiko juostų. Šviesos greitis yra baigtinis ir tokiais atstumais vėlavimai jau yra dideli. 150 ms šauniausiuose šiuolaikiniuose optiniuose kanaluose yra per daug, kad būtų galima atsiskaityti realiuoju laiku, ypač dėl to, kad dabar tai yra Rusijos telekomunikacijose. Be to, atnaujinti reikia per vieną darbo dieną, o esant skirtingoms laiko juostoms tai yra problema.
Teikiame paslaugas ne tik už abonentinį mokestį, turime sudėtingus tarifus, paketus ir įvairius modifikatorius. Turime ne tik leisti ar neleisti abonentui kalbėti, bet ir suteikti jam tam tikrą kvotą – skaičiuoti skambučius ir veiksmus realiu laiku, kad jis nepastebėtų.
atsparumas gedimams
Tai kita centralizacijos pusė.
Jei surenkame visus abonentus į vieną sistemą, bet kokie kritiniai įvykiai ir nelaimės yra pražūtingi verslui. Todėl sistemą projektuojame taip, kad nelaimingų atsitikimų poveikis visai abonentų bazei būtų pašalintas.
Tai vėlgi yra atsisakymo vertikaliai mastyti pasekmė. Kai padidinome mastelį horizontaliai, serverių skaičių padidinome nuo šimtų iki tūkstančių. Jie turi būti valdomi ir keičiami, automatiškai sukurti atsarginę IT infrastruktūros kopiją ir atkurti paskirstytą sistemą.
Susidūrėme su tokiais įdomiais iššūkiais. Sukūrėme sistemą ir tuo metu bandėme ieškoti geriausios pasaulinės praktikos, kad galėtume patikrinti, kokia tendencija esame, kiek laikomės pažangių technologijų.
Pasaulio patirtis
Keista, bet pasauliniame telekomunikacijoje neradome nė vienos nuorodos.
Europa nukrito pagal abonentų skaičių ir mastą, JAV - pagal tarifų vienodumą. Kai kuriuos peržiūrėjome Kinijoje, kai kuriuos radome Indijoje ir pasamdėme specialistus iš „Vodafone India“.
Architektūrai analizuoti subūrėme Dream Team, kuriai vadovauja IBM – skirtingų sričių architektai. Šie žmonės galėjo tinkamai įvertinti, ką mes darome, ir įnešti tam tikrų žinių į mūsų architektūrą.
Skalė
Keletas skaičių iliustracijai.
Mes projektuojame sistemą 80 milijonų abonentų su milijardo rezervu. Taip pašaliname būsimus slenksčius. Taip yra ne todėl, kad ketiname užvaldyti Kiniją, o dėl daiktų interneto ir M2M antpuolio.
Realiu laiku apdorota 300 milijonų dokumentų. Nors turime 80 milijonų abonentų, jei reikia išieškoti gautinas sumas, dirbame tiek su potencialiais klientais, tiek su tais, kurie mus paliko. Todėl faktinės apimtys yra pastebimai didesnės.
2 milijardai sandorių Likutis keičiasi kasdien – tai mokėjimai, mokesčiai, skambučiai ir kiti įvykiai. 200 TB duomenų aktyviai keičiasi, keiskite šiek tiek lėčiau 8 PB duomenų, ir tai nėra archyvas, o tiesioginiai duomenys vienoje sąskaitoje. Mastelis pagal duomenų centrą – 5 tūkstančiai serverių 14 svetainių.
Technologijų krūva
Kai planavome architektūrą ir pradėjome montuoti sistemą, importavome pačias įdomiausias ir pažangiausias technologijas. Rezultatas – technologijų krūva, pažįstama bet kuriam interneto žaidėjui ir didelės apkrovos sistemas gaminančioms korporacijoms.
Stackas panašus į kitų pagrindinių žaidėjų krūvas: „Netflix“, „Twitter“, „Viber“. Jį sudaro 6 komponentai, tačiau norime jį sutrumpinti ir suvienodinti.
Lankstumas yra gerai, bet didelėje korporacijoje neapsieina be susivienijimo.
Neketiname to paties „Oracle“ pakeisti į „Tarantool“. Didžiųjų kompanijų realybėje tai yra utopija arba 5-10 metų kryžiaus žygis su neaiškia baigtimi. Tačiau „Cassandra“ ir „Couchbase“ galima lengvai pakeisti „Tarantool“, ir to mes siekiame.
Kodėl Tarantool?
Yra 4 paprasti kriterijai, kodėl pasirinkome šią duomenų bazę.
Pagreitinti. Mes atlikome MegaFon pramoninių sistemų apkrovos bandymus. Nugalėjo Tarantool – parodė geriausią pasirodymą.
Tai nereiškia, kad kitos sistemos neatitinka „MegaFon“ poreikių. Dabartiniai atminties sprendimai yra tokie produktyvūs, kad įmonės rezervų yra daugiau nei pakankamai. Bet mums įdomu bendrauti su lyderiu, o ne su žmogumi, kuris atsilieka, įskaitant apkrovos testą.
Tarantool patenkina įmonės poreikius net ir ilgalaikėje perspektyvoje.
TCO kaina. „Couchbase“ palaikymas „MegaFon“ apimtimis kainuoja astronomines pinigų sumas, tačiau „Tarantool“ situacija yra daug malonesnė, o funkcionalumu jie panašūs.
Kita maloni savybė, kuri šiek tiek paveikė mūsų pasirinkimą, yra ta, kad Tarantool geriau veikia su atmintimi nei kitos duomenų bazės. Jis rodo maksimalus efektyvumas.
Patikimumas. „MegaFon“ investuoja į patikimumą, tikriausiai daugiau nei bet kas kitas. Taigi, kai pažvelgėme į Tarantool, supratome, kad turime padaryti, kad jis atitiktų mūsų reikalavimus.
Investavome savo laiką ir finansus, kartu su Mail.ru sukūrėme įmonės versiją, kuri dabar naudojama keliose kitose įmonėse.
Tarantool-įmonė mus visiškai patenkino saugumo, patikimumo ir medienos ruošos požiūriu.
Partnerystė
Man svarbiausia tiesioginis kontaktas su kūrėju. Būtent tai ir papirko vaikinai iš Tarantolo.
Jei ateinate pas žaidėją, ypač tą, kuris dirba su pagrindiniu klientu, ir sakote, kad jums reikia duomenų bazės, kad galėtumėte tai, tai ir tai padaryti, jis dažniausiai atsako:
– Gerai, sudėk reikalavimus į tos krūvos apačią – kada nors, ko gero, prie jų pasieksime.
Daugelis turi planą artimiausiems 2-3 metams ir ten beveik neįmanoma integruotis, tačiau Tarantool kūrėjai žavi savo atvirumu ir ne tik iš MegaFon, ir pritaiko savo sistemą klientui. Tai šaunu ir mums tai labai patinka.
Kur mes naudojome Tarantool
Tarantool naudojame kelis elementus. Pirmasis yra pilote, kurį sukūrėme adresų katalogų sistemoje. Vienu metu norėjau, kad tai būtų sistema, kuri būtų panaši į „Yandex.Maps“ ir „Google Maps“, bet pasirodė kiek kitaip.
Pavyzdžiui, adresų katalogas pardavimo sąsajoje. „Oracle“ norimo adreso paieška trunka 12–13 sekundžių. - nepatogūs skaičiai. Kai pereiname prie Tarantool, pakeičiame Oracle kita duomenų baze konsolėje ir atliekame tą pačią paiešką, gauname 200 kartų pagreitį! Miestas pasirodo po trečios raidės. Dabar pritaikome sąsają, kad tai įvyktų po pirmosios. Tačiau atsako greitis visiškai kitoks – ne sekundės, o milisekundės.
Antroji programa yra madinga tema, vadinama dviejų greičių IT. Taip yra todėl, kad konsultantai iš kiekvieno kampo sako, kad korporacijos turėtų ten eiti.
Yra infrastruktūros sluoksnis su virš jo esančiais domenais, pavyzdžiui, atsiskaitymo sistema, tokia kaip telekomunikacijos, įmonių sistemos, įmonių ataskaitų teikimas. Tai yra šerdis, kurios nereikia liesti. Tai, žinoma, įmanoma, bet paranojiškai užtikrinanti kokybę, nes tai atneša korporacijai pinigų.
Toliau seka mikropaslaugų sluoksnis – kas išskiria operatorių ar kitą žaidėją. Mikropaslaugos gali būti greitai sukurtos remiantis tam tikromis talpyklomis, perkeliant duomenis iš skirtingų domenų. Čia laukas eksperimentams - jei kažkas nepavyko, uždariau vieną mikroservisą ir atidariau kitą. Tai tikrai pailgina pateikimo į rinką laiką ir padidina įmonės patikimumą bei greitį.
Mikropaslaugos tikriausiai yra pagrindinis Tarantool vaidmuo MegaFon.
Kur planuojame naudoti Tarantool
Jei palyginsime mūsų sėkmingą atsiskaitymo projektą su transformacijos programomis Deutsche Telekom, Svyazcom, Vodafone India, tai stebėtinai dinamiškas ir kūrybiškas. Įgyvendinant šį projektą buvo pakeista ne tik „MegaFon“ ir jo struktūra, bet ir Mail.ru atsirado „Tarantool“ įmonė, o mūsų pardavėjas „Nexign“ (buvęs „Peter-Service“) – „BSS Box“ (dėžutinio atsiskaitymo sprendimas).
Tai tam tikra prasme istorinis projektas Rusijos rinkai. Tai galima palyginti su tuo, kas aprašyta Fredericko Brookso knygoje „Mitinis žmogaus mėnuo“. Tada, septintajame dešimtmetyje, IBM pasamdė 60 žmonių, kad sukurtų naują OS/360 operacinę sistemą, skirtą dideliems kompiuteriams. Turime mažiau – 5, bet mūsiškiai su liemenėmis, o atsižvelgiant į atvirojo kodo naudojimą ir naujus požiūrius, dirbame produktyviau.
Žemiau pateikiamos atsiskaitymo arba, plačiau kalbant, verslo sistemų sritys. Įmonės žmonės labai gerai išmano CRM. Kiekvienas jau turėtų turėti kitas sistemas: Open API, API Gateway.
Atidaryti API
Dar kartą pažvelkime į skaičius ir kaip šiuo metu veikia Open API. Jo apkrova yra 10 000 operacijų per sekundę. Kadangi planuojame aktyviai plėtoti mikropaslaugų sluoksnį ir kurti MegaFon viešąją API, ateityje tikimės didesnio šios dalies augimo. Tikrai bus 100 000 sandorių.
Nežinau, ar galime palyginti su Mail.ru SSO - atrodo, kad vaikinai atlieka 1 000 0000 operacijų per sekundę. Jų sprendimas mums labai įdomus, todėl planuojame perimti jų patirtį – pavyzdžiui, sukurti funkcinę SSO atsarginę kopiją naudojant Tarantool. Dabar Mail.ru kūrėjai tai daro už mus.
CRM
CRM yra tie patys 80 milijonų prenumeratorių, kuriuos norime padidinti iki milijardo, nes jau yra 300 milijonų dokumentų, apimančių trejų metų istoriją. Labai laukiame naujų paslaugų ir čia augimo taškas yra prijungtos paslaugos. Tai kamuolys, kuris augs, nes paslaugų bus vis daugiau. Atitinkamai, mums reikės istorijos; nenorime dėl to suklupti.
Pats atsiskaitymas sąskaitų faktūrų išrašymo požiūriu, darbas su klientų gautinomis sumomis paverčiamas atskira domenu. Norėdami pagerinti našumą, taikomosios srities architektūros architektūrinis modelis.
Sistema suskirstyta į domenus, paskirstoma apkrova ir užtikrinama gedimų tolerancija. Be to, dirbome su paskirstyta architektūra.
Visa kita yra įmonės lygio sprendimai. Skambučių saugykloje - 2 milijardai per dieną, 60 mlrd. per mėnesį. Kartais tenka juos skaičiuoti per mėnesį, o geriau greitai. Finansinė stebėsena – tai lygiai tie patys 300 milijonų, kurie nuolat auga ir auga: abonentai dažnai bėgioja tarp operatorių, didindami šią dalį.
Labiausiai telekomunikacinis mobiliojo ryšio komponentas yra internetinis tarifikavimas. Tai sistemos, kurios leidžia skambinti ar neskambinti, priimti sprendimus realiu laiku. Čia apkrova yra 30 000 operacijų per sekundę, tačiau atsižvelgiant į duomenų perdavimo augimą, planuojame 250 000 sandorių, todėl mus labai domina Tarantool.
Ankstesnė nuotrauka yra domenai, kuriuose ketiname naudoti Tarantool. Žinoma, pats CRM yra platesnis ir mes ketiname jį naudoti pačiame branduolyje.
Manoma, kad mūsų TTX prenumeratorių skaičius yra 100 milijonų, mane, kaip architektą, klaidina – o jei 101 milijonas? Ar reikia viską daryti iš naujo? Kad taip nenutiktų, naudojame talpyklas, tuo pačiu didindami pasiekiamumą.
Apskritai, yra du Tarantool naudojimo būdai. Pirmas - sukurti visas talpyklas mikro paslaugų lygiu. Kiek suprantu, VimpelCom eina šiuo keliu, kurdamas klientų talpyklą.
Esame mažiau priklausomi nuo tiekėjų, keičiame BSS branduolį, todėl turime vieną kliento failą. Bet mes norime jį išplėsti. Todėl mes laikomės šiek tiek kitokio požiūrio - sukurti talpyklas sistemų viduje.
Taip yra mažiau sinchronizavimo – viena sistema atsakinga ir už talpyklą, ir už pagrindinį pagrindinį šaltinį.
Metodas puikiai dera su Tarantool metodu su sandorio skeletu, kai atnaujinamos tik dalys, kurios yra susijusios su atnaujinimais, ty su duomenų pakeitimais. Visa kita galima laikyti kur nors kitur. Nėra didžiulio duomenų ežero, nevaldomos pasaulinės talpyklos. Talpyklos yra skirtos sistemai, produktams, klientams arba palengvinti priežiūrą. Kai abonentas skambina ir yra nusiminęs dėl jūsų paslaugos kokybės, jūs norite teikti kokybiškas paslaugas.
RTO ir RPO
IT yra du terminai - OTR и RPO.
Atkūrimo laiko tikslas yra laikas, kurio reikia paslaugai atkurti po gedimo. RTO = 0 reiškia, kad net jei kažkas nepavyksta, paslauga ir toliau veikia.
Atkūrimo taško tikslas – tai duomenų atkūrimo laikas, kiek duomenų galime prarasti per tam tikrą laikotarpį. RPO = 0 reiškia, kad neprarandame duomenų.
Tarantolio užduotis
Pabandykime išspręsti Tarantool problemą.
Duota: visiems suprantamų programų krepšelis, pavyzdžiui, „Amazon“ ar kur kitur. reikia kad pirkinių krepšelis veiktų 24 valandas 7 dienas per savaitę arba 99,99 % laiko. Pas mus gaunami užsakymai turi išlikti tvarkingi, nes negalime atsitiktinai įjungti ar išjungti abonento ryšio – viskas turi būti griežtai nuosekli. Ankstesnė prenumerata turi įtakos kitam, todėl duomenys yra svarbūs – nieko neturėtų dingti.
sprendimas. Galite pabandyti tai išspręsti tiesiai ir paklausti duomenų bazės kūrėjų, tačiau problemos negalima išspręsti matematiškai. Galite prisiminti teoremas, išsaugojimo dėsnius, kvantinę fiziką, bet kodėl - to negalima išspręsti DB lygiu.
Čia veikia senas geras architektūrinis požiūris – reikia gerai išmanyti dalykinę sritį ir ją panaudoti sprendžiant šį galvosūkį.
Mūsų sprendimas: sukurti paskirstytą programų registrą Tarantool – geografiškai paskirstytame klasteryje. Diagramoje tai yra trys skirtingi duomenų apdorojimo centrai – du prieš Uralą, vienas už Uralo, ir mes paskirstome visas užklausas tarp šių centrų.
„Netflix“, kuri dabar laikoma viena iš IT lyderių, iki 2012 m. turėjo tik vieną duomenų centrą. Katalikų Kalėdų išvakarėse, gruodžio 24 d., šis duomenų centras sustojo. Kanados ir JAV vartotojai liko be mėgstamų filmų, labai nusiminė ir apie tai rašė socialiniuose tinkluose. „Netflix“ dabar turi tris duomenų centrus vakarų-rytinėje pakrantėje ir vieną Vakarų Europoje.
Iš pradžių kuriame geografiškai paskirstytą sprendimą – mums svarbus atsparumas gedimams.
Taigi mes turime klasterį, bet kaip su RPO = 0 ir RTO = 0? Sprendimas yra paprastas, priklausomai nuo temos.
Kas svarbu programose? Dvi dalys: krepšelio mėtymas TO priimant sprendimą pirkti ir PO. DO dalis telekomunikacijoje paprastai vadinama užsakymo fiksavimas arba užsakymo derybos. Telekome tai gali būti daug sunkiau nei internetinėje parduotuvėje, nes ten klientas turi būti aptarnaujamas, pasiūlyti 5 variantai ir visa tai vyksta tam tikrą laiką, bet krepšelis užpildomas. Šiuo metu gedimas galimas, bet tai nėra baisu, nes tai vyksta interaktyviai, žmogui prižiūrint.
Jei Maskvos duomenų centras staiga suges, automatiškai persijungę į kitą duomenų centrą, dirbsime toliau. Teoriškai viena prekė gali būti pamesta krepšelyje, bet tai matai, vėl dedi į krepšelį ir dirbi toliau. Šiuo atveju RTO = 0.
Tuo pačiu metu yra ir antras variantas: paspaudę „pateikti“, norime, kad duomenys neprarastų. Nuo šio momento pradeda veikti automatika – tai yra RPO = 0. Naudojant šiuos du skirtingus šablonus, vienu atveju tai gali būti tiesiog geografiškai paskirstytas klasteris su vienu perjungiamu pagrindiniu kompiuteriu, kitu atveju kažkoks kvorumo įrašas. Modeliai gali skirtis, bet mes išsprendžiame problemą.
Be to, turėdami paskirstytą programų registrą, taip pat galime visa tai išplėsti – turime daug dispečerių ir vykdytojų, kurie prisijungia prie šio registro.
Cassandra ir Tarantool kartu
Yra dar vienas atvejis - „balansų vitrina“. Čia yra įdomus Cassandra ir Tarantool bendro naudojimo atvejis.
Mes naudojame „Cassandra“, nes 2 milijardai skambučių per dieną nėra riba, o jų bus daugiau. Rinkodaros specialistai mėgsta spalvinti srautą pagal šaltinį; pavyzdžiui, socialiniuose tinkluose pasirodo vis daugiau informacijos. Visa tai papildo istoriją.
„Cassandra“ leidžia keisti horizontalų mastelį iki bet kokio dydžio.
Su Cassandra jaučiamės patogiai, tačiau ji turi vieną problemą – ji nemoka skaityti. Su įrašu viskas gerai, 30 000 per sekundę nėra problema - skaitymo problema.
Todėl atsirado tema su talpykla ir tuo pačiu išsprendėme šią problemą: yra senas tradicinis atvejis, kai įranga perjungus nuo atsiskaitymo internetu patenka į failus, kuriuos įkeliame į Cassandra. Mes kovojome su patikimo šių failų atsisiuntimo problema, net pasinaudoję IBM tvarkyklės failų perdavimo patarimais – yra sprendimų, kurie efektyviai valdo failų perdavimą, naudojant, pavyzdžiui, UDP protokolą, o ne TCP. Tai gerai, bet tai dar minutės, o mes to dar neįkėlėme, operatorius skambučių centre negali atsakyti klientui, kas atsitiko su jo balansu - turime palaukti.
Kad taip nenutiktų, mes naudojame lygiagretų funkcinį rezervą. Kai siunčiame įvykį per Kafka į Tarantool, realiuoju laiku perskaičiuodami suvestinius duomenis, pavyzdžiui, šiandien, gauname grynųjų pinigų likučiai, kuris gali pervesti likučius bet kokiu greičiu, pavyzdžiui, 100 tūkstančių operacijų per sekundę ir tas pačias 2 sekundes.
Siekiama, kad po skambučio per 2 sekundes Jūsų asmeninėje paskyroje būtų ne tik pasikeitęs likutis, bet ir informacija, kodėl jis pasikeitė.
išvada
Tai buvo Tarantool naudojimo pavyzdžiai. Mums labai patiko Mail.ru atvirumas ir noras svarstyti skirtingus atvejus.
Konsultantams iš BCG ar McKinsey, Accenture ar IBM jau sunku mus nustebinti kažkuo nauju – daug ką jie siūlo, mes jau darome, esame padarę arba planuojame daryti. Manau, kad Tarantool užims deramą vietą mūsų technologijų krūvoje ir pakeis daugelį esamų technologijų. Esame aktyvioje šio projekto kūrimo fazėje.
Olego ir Andrejaus pranešimas yra vienas geriausių praėjusių metų Tarantool konferencijoje, o birželio 17 d. Olegas Ivlevas kalbės su ataskaita . Aleksandras Deulinas taip pat skaitys „MegaFon“ pristatymą . Sužinokime, kas pasikeitė, kokie planai įgyvendinti. Prisijunkite – konferencija nemokama, tereikia ... Viskas ir susiformavo konferencijos programa: nauji atvejai, nauja Tarantool naudojimo patirtis, architektūra, įmonė, pamokos ir mikropaslaugos.
Šaltinis: www.habr.com