Zergatik behar du MegaFon bezalako korporazio batek Tarantool fakturazioan? Kanpotik badirudi saltzailea etortzen dela normalean, kutxa handi bat ekartzen duela, entxufea entxufean sartzen duela, eta hori fakturazioa da! Garai batean hala zen, baina orain arkaikoa da, eta horrelako dinosauroak dagoeneko desagertu egin dira edo desagertzen ari dira. Hasieran, fakturazioa fakturak igortzeko sistema bat da: zenbatzeko makina edo kalkulagailua. Telekomunikazio modernoetan hau da automatizazio sistema harpidedun batekin elkarreraginaren bizitza-ziklo osorako, kontratua sinatzen denetik amaitu arte, denbora errealeko fakturazioa, ordainketa onartzea eta askoz gehiago barne. Telekomunikazio enpresetan fakturazioa borroka-robot bat bezalakoa da: handia, indartsua eta armaz betea.
Zer zerikusi du Tarantool-ek? Horretaz hitz egingo dute Oleg Ivlev и Andrei Knyazev. Oleg konpainiako arkitekto nagusia da atzerriko enpresetan lan egiten duen esperientzia handia du, Andrey negozio sistemen zuzendaria da. Beraien txostenaren transkripziotik korporazioetan I+G zergatik behar den, Tarantool zer den, nola eskalatze bertikalaren eta globalizazioaren impasse-a enpresan datu-base hau agertzeko ezinbesteko baldintza bihurtu zen, erronka teknologikoei, eraldaketa arkitektonikoari buruz eta MegaFon-en technostack-a Netflix-en antzekoa nolakoa den ikasiko duzu. , Google eta Amazon.
"Fakturazio bateratua" proiektua
Aipatutako proiektuari “Fakturazio bateratua” deitzen zaio. Hemen erakutsi zituen Tarantool-ek bere ezaugarri onenak.
Hi-End ekipoen produktibitatearen hazkundeak ez zuen harpidedun oinarriaren hazkundearekin eta zerbitzu kopuruaren hazkundearekin jarraitu; harpidedunen eta zerbitzuen kopuruaren hazkunde gehiago espero zen M2M, IoT eta sukurtsalen ezaugarriengatik. merkaturatzeko denbora hondatzeari. Konpainiak mundu mailako arkitektura modular berezi batekin negozio sistema bateratu bat sortzea erabaki zuen, egungo 8 fakturazio sistema ezberdinen ordez.
MegaFon zortzi enpresa bat dira. 2009an, berrantolaketa amaitu zen: Errusia osoko sukurtsalak konpainia bakarrean batu ziren, MegaFon OJSC (gaur egun PJSC). Horrela, konpainiak 8 fakturazio sistema ditu bere soluzio “pertsonalizatuak”, sukurtsalen ezaugarriak eta antolakuntza-egitura desberdinak, informatika eta marketina.
Dena ondo zegoen produktu federal komun bat martxan jarri behar izan genuen arte. Hemen zailtasun asko sortu ziren: batzuentzat tarifak gora biribiltzen dira, beste batzuentzat behera biribiltzen dira eta besteentzat -batez besteko aritmetikoan oinarrituta. Milaka daude horrelako momentuak.
Fakturazio sistemaren bertsio bakarra zegoen arren, hornitzaile bakarra, ezarpenak hainbeste aldendu ziren, ezen denbora luzea behar izan baitzuen muntatzeko. Haien kopurua murrizten saiatu ginen, eta korporazio askorentzat ezaguna den bigarren arazo batekin egin genuen topo.
Eskalatze bertikala. Garai hartako hardware politenak ere ez zituen beharrak asetzen. Superdome Hi-End lineako Hewlett-Packard ekipoak erabili genituen, baina ez zituen bi adarren beharrak asetzen. Eskala horizontala nahi nuen operazio-kostu handirik eta kapital-inbertsiorik gabe.
Harpidedunen eta zerbitzuen kopuruaren hazkundearen itxaropena. Aholkulariek aspalditik ekarri dituzte IoT eta M2Mri buruzko istorioak telekomunikazioen mundura: iritsiko da telefono eta plantxa guztiek SIM txartel bat izango duten unea, eta bi hozkailuan. Gaur egun harpidedun kopuru bat dugu, baina etorkizun hurbilean askoz gehiago izango dira.
Erronka teknologikoak
Lau arrazoi hauek aldaketa larriak egitera bultzatu gintuzten. Aukera zegoen sistema berritzea eta hutsetik diseinatzearen artean. Denbora luzez pentsatu genuen, erabaki serioak hartu, lizitazioak jokatu. Ondorioz, hasiera-hasieratik diseinatzea erabaki genuen, eta erronka interesgarriak hartu genituen -erronka teknologikoak-.
Eskalagarritasuna
Lehen bazen, demagun, demagun 8 fakturazio 15 milioi harpidedunentzat, eta orain funtzionatu beharko luke 100 milioi harpidedun eta gehiago - karga magnitude ordena bat handiagoa da.
Mail.ru edo Netflix bezalako Interneteko jokalari handiekin konparagarriak bihurtu gara.
Baina karga eta harpidedun oinarria handitzeko mugimenduak erronka larriak ezarri dizkigu.
Gure herrialde zabalaren geografia
Kaliningrad eta Vladivostok artean 7500 km eta 10 ordu-eremu. Argiaren abiadura mugatua da eta distantzia horietan atzerapenak nabarmenak dira dagoeneko. 150 ms kanal optiko modernoenetan gehiegi dira denbora errealeko fakturaziorako, batez ere orain Errusiako telekomunikazioetan dagoenez. Horrez gain, lanegun batean eguneratu behar duzu, eta ordu-eremu ezberdinekin arazo bat da.
Ez ditugu zerbitzuak harpidetza kuota baten truke soilik eskaintzen, tarifa konplexuak, paketeak eta hainbat aldatzaile ditugu. Harpidedunari hitz egitea baimendu edo ukatu ez ezik, kuota jakin bat eman behar diogu: deiak eta ekintzak kalkulatu denbora errealean, ohartu ez dadin.
akatsen tolerantzia
Hau da zentralizazioaren beste aldea.
Harpidedun guztiak sistema batean biltzen baditugu, edozein larrialdi-gertaera eta hondamendia negargarria da negozioarentzat. Hori dela eta, sistema diseinatzen dugu istripuen eragina abonatuen oinarri osoan ezabatzeko moduan.
Berriro ere bertikalean eskalatzeari uko egitearen ondorioa da. Horizontalki eskalatu genuenean, zerbitzarien kopurua ehunka izatetik milaka izatera pasa genuen. Kudeatu eta trukagarriak izan behar dira, automatikoki babeskopiak egin behar dituzte IT azpiegituran eta banatutako sistema berreskuratu.
Hain erronka interesgarriak egin genituen aurre. Sistema diseinatu genuen, eta momentu horretan mundu mailako praktika onak bilatzen saiatu ginen, nola joera gauden, teknologia aurreratuak zenbateraino jarraitzen ditugun egiaztatzeko.
Munduko esperientzia
Harrigarria bada ere, ez dugu erreferentzia bakar bat aurkitu mundu mailako telekomunikazioetan.
Europa jaitsi egin da harpidedun kopuruari eta eskalari dagokionez, AEB - bere tarifen lautasunari dagokionez. Txinan batzuk begiratu, eta Indian aurkitu ditugu eta Vodafone Indiako espezialistak kontratatu ditugu.
Arkitektura aztertzeko, IBMk zuzendutako Dream Team bat muntatu dugu, arlo ezberdinetako arkitektoak. Pertsona hauek behar bezala ebaluatu ahal izan genuen zer egiten ari ginen eta zenbait ezagutza ekarri gure arkitekturara.
eskala
Zenbaki batzuk ilustraziorako.
Sistema horretarako diseinatzen dugu 80 milioi harpidedun mila milioiko erreserbarekin. Horrela kentzen ditugu etorkizuneko atalaseak. Hau ez da Txina hartuko dugulako, IoT eta M2Mren erasoagatik baizik.
300 milioi dokumentu prozesatu dira denbora errealean. 80 milioi harpidedun baditugu ere, bezero potentzialekin eta utzi gaituztenekin lan egiten dugu, kobratu behar baditugu. Hori dela eta, benetako bolumenak nabarmen handiagoak dira.
2 milioi transakzio Saldoa egunero aldatzen da: ordainketak, karguak, deiak eta bestelako gertaerak dira. 200 TB datu aktiboki aldatzen ari dira, aldatu pixka bat motelago 8 PB datu, eta hau ez da artxibo bat, fakturazio bakarreko zuzeneko datuak baizik. Eskalatu datu-zentroaren arabera - 5 mila zerbitzari 14 gunetan.
Teknologia pila
Arkitektura planifikatu eta sistema muntatzen hasi ginenean, teknologiarik interesgarrienak eta aurreratuenak inportatu genituen. Emaitza karga handiko sistemak egiten dituzten Interneteko erreproduzitzaile eta korporazio guztientzat ezaguna den teknologia pila bat da.
Pila beste jokalari garrantzitsuen pilen antzekoa da: Netflix, Twitter, Viber. 6 osagaiz osatuta dago, baina laburtu eta bateratu nahi dugu.
Malgutasuna ona da, baina korporazio handi batean ez dago biderik bateratzerik gabe.
Ez dugu Oracle bera Tarantool-era aldatuko. Enpresa handien errealitateetan, hau utopia bat da, edo 5-10 urteko gurutzada bat, emaitza argirik ez duena. Baina Cassandra eta Couchbase erraz ordezkatu daitezke Tarantool-ekin, eta horretan ari gara ahalegintzen.
Zergatik Tarantool?
Datu-base hau aukeratu dugun 4 irizpide sinple daude.
Abiadura. MegaFon industria-sistemetan karga-probak egin ditugu. Tarantool-ek irabazi zuen - errendimendu onena erakutsi zuen.
Horrek ez du esan nahi beste sistema batzuek MegaFon-en beharrak asetzen ez dituztenik. Gaur egungo memoria-soluzioak hain dira produktiboak, non konpainiaren erreserbak nahikoak dira. Baina lider batekin aritzea interesatzen zaigu, eta ez atzeratuta dagoen norbaitekin, karga proban barne.
Tarantool-ek konpainiaren beharrak estaltzen ditu epe luzera ere.
TCO kostua. Couchbase-ren laguntza MegaFon-en bolumenetan diru-kopuru astronomikoak kostatzen dira, baina Tarantool-ekin egoera askoz atseginagoa da eta funtzionalitatean antzekoak dira.
Gure aukeran zertxobait eragin duen beste ezaugarri polita Tarantool-ek memoriarekin hobeto funtzionatzen duela da beste datu-baseek baino. Erakusten du eraginkortasun handiena.
Fidagarritasuna. MegaFonek fidagarritasunean inbertitzen du, ziurrenik inork baino gehiago. Beraz, Tarantool-i begiratu genionean, gure eskakizunak bete behar genituela konturatu ginen.
Gure denbora eta finantzak inbertitu genituen, eta Mail.ru-rekin batera enpresa-bertsio bat sortu genuen, orain beste hainbat enpresatan erabiltzen dena.
Tarantool-enpresa guztiz ase gintuen segurtasunari, fidagarritasunari eta erregistroari dagokionez.
Lankidetza
Niretzat garrantzitsuena da garatzailearekin harreman zuzena. Horixe da, hain zuzen, Tarantool-eko mutilek soropekatu zutena.
Jokalari batengana etortzen bazara, batez ere aingura-bezero batekin lan egiten duen batengana, eta hau, hau eta hau egin ahal izateko datu-basea behar duzula esaten baduzu, berak erantzun ohi du:
- Ados, jarri eskakizunak pila horren azpian - noizbait, ziurrenik iritsiko gara.
Askok hurrengo 2-3 urteetarako bide orria dute, eta ia ezinezkoa da bertan integratzea, baina Tarantool-eko garatzaileek irekitasunarekin liluratzen dute, eta ez MegaFonetik bakarrik, eta bezeroari egokitzen diote sistema. Polita da eta asko gustatzen zaigu.
Tarantool non erabiltzen genuen
Tarantool hainbat elementutan erabiltzen dugu. Lehenengoa pilotuan dago, helbide-direktorio sisteman egin genuena. Garai batean Yandex.Maps eta Google Maps-en antzeko sistema bat izatea nahi nuen, baina apur bat desberdina izan zen.
Adibidez, salmenta-interfazeko helbide-katalogoa. Oracle-n, nahi duzun helbidea bilatzeko 12-13 segundo behar dira. - Zenbaki deserosoak. Tarantool-era aldatzen dugunean, Oracle kontsolan beste datu-base batekin ordezkatzen dugunean eta bilaketa bera egiten dugunean, 200 aldiz bizkortzea lortzen dugu! Hirugarren letraren ondoren hiria agertzen da. Orain interfazea egokitzen ari gara, hau lehenengoaren ondoren gertatu dadin. Hala ere, erantzun-abiadura guztiz ezberdina da - milisegundoak segundoren ordez.
Bigarren aplikazioa bi abiadurako IT izeneko gai modan dago. Hau da, bazter guztietako aholkulariek esaten baitute korporazioek bertara joan behar dutela.
Azpiegitura geruza bat dago, haren gainean domeinuak daude, adibidez, telekomunikazio bat bezalako fakturazio sistema bat, sistema korporatiboak, txosten korporatiboak. Hau da ukitu behar ez den muina. Hori da, noski, posible da, baina paranoikoki kalitatea bermatzea, korporazioari dirua ekartzen diolako.
Ondoren, mikrozerbitzuen geruza dator: operadorea edo beste jokalaria bereizten duena. Mikrozerbitzuak azkar sor daitezke zenbait cachetan oinarrituta, domeinu ezberdinetako datuak bertara eramanez. Hemen esperimentuak egiteko eremua — Zerbait ez bazen konpontzen, mikrozerbitzu bat itxi eta beste bat ireki nuen. Horrek merkaturatzeko denbora benetan handitzen du eta enpresaren fidagarritasuna eta abiadura areagotzen ditu.
Mikrozerbitzuak dira agian Tarantool-en eginkizun nagusia MegaFon-en.
Non Tarantool erabiltzeko asmoa dugu
Gure fakturazio proiektu arrakastatsua Deutsche Telekom, Svyazcom, Vodafone Indiako eraldaketa programekin alderatzen badugu, harrigarriro dinamikoa eta sormena da. Proiektu hau ezartzeko prozesuan, MegaFon eta bere egitura ez ezik, Tarantool-enpresa ere agertu zen Mail.ru-n, eta gure saltzailea Nexign (lehen Peter-Service) - BSS Box (kutxako fakturazio irtenbide bat).
Hau, nolabait, Errusiako merkaturako proiektu historikoa da. Frederick Brooksen "The Mythical Man-Month" liburuan deskribatzen denarekin alderatu daiteke. Gero, 60ko hamarkadan, IBMk 360 pertsona kontratatu zituen mainframeetarako OS/5 sistema eragile berria garatzeko. Gutxiago ditugu - 000, baina gureak txalekoak dira, eta kode irekiaren erabilera eta ikuspegi berriak kontuan hartuta, produktiboago lan egiten dugu.
Jarraian, fakturazio edo, modu zabalagoan, negozio sistemen domeinuak daude. Enpresako jendeak oso ondo ezagutzen du CRM. Guztiek dagoeneko beste sistema batzuk izan beharko lituzkete: Open API, API Gateway.
Ireki APIa
Ikus ditzagun berriro zenbakiak eta gaur egun Open APIak nola funtzionatzen duen. Bere karga da 10 transakzio segundoko. Mikrozerbitzuen geruza aktiboki garatzeko eta MegaFon API publikoa eraikitzeko asmoa dugunez, etorkizunean hazkunde handiagoa espero dugu zati honetan. Zalantzarik gabe, 100 transakzio izango dira.
Ez dakit Mail.ru-rekin alderatu dezakegun SSO-n - badirudi mutilek 1 transakzio dituztela segundoko. Haien irtenbidea oso interesgarria da guretzat eta haien esperientzia hartzeko asmoa dugu, adibidez, SSO funtzionalaren babeskopia bat egitea Tarantool erabiliz. Orain Mail.ru-ko garatzaileek hau egiten ari dira guretzat.
CRM
CRM mila milioira igo nahi dugun 80 milioi harpidedun bera da, dagoeneko hiru urteko historia biltzen duten 300 milioi dokumentu daudelako. Zerbitzu berrien zain gaude eta hemen hazkunde puntua konektatutako zerbitzuak dira. Hau hazi egingo den pilota bat da, gero eta zerbitzu gehiago egongo direlako. Horren arabera, istorio bat beharko dugu; ez dugu honekin estropezu egin nahi.
Fakturak igortzeari dagokionez berari fakturatzea, bezeroen kobratzeko kontuekin lan egitea domeinu bereizi batean eraldatu. Errendimendua hobetzeko, aplikatutako domeinu arkitektura eredu arkitektonikoa.
Sistema domeinuetan banatzen da, karga banatzen da eta akatsen tolerantzia bermatzen da. Gainera, arkitektura banatuarekin lan egin dugu.
Beste guztia enpresa mailako soluzioak dira. Deien biltegian - 2 milioi eguneko, 60 milioi hilero. Batzuetan hilabete batean zenbatu behar dituzu, eta hobe da azkar. Finantza-jarraipena - etengabe hazten eta hazten ari diren 300 milioi berdinak dira: harpidedunak sarritan ibiltzen dira operadoreen artean, zati hori handituz.
Komunikazio mugikorren telekomunikazio osagairik handiena da lineako fakturazioa. Hauek deitzeko edo ez deitzeko aukera ematen duten sistemak dira, erabakiak denbora errealean hartzeko. Hemen karga segundoko 30 transakzio da, baina datuen transferentziaren hazkundea kontuan hartuta, planifikatzen dugu 250 transakzio, eta horregatik Tarantool-en oso interesatzen zaigu.
Aurreko argazkia Tarantool erabiliko dugun domeinua da. CRM bera, noski, zabalagoa da eta muinean bertan erabiliko dugu.
Gure 100 milioi harpidedun TTX-ren kopuruak nahastu egiten nau arkitekto gisa - 101 milioi izango balira? Dena berriro egin behar al duzu? Hori gerta ez dadin, cacheak erabiltzen ditugu, aldi berean, irisgarritasuna areagotuz.
Oro har, bi ikuspegi daude Tarantool erabiltzeko. Lehenengoa - eraiki cache guztiak mikrozerbitzu mailan. Nik ulertzen dudanez, VimpelCom bide hau jarraitzen ari da, bezeroen cache bat sortuz.
Saltzaileen menpe gutxiago gaude, BSS nukleoa aldatzen ari gara, beraz, bezero fitxategi bakarra dugu kutxatik kanpo. Baina zabaldu nahi dugu. Hori dela eta, ikuspegi apur bat ezberdina hartzen dugu - cacheak egin sistemen barruan.
Horrela sinkronizazio gutxiago dago - sistema bat da cachearen eta iturri nagusi nagusiaren arduraduna.
Metodoa ondo egokitzen da Tarantool-en ikuspegiarekin transakzio-eskeletoarekin, eguneratzeekin erlazionatutako zatiak soilik eguneratzen direnean, hau da, datu-aldaketak. Beste guztia beste nonbait gorde daiteke. Ez dago datu-laku handirik, kudeatu gabeko cache globalik. Cacheak sistemarako, edo produktuetarako, edo bezeroentzako diseinatuta daude, edo mantentze-lanak bizitza errazteko. Harpidedun batek deitzen duenean eta zure zerbitzuaren kalitatearekin atsekabetuta dagoenean, kalitatezko zerbitzua eman nahi duzu.
RTO eta RPO
Informatikan bi termino daude: OTR и RPO.
Berreskuratzeko denboraren helburua hutsegite baten ondoren zerbitzua berrezartzeko behar den denbora da. RTO = 0 esan nahi du zerbaitek huts egiten badu ere, zerbitzuak lanean jarraitzen duela.
Berreskuratze puntuaren helburua - Hau da datuak berreskuratzeko denbora, zenbat datu gal ditzakegun denbora-tarte jakin batean. RPO = 0 esan nahi du ez dugula datuak galtzen ari.
Tarantool zeregina
Saia gaitezen Tarantool-en arazo bat konpontzen.
Emana: denek ulertzen duten aplikazioen saskia, adibidez, Amazonen edo beste nonbait. beharrezkoa beraz, erosketa-gurdiak asteko 24 egunetan 7 orduz funtzionatzen du, edo denboraren %99,99an. Etortzen zaizkigun aginduek ordenatuta egon behar dute, ezin dugulako ausaz harpidedunaren konexioa piztu edo itzali; dena koherentea izan behar da. Aurreko harpidetzak hurrengoari eragiten dio, beraz, datuak garrantzitsuak dira - ez da ezer galdu behar.
Erabaki. Saia zaitezke buru-belarri konpontzen eta datu-baseen garatzaileei galdetu, baina arazoa ezin da matematikoki konpondu. Teoremak, kontserbazio-legeak, fisika kuantikoa gogora ditzakezu, baina zergatik - ezin da DB mailan konpondu.
Ikuspegi arkitektoniko zaharrak hemen funtzionatzen du: gaia ondo ezagutu eta puzzle hau konpontzeko erabili behar duzu.
Gure irtenbidea: Tarantool-en aplikazioen erregistro banatu bat sortzea - geo-banatutako kluster bat. Diagraman, datuak prozesatzeko hiru zentro ezberdin dira: bi Uralen aurretik, bat Uralen haratago, eta eskaera guztiak zentro horien artean banatzen ditugu.
Netflixek, gaur egun informatikako liderretakotzat hartzen dena, datu-zentro bakarra zuen 2012ra arte. Eguberri katolikoen bezperan, abenduaren 24an, datu-zentro honek behera egin zuen. Kanadako eta AEBko erabiltzaileak gogoko filmik gabe geratu ziren, oso haserretu ziren eta horri buruz idatzi zuten sare sozialetan. Netflix-ek hiru datu-zentro ditu orain mendebalde-ekialdeko kostaldean eta bat Europa mendebaldean.
Hasieran geo-banatutako irtenbide bat eraikitzen ari gara - akatsen tolerantzia garrantzitsua da guretzat.
Beraz, kluster bat dugu, baina zer gertatzen da RPO = 0 eta RTO = 0? Irtenbidea erraza da, gaiaren arabera.
Zer da garrantzitsua aplikazioetan? Bi zati: Saski jaurtiketa gisA erosteko erabakia hartzea, eta ONDOREN. Telekomunikazioetako DO zatiari deitzen zaio normalean ordena harrapatzea edo aginduen negoziazioa. Telekomunikazioetan, hau online denda batean baino askoz zailagoa izan daiteke, bertan bezeroari zerbitzatu behar zaiolako, 5 aukera eskaini behar zaizkiolako, eta hori guztia denbora batez gertatzen da, baina saskia beteta dago. Momentu honetan, hutsegite bat posible da, baina ez da beldurgarria, interaktiboki gertatzen baita gizakiaren zaintzapean.
Moskuko datu-zentroak bat-batean huts egiten badu, beste datu-zentro batera automatikoki aldatuz, lanean jarraituko dugu. Teorian, baliteke produktu bat saskian galtzea, baina ikusten duzu, gehitu berriro saskira eta jarraitu lanean. Kasu honetan RTO = 0.
Momentu berean, bigarren aukera dago: “Enviar” sakatzen dugunean, datuak ez galtzea nahi dugu. Une honetatik aurrera, automatizazioa funtzionatzen hasten da - hau da RPO = 0. Bi eredu desberdin hauek erabiliz, kasu batean, maisu aldagarri batekin geo-banatutako kluster bat izan liteke, beste kasu batean quorum-erregistroren bat. Ereduak alda daitezke, baina arazoa konpontzen dugu.
Gainera, aplikazioen erregistro banatua edukita, dena eskalatu dezakegu: erregistro honetara sartzen diren bidaltzaile eta exekutatzaile asko ditugu.
Cassandra eta Tarantool elkarrekin
Bada beste kasu bat - "saldoen erakusleihoa". Hona hemen Cassandra eta Tarantool elkarrekin erabiltzeko kasu interesgarri bat.
Cassandra erabiltzen dugu eguneko 2 milioi dei ez delako muga, eta gehiago izango dira. Merkataritzari trafikoa iturriaren arabera koloreztatzea gustatzen zaio; gero eta xehetasun gehiago agertzen dira sare sozialetan, adibidez. Horrek guztiak istorioari gehitzen dio.
Cassandra-k horizontalki edozein tamainatara eskalatzeko aukera ematen du.
Cassandrarekin gustura sentitzen gara, baina arazo bat du: ez da ona irakurtzeko. Grabazioan dena ondo dago, segundoko 30 ez da arazoa - irakurketa arazoa.
Hori dela eta, cachea duen gai bat agertu da, eta aldi berean arazo hau konpondu dugu: kasu tradizional zahar bat dago lineako fakturaziotik aldatzeko ekipoak Cassandran kargatzen ditugun fitxategietan sartzen direnean. Fitxategi hauen deskarga fidagarriaren arazoarekin borrokatu genuen, IBM kudeatzailearen fitxategien transferentziaren aholkua erabilita ere - fitxategien transferentzia modu eraginkorrean kudeatzen duten irtenbideak daude, UDP protokoloa erabiliz, adibidez, TCP baino. Hau ona da, baina minutuak dira oraindik, eta oraindik ez dugu dena kargatu, dei-zentroko operadoreak ezin dio bezeroari erantzun saldoari gertatutakoa - itxaron behar dugu.
Hori gerta ez dadin, guk erreserba funtzional paraleloa erabiltzen dugu. Kafkaren bidez Tarantoolera gertaera bat bidaltzen dugunean, agregatuak denbora errealean berriro kalkulatuz, adibidez, gaur egun, lortuko dugu eskudiru-gerakinak, edozein abiaduratan saldoak transferi ditzakeena, adibidez, 100 mila transakzio segundoko eta 2 segundo horiek berdinak.
Helburua da dei bat egin ondoren, zure kontu pertsonalean 2 segundoren buruan aldatutako saldoa ez ezik, zergatik aldatu den buruzko informazioa ere egotea.
Ondorioa
Tarantool erabiltzearen adibideak izan ziren. Asko gustatu zitzaigun Mail.ru-ren irekitasuna eta kasu desberdinak aztertzeko duten borondatea.
Dagoeneko zaila da BCG edo McKinsey, Accenture edo IBMko aholkularientzat zerbait berri batekin harritzea; eskaintzen dutenaren zati handi bat, dagoeneko egiten dugu, egin dugu edo egiteko asmoa dugu. Tarantool-ek gure teknologia pilan dagokion lekua hartuko duela eta lehendik dauden teknologia asko ordezkatuko dituela uste dut. Proiektu honen garapen fase aktiboan gaude.
Oleg eta Andreyren txostena iazko Tarantool Konferentziako onenetako bat da, eta ekainaren 17an Oleg Ivlev-ek hitz egingo du. txosten batekin . MegaFon-en aurkezpena ere egingo du Alexander Deulinek . Jakin dezagun zer aldatu den, zein plan ezarri diren. Sartu - hitzaldia doakoa da, egin behar duzun guztia da ... guztiak eta jardunaldien programa osatu da: kasu berriak, Tarantool erabiltzeko esperientzia berria, arkitektura, enpresa, tutorialak eta mikrozerbitzuak.
Iturria: www.habr.com