Pse një korporatë si MegaFon ka nevojë për Tarantool për faturim? Nga jashtë, duket sikur një shitës zakonisht vjen, sjell një kuti të madhe, e lidh atë në prizë dhe ky është faturimi! Kështu ndodhte më parë, por tani është arkaik dhe dinosaurë të tillë ose janë zhdukur ose po zhduken. Fillimisht, faturimi ishte një sistem për faturimin - një rimë numërimi ose një kalkulator. Në telekomunikacionet moderne, është... një sistem për automatizimin e të gjithë ciklit jetësor të bashkëveprimit me pajtimtarin, nga lidhja e kontratës deri në përfundimin e saj, duke përfshirë faturimin në kohë reale, pranimin e pagesave dhe shumë më tepër. Faturimi në kompanitë e telekomunikacionit është si një robot luftarak - i madh, i fuqishëm dhe i armatosur me armë.
Çfarë lidhje ka Tarantool me këtë? Kjo do të shpjegohet. Oleg Ivlev и Andrey KnyazevOleg është arkitekti kryesor i kompanisë. Me përvojë të gjerë pune për kompani ndërkombëtare, Andrey është Drejtor i Sistemeve të Biznesit. Nga transkripti i prezantimit të tyre në Do të mësoni pse kërkimi dhe zhvillimi është i nevojshëm në korporata, çfarë është Tarantool, si ngërçi i shkallëzimit vertikal dhe globalizimit u bë parakusht për shfaqjen e kësaj baze të dhënash në kompani, rreth sfidave teknologjike, transformimit arkitektonik dhe si grupi teknologjik i MegaFon është i ngjashëm me Netflix, Google dhe Amazon.
Projekti i Faturimit të Unifikuar
Projekti që do të diskutojmë quhet "Faturim i Unifikuar". Pikërisht këtu shkëlqen vërtet Tarantool.
Performanca e pajisjeve të nivelit të lartë nuk po ecte në ritmin e rritjes së bazës së abonentëve dhe numrit të shërbimeve. Pritej një rritje e mëtejshme e abonentëve dhe shërbimeve për shkak të M2M dhe IoT, dhe natyra e sistemit e bazuar në degë po çonte në një përkeqësim të kohës në treg. Kompania vendosi të krijonte një sistem të unifikuar biznesi me një arkitekturë modulare unike, të klasit botëror, për të zëvendësuar tetë sisteme të ndryshme aktuale faturimi.
MegaFon është tetë kompani në njëNë vitin 2009, riorganizimi u përfundua: degët në të gjithë Rusinë u bashkuan në një kompani të vetme, MegaFon OJSC (tani PJSC). Kështu, kompania bleu tetë sisteme faturimi me zgjidhjet e tyre të personalizuara, veçoritë specifike të degëve dhe strukturat e dallueshme organizative, ekipet e IT-së dhe marketingut.
Gjithçka ishte në rregull derisa na u desh të lançonim një produkt të vetëm federal të unifikuar. Kjo krijoi një mori ndërlikimesh: disa kishin tarifa që rrumbullakoseshin lart, disa poshtë dhe të tjera të bazuara në mesataren aritmetike. Ka mijëra çështje të tilla.
Pavarësisht faktit që kishim të njëjtin version të sistemit të faturimit dhe të njëjtin shitës, cilësimet ishin aq të paqëndrueshme saqë na u desh shumë kohë për t'i përshtatur ato. U përpoqëm të zvogëlonim numrin e cilësimeve dhe hasëm një problem të dytë, të njohur për shumë korporata.
Shkallëzimi vertikalEdhe pajisjet më të përparuara të disponueshme në atë kohë nuk i plotësonin nevojat e kompanisë. Ata përdornin pajisje Hewlett-Packard nga linja Superdome Hi-End, por ato nuk mund të përballonin nevojat as të dy degëve. Ata donin të shkallëzoheshin horizontalisht pa pasur kosto të mëdha operative dhe investime kapitale.
Rritja e pritur e numrit të abonentëve dhe shërbimeveKonsulentët kanë kohë që sjellin histori rreth IoT dhe M2M në botën e telekomunikacionit: do të vijë koha kur çdo telefon dhe hekur do të ketë një kartë SIM, dhe çdo frigorifer do të ketë dy. Sot, kemi të njëjtin numër abonentësh, por në të ardhmen e afërt, do të ketë shumë më tepër.
Sfidat teknologjike
Këta katër faktorë na motivuan të bënim ndryshime të rëndësishme. Na u desh të zgjidhnim midis modernizimit të sistemit dhe projektimit të tij nga e para. Menduam gjatë dhe me kujdes, morëm vendime serioze dhe konkurruam për tendera. Në fund, vendosëm ta projektonim nga e para dhe u përballëm me sfida interesante - ato teknologjike.
Shkallëzueshmëria
Nëse ka qenë më parë, le të themi, 8 sisteme faturimi me nga 15 milionë abonentë secili, dhe tani duhet të kishte funksionuar 100 milionë abonentë dhe më shumë — ngarkesa është një rend madhësie më e lartë.
Ne jemi bërë të krahasueshëm në shkallë me lojtarët kryesorë të internetit si Mail.ru ose Netflix.
Por lëvizja e mëtejshme drejt rritjes së ngarkesës dhe bazës së pajtimtarëve na paraqiti sfida serioze.
Gjeografia e vendit tonë të gjerë
Midis Kaliningradit dhe Vladivostokut 7500 km dhe 10 zona kohoreShpejtësia e dritës është e kufizuar dhe në distanca të tilla, vonesat janë të konsiderueshme. 150 ms në lidhjet optike më të shpejta moderne është shumë për çmimet në kohë reale, veçanërisht lloji që përdoret aktualisht në telekomunikacionet ruse. Për më tepër, përditësimet duhet të përfundojnë brenda një dite pune, gjë që është një sfidë me zona të ndryshme kohore.
Ne nuk ofrojmë shërbime vetëm për një tarifë abonimi; kemi plane, paketa dhe modifikues të ndryshëm kompleksë. Nuk duhet vetëm t'u lejojmë ose bllokojmë abonentëve të flasin, por t'u caktojmë atyre një kuotë specifike - të llogarisim thirrjet dhe veprimet në kohë reale pa e vënë re ata.
toleranca ndaj gabimeve
Kjo është ana negative e centralizimit.
Nëse i bashkojmë të gjithë abonentët në një sistem të vetëm, çdo emergjencë ose fatkeqësi do të ishte katastrofike për biznesin. Prandaj, ne e projektojmë sistemin për të eliminuar ndikimin e emergjencave në të gjithë bazën e abonentëve.
Kjo është, përsëri, një pasojë e braktisjes së shkallëzimit vertikal. Kur kaluam në shkallëzimin horizontal, rritëm numrin e serverave nga qindra në mijëra. Ata duhen menaxhuar, duhet të ndërtohet ndërrueshmëria e tyre, të ruhet automatikisht një kopje rezervë e infrastrukturës IT dhe të rivendoset sistemi i shpërndarë.
U përballëm me sfida kaq interesante. Ne e projektuam sistemin dhe në atë pikë u përpoqëm të gjenim praktikat më të mira globale për të testuar se sa në trend ishim, sa nga afër i ndiqnim teknologjitë më të përparuara.
Përvoja botërore
Çuditërisht, nuk gjetëm asnjë referencë në industrinë globale të telekomunikacionit.
Evropa ishte jashtë diskutimit për shkak të numrit dhe shkallës së abonentëve, dhe SHBA-ja për shkak të përballueshmërisë së tarifave të saj. Ata shikuan disa gjëra në Kinë dhe gjetën të tjera në Indi, duke i shtyrë ata të punësonin specialistë nga Vodafone India.
Për të analizuar arkitekturën, ne krijuam një Ekip Ëndrrash të udhëhequr nga IBM - arkitektë nga fusha të ndryshme. Këta njerëz ishin në gjendje të vlerësonin në mënyrë adekuate atë që po bënim dhe të kontribuonin me njohuri specifike në arkitekturën tonë.
shkallë
Disa shifra për ilustrim.
Ne e projektojmë sistemin për 80 milionë abonentë me një miliard rezervëKështu i heqim barrierat e së ardhmes. Kjo nuk ndodh sepse po planifikojmë të pushtojmë Kinën, por për shkak të sulmit të madh të IoT dhe M2M.
300 milionë dokumente përpunohen në kohë realeEdhe pse kemi 80 milionë abonentë, ne punojmë edhe me klientë potencialë dhe me ata që na kanë lënë kur na duhet të mbledhim llogaritë e arkëtueshme. Prandaj, vëllimi real është dukshëm më i lartë.
2 miliardë transaksione Bilanci ndryshon çdo ditë - këto janë pagesa, llogaritje, thirrje dhe ngjarje të tjera. 200 TB të dhëna po ndryshojnë në mënyrë aktive, ndrysho pak më ngadalë 8 PB të dhëna, dhe ky nuk është një arkiv, por të dhëna të drejtpërdrejta në një sistem të vetëm faturimi. Shkalla në të gjitha qendrat e të dhënave është 5 servera në 14 faqe interneti.
Stack i teknologjisë
Kur planifikuam arkitekturën dhe filluam ndërtimin e sistemit, importuam teknologjitë më interesante dhe më të përparuara. Rezultati ishte një grumbull teknologjish i njohur për çdo lojtar interneti dhe korporata që ndërtojnë sisteme me ngarkesë të lartë.
Grupi është i ngjashëm me atë të lojtarëve të tjerë të mëdhenj: Netflix, Twitter, Viber. Ai përbëhet nga gjashtë komponentë, por ne duam ta reduktojmë dhe standardizojmë atë.
Fleksibiliteti është i mirë, por në një korporatë të madhe nuk ka rrugë pa bashkim.
Ne nuk planifikojmë ta zëvendësojmë Oracle me Tarantool. Për kompanitë e mëdha, kjo është një utopi, ose një kryqëzatë 5-10-vjeçare me një rezultat të pasigurt. Por Cassandra dhe Couchbase me siguri mund të zëvendësohen me Tarantool, dhe kjo është ajo për të cilën po punojmë.
Pse pikërisht Tarantool?
Ekzistojnë 4 kritere të thjeshta pse zgjodhëm këtë bazë të dhënash.
ShpejtësiNe kryem teste ngarkese në sistemet industriale të MegaFon. Tarantool doli fitimtar, duke demonstruar performancë superiore.
Nuk është se sistemet e tjera nuk i plotësojnë nevojat e MegaFon. Zgjidhjet aktuale të memories janë aq të fuqishme sa kompania ka hapësirë të mjaftueshme. Por ne jemi të interesuar të punojmë me një lider, jo me dikë që mbetet prapa, përfshirë testimin e ngarkesës.
Tarantool plotëson nevojat e kompanisë edhe në planin afatgjatë.
Kostoja TCOMbështetja e Couchbase në vëllimet e MegaFon është tepër e kushtueshme, ndërsa Tarantool është shumë më i përshtatshëm dhe funksionaliteti i tyre është i ngjashëm.
Një tjetër veçori e mirë që ndikoi paksa në zgjedhjen tonë është se Tarantool e trajton memorien më mirë se bazat e të dhënave të tjera. Kjo tregon efikasitet maksimal.
SeriozitetMegaFon investon në besueshmëri ndoshta më shumë se kushdo tjetër. Pra, kur pamë Tarantool-in, e dinim se duhej ta bënim që të përmbushte kërkesat tona.
Ne investuam kohën dhe paratë tona, dhe së bashku me Mail.ru, krijuam një version për ndërmarrje, i cili tani përdoret nga disa kompani të tjera.
Tarantool-enterprise na kënaqi plotësisht për sa i përket sigurisë, besueshmërisë dhe regjistrimit të të dhënave.
Partneriteti
Gjëja më e rëndësishme për mua është kontakt i drejtpërdrejtë me zhvilluesinKjo është pikërisht ajo me të cilën na korruptuan djemtë nga Tarantooli.
Nëse i afrohesh një lojtari, veçanërisht një lojtari që punon me një klient kryesor, dhe i thua se të duhet baza e të dhënave që të jetë në gjendje të bëjë këtë, këtë dhe këtë, ai zakonisht përgjigjet:
- Në rregull, vendosi kërkesat në fund të asaj grumbulli - ndoshta do t'i përmbushim një ditë.
Shumë kompani kanë një plan veprimi për dy-tre vitet e ardhshme dhe është praktikisht e pamundur të integrohen në të. Por zhvilluesit e Tarantool po na fitojnë me hapjen e tyre, dhe jo vetëm me MegaFon, dhe ata e përshtatin sistemin e tyre sipas klientit. Kjo është fantastike dhe na pëlqen shumë.
Ku e përdorëm Tarantool-in
Ne përdorim Tarantool në disa elementë. E para është në pilot, të cilin e ndërtuam mbi sistemin e drejtorive të adresave. Në atë kohë, donim që të ishte një sistem i ngjashëm me Yandex.Maps dhe Google Maps, por doli disi ndryshe.
Për shembull, merrni direktorinë e adresave në ndërfaqen e shitjeve. Në Oracle, gjetja e adresës së kërkuar zgjat 12-13 sekonda - një shifër e pafavorshme. Kur kalojmë në Tarantool, zëvendësojmë Oracle me një bazë të dhënash të ndryshme në tastierë dhe kryejmë të njëjtin kërkim, marrim një shpejtësi 200-fish! Qyteti shfaqet pas shkronjës së tretë. Aktualisht po e përshtatim ndërfaqen në mënyrë që të shfaqet pas të parës. Megjithatë, koha e përgjigjes është dukshëm më e shpejtë - tani milisekonda në vend të sekondave.
Aplikacioni i dytë është një temë në modë e quajtur IT me dy shpejtësi.Kjo ndodh sepse konsulentë nga çdo cep i botës po u thonë korporatave se duhet të shkojnë atje.
Ekziston një shtresë infrastrukture, dhe mbi të janë domene, të tilla si një sistem faturimi si një telekomunikacion, sistemet e korporatave dhe raportimi i korporatave. Ky është thelbi, i cili nuk duhet prekur. Kjo është, sigurisht, e mundur, por paranojake për sigurimin e cilësisë, sepse është ajo që i sjell para korporatës.
Më pas vjen shtresa e mikroshërbimeve - ajo që dallon një operator ose një lojtar tjetër. Mikroshërbimet mund të krijohen shpejt bazuar në memorje të caktuara të përkohshme, duke integruar të dhëna nga domene të ndryshme. fushë për eksperimente Nëse diçka nuk funksionon, unë mbyll një mikroshërbim dhe lançoj një tjetër. Kjo siguron një kohë vërtet të rritur në treg dhe rrit besueshmërinë dhe shpejtësinë e kompanisë.
Mikroshërbimet janë ndoshta roli kryesor i Tarantool në MegaFon.
Ku planifikojmë të përdorim Tarantool
Krahasuar me programet e transformimit në Deutsche Telekom, Svyazkom dhe Vodafone India, projekti ynë i suksesshëm i faturimit është jashtëzakonisht dinamik dhe krijues. Ky projekt jo vetëm që transformoi MegaFon dhe strukturën e saj, por çoi edhe në zhvillimin e Tarantool Enterprise në Mail.ru dhe lançimin e BSS Box (një zgjidhje faturimi e paketuar plotësisht) te shitësi ynë, Nexign (më parë Peter-Service).
Ky është, në një farë mënyre, një projekt historik për tregun rus. Mund të krahasohet me atë që përshkruhet në librin e Frederick Brooks "Muaji Mitik i Njeriut". Në atë kohë, në vitet 1960, IBM punësoi 5,000 njerëz për të zhvilluar sistemin e ri operativ OS/360 për mainframe-t. Ne kemi më pak - 1,800 - por ne jemi ata që veshim bluza me vija, dhe duke pasur parasysh përdorimin tonë të burimit të hapur dhe qasjeve të reja, jemi më produktivë.
Më poshtë janë domenet për faturim, ose më gjerësisht, për sistemet e biznesit. Përdoruesit e ndërmarrjeve janë të njohur mirë me CRM. Sisteme të tjera duhet të jenë tashmë në përdorim nga të gjithë: Open API, API Gateway.
Hap API
Le t'i shohim përsëri numrat dhe të shohim se si po funksionon aktualisht Open API. Ngarkesa e saj është 10,000 transaksione për sekondëMeqenëse planifikojmë të zhvillojmë në mënyrë aktive shtresën e mikroshërbimeve dhe të ndërtojmë API-në publike të MegaFon, presim një rritje më të madhe në këtë fushë në të ardhmen. Me siguri do të ketë 100,000 transaksione.
Nuk e di nëse mund të krahasohemi me performancën SSO të Mail.ru—me sa duket ata po trajtojnë 1,000,0000 transaksione në sekondë. Ne jemi jashtëzakonisht të interesuar në zgjidhjen e tyre dhe planifikojmë të përvetësojmë përvojën e tyre—për shembull, duke zbatuar një kopje rezervë funksionale për SSO duke përdorur Tarantool. Zhvilluesit e Mail.ru po punojnë aktualisht për këtë për ne.
CRM
CRM është i njëjti numër prej 80 milionë abonentësh që duam të arrijmë në një miliard, sepse tashmë kemi 300 milionë dokumente që mbulojnë tre vjet histori. Ne mezi presim shërbime të reja, dhe këtu Pika e rritjes është shërbimet e lidhuraKjo është një sferë që do të rritet ndërsa shtohen gjithnjë e më shumë shërbime. Si pasojë, do të nevojitet një historik dhe nuk duam të pengohemi në këtë drejtim.
Faturimi vetë në aspektin e faturimit dhe puna me llogaritë e arkëtueshme të klientëve transformuar në një domen të veçantëPër të rritur produktivitetin, modeli i arkitekturës së domenit u aplikua.
Sistemi është i ndarë në domene, ngarkesa është e shpërndarë dhe toleranca ndaj gabimeve është e siguruar. Përveç kësaj, u krye punë në arkitekturën e shpërndarë.
Çdo gjë tjetër është zgjidhje në nivel ndërmarrjeje. Në ruajtjen e thirrjeve - 2 miliardë në ditë, 60 miliardë në muaj. Ndonjëherë duhet t'i rillogaritësh ato çdo muaj, dhe është më mirë ta bësh shpejt. Monitorimi financiar — këto janë pikërisht ato 300 milionë që janë vazhdimisht në rritje: pajtimtarët shpesh kalojnë midis operatorëve, duke rritur këtë pjesë.
Komponenti më telekomunikues i komunikimeve mobile është çmimet onlineKëto janë sistemet që ju lejojnë të telefononi ose jo, duke marrë vendime në kohë reale. Ngarkesa këtu është 30,000 transaksione në sekondë, por duke pasur parasysh rritjen e transferimit të të dhënave, ne planifikojmë të 250,000 transaksione, dhe për këtë arsye ne jemi shumë të interesuar për Tarantool-in.
Imazhi i mëparshëm tregon domenet ku planifikojmë të përdorim Tarantool. Sigurisht, vetë CRM është më i gjerë dhe planifikojmë ta përdorim atë në bërthamë.
Shifra jonë e vlerësuar e performancës prej 100 milionë abonentësh në vit më huton si arkitekt - po sikur të jenë 101 milionë? A duhet ta ribëjmë gjithçka përsëri? Për ta parandaluar këtë, po përdorim memorje të përkohshme, duke rritur njëkohësisht disponueshmërinë.
Në përgjithësi ka dy qasje për përdorimin e Tarantool. E para është ndërto të gjitha memorjet e përkohshme në nivelin e mikroservisitPër aq sa kuptoj unë, VimpelCom po ndjek këtë rrugë duke krijuar një memorje të përkohshme për klientët.
Ne jemi më pak të varur nga shitësit dhe po ndryshojmë thelbin e BSS, kështu që tashmë kemi një bazë të dhënash të unifikuar të klientëve që në fillim. Por duam ta zgjerojmë atë. Pra, po ndjekim një qasje paksa të ndryshme— Ne krijojmë memorje të fshehta brenda sistemeve.
Kjo zvogëlon desinkronizimin - një sistem është përgjegjës si për memorien e përkohshme ashtu edhe për burimin kryesor master.
Kjo metodë përshtatet mirë me qasjen e skeletit transaksional të Tarantool, ku përditësohen vetëm pjesët që merren me përditësimet, d.m.th., ndryshimet e të dhënave. Çdo gjë tjetër mund të ruhet diku tjetër. Nuk ka liqen të madh të dhënash ose memorje të përkohshme globale të pamenaxhuar. Memorjet e përkohshme janë të dizajnuara për sistemin, për produktet, për klientët ose për ta bërë jetën më të lehtë për ofruesit e shërbimeve. Kur një telefonues telefonon i frustruar, ju doni t'i ofroni atij shërbim cilësor.
RTO dhe RPO
Në IT ekzistojnë dy terma - OTR и RPO.
Objektivi i kohës së rikuperimit — kjo është koha që i duhet një shërbimi për t'u rikuperuar pas një dështimi. RTO = 0 do të thotë që edhe nëse diçka shkon keq, shërbimi vazhdon të funksionojë.
Objektivi i pikës së rikuperimit — kjo është koha e rikuperimit të të dhënave, d.m.th., sa të dhëna mund të presim të humbasim gjatë një periudhe të caktuar kohore. RPO = 0 do të thotë që nuk humbasim asnjë të dhënë.
Detyra e Tarantoolit
Le të përpiqemi ta zgjidhim problemin për Tarantool.
E dhënënjë shportë blerjesh e pastër, si në Amazon ose diku tjetër. i nevojshëm Për të siguruar që shporta e blerjeve të funksionojë 24/7, ose 99,99% të kohës. Porositë që marrim duhet të jenë të organizuara, pasi nuk mund t'i aktivizojmë ose çaktivizojmë rastësisht lidhjet e pajtimtarëve - gjithçka duhet të jetë në një rend të rreptë. Abonimi i mëparshëm ndikon në atë pasardhës, kështu që të dhënat janë të rëndësishme - asgjë nuk duhet të humbasë.
vendimMund të përpiqesh ta zgjidhësh drejtpërdrejt dhe t’ua bësh këtë pyetje zhvilluesve të bazave të të dhënave, por problemi është matematikisht i pazgjidhshëm. Mund të kujtosh teorema, ligjet e ruajtjes dhe fizikën kuantike, por cili është qëllimi? Është e pamundur të zgjidhet në nivelin e bazës së të dhënave.
Qasja e mirë e vjetër arkitekturore hyn në lojë këtu: duhet të keni një kuptim të mirë të fushës lëndore dhe ta përdorni atë për të zgjidhur këtë enigmë.
Zgjidhja jonë: krijimi i një regjistri të shpërndarë të aplikacioneve në Tarantool – një klaster i shpërndarë gjeografikishtNë diagram, ekzistojnë tre qendra të ndryshme të përpunimit të të dhënave - dy brenda Uraleve, një përtej Uraleve - dhe ne i shpërndajmë të gjitha kërkesat nëpër këto qendra.
Netflix, që tani konsiderohet si lider në IT, kishte vetëm një qendër të dhënash deri në vitin 2012. Në prag të Krishtlindjeve, më 24 dhjetor, kjo qendër e të dhënave u ndal. Përdoruesit në Kanada dhe SHBA mbetën pa filmat e tyre të preferuar, u mërzitën thellësisht dhe përdorën mediat sociale për të ndarë mendimet e tyre. Netflix tani ka tre qendra të dhënash në Bregun Perëndimor dhe Bregun Lindor, dhe një në Evropën Perëndimore.
Ne po ndërtojmë një zgjidhje të shpërndarë gjeografikisht që nga fillimi - toleranca ndaj gabimeve është e rëndësishme për ne.
Pra, kemi një klaster, por çfarë ndodh nëse RPO = 0 dhe RTO = 0? Zgjidhja është e thjeshtë dhe varet nga tema.
Çfarë është e rëndësishme në aplikime? Dy pjesë: përgatitja e një shporte tO marrjen e një vendimi blerjeje, dhe PASPjesa DO në telekomunikacion zakonisht quhet kapja e porosive ose negocim porosieNë telekomunikacion, kjo mund të jetë shumë më e vështirë sesa në një dyqan online, sepse atje duhet t'i shërbesh klientit, të ofrosh pesë opsione dhe e gjithë kjo kërkon pak kohë, por shporta është e mbushur. Në këtë pikë, një gabim është i mundur, por nuk është ndonjë problem i madh sepse ndodh në mënyrë interaktive nën mbikëqyrjen e njeriut.
Nëse qendra e të dhënave në Moskë papritmas ndalon së funksionuari, ne automatikisht do të kalojmë në një qendër tjetër të dhënash dhe do të vazhdojmë operacionet. Teorikisht, një produkt mund të humbasë në shportën tuaj të blerjeve, por ju do ta vini re, do ta rimbushni shportën dhe do të vazhdoni operacionet. Në këtë rast, RTO = 0.
Në të njëjtën kohë, ekziston një opsion i dytë: kur klikojmë "dërgo", duam të sigurohemi që të dhënat nuk humbasin. Nga kjo pikë e tutje, fillon automatizimi - që është RPO = 0. Zbatimi i këtyre dy modeleve të ndryshme: në një rast, mund të jetë thjesht një grumbull i shpërndarë gjeografikisht me një master të vetëm failover, në tjetrin, një lloj shkrimi kuorum. Modelet mund të ndryshojnë, por ne po e zgjidhim problemin.
Për më tepër, duke pasur një regjistër të shpërndarë të kërkesave, ne gjithashtu mund ta shkallëzojmë të gjithë këtë - të kemi shumë dispeçerë dhe interpretues që qasen në këtë regjistër.
Kasandra dhe Tarantooli së bashku
Ka edhe një rast tjetër - pasqyrë e bilancitKy është një rast interesant i përdorimit të Cassandra-s dhe Tarantool-it së bashku.
Ne përdorim Cassandra sepse 2 miliardë thirrje në ditë nuk është limiti, dhe do të ketë më shumë. Tregtarët pëlqejnë ta ngjyrosin trafikun sipas burimit, dhe ka gjithnjë e më shumë detaje që vijnë nga mediat sociale, për shembull. E gjithë kjo e bën historinë më të pasur.
Cassandra ju lejon të shkallëzoni horizontalisht në çdo vëllim.
Ndihemi rehat me Cassandrën, por ka një problem: nuk është shumë e mirë në lexim. Shkrimi është i mirë; 30,000 në sekondë nuk është problem. problem me leximin.
Pra, doli problemi i memorjes së përkohshme (cache) dhe ne zgjidhëm gjithashtu problemin e mëposhtëm: ekziston një rast i hershëm ku pajisjet nga një central elektrik, për shkak të faturimit online, përfundonin në skedarët që ne ngarkojmë në Cassandra. Ne e trajtuam çështjen e ngarkimit të besueshëm të këtyre skedarëve, madje duke ndjekur rekomandimin e IBM, duke përdorur menaxherin e transferimit të skedarëve - ka zgjidhje që menaxhojnë transferimet e skedarëve në mënyrë efikase, duke përdorur UDP, për shembull, në vend të TCP. Kjo është mirë, por prapëseprapë duhen disa minuta, dhe derisa të kemi ngarkuar gjithçka, operatori i qendrës së thirrjeve nuk mund t'i tregojë klientit se çfarë ka ndodhur me bilancin e tyre - ata duhet të presin.
Për të parandaluar që kjo të ndodhë, ne Ne përdorim rezervën funksionale paraleleKur dërgojmë një ngjarje nëpërmjet Kafka-s te Tarantool, duke rillogaritur agregatet në kohë reale, për shembull, për sot, marrim balancat e parave të gatshme, e cila mund të japë balanca me çdo shpejtësi, për shembull, 100 mijë transaksione në sekondë dhe të njëjtat 2 sekonda.
Qëllimi është të sigurohet që brenda 2 sekondave nga kryerja e një telefonate, llogaria juaj personale jo vetëm që do të tregojë bilancin e ndryshuar, por edhe informacionin se pse ai ndryshoi.
Përfundim
Këto ishin shembuj të rasteve të përdorimit të Tarantool. Ne mbetëm shumë të impresionuar nga hapja dhe gatishmëria e Mail.ru për të marrë në konsideratë raste të ndryshme përdorimi.
Konsulentët nga BCG, McKinsey, Accenture ose IBM po e kanë të vështirë të na surprizojnë me diçka të re - ne tashmë kemi bërë, zbatuar ose po planifikojmë të bëjmë shumë nga ato që ofrojnë ata. Unë besoj se Tarantool do të zërë vendin që i takon në teknologjinë tonë dhe do të zëvendësojë shumë teknologji ekzistuese. Ne po e zhvillojmë në mënyrë aktive këtë projekt.
Prezantimi i Oleg dhe Andrey ishte një nga më të mirat në Konferencën Tarantool vitin e kaluar, dhe më 17 qershor, Oleg Ivlev do të flasë në me një raport Alexander Deulin do të prezantojë gjithashtu një reportazh nga MegaFon. Le të zbulojmë se çfarë ka ndryshuar dhe cilat plane janë zbatuar. Bashkohuni me ne - konferenca është falas, e tëra çfarë duhet të bëni është ... Të gjitha dhe programi i konferencës është i plotë: raste të reja, përvoja të reja duke përdorur Tarantool, arkitekturë, ndërmarrje, tutoriale dhe mikroshërbime.
Burimi: www.habr.com
