Kial korporacio kiel MegaFon bezonas Tarantool en fakturado? De ekstere ŝajnas, ke la vendisto kutime venas, alportas ian grandan skatolon, ŝtopas la ŝtopilon en la inkon - kaj tio estas fakturado! Tiel estis iam, sed nun ĝi estas arkaika, kaj tiaj dinosaŭroj jam formortis aŭ formortas. Komence, fakturado estas sistemo por eldonado de fakturoj - kalkulmaŝino aŭ kalkulilo. En modernaj telekomunikadoj tio estas aŭtomatiga sistemo por la tuta vivociklo de interago kun abonanto de konkludo de kontrakto ĝis fino, inkluzive de realtempa fakturado, akcepto de pago kaj multe pli. Fakturado en telekomunikaj kompanioj estas kiel batalroboto - granda, potenca kaj ŝarĝita per armiloj.
Kion rilatas Tarantool al ĝi? Ili parolos pri tio Oleg Ivlev и Andrej Knyazev. Oleg estas la ĉefa arkitekto de la kompanio kun vasta sperto laboranta en eksterlandaj kompanioj, Andrey estas direktoro de komercaj sistemoj. El la transskribo de ilia raporto sur vi lernos kial R&D estas bezonata en korporacioj, kio estas Tarantool, kiel la blokiĝo de vertikala skalado kaj tutmondiĝo fariĝis la antaŭkondiĉoj por la apero de ĉi tiu datumbazo en la kompanio, pri teknologiaj defioj, arkitektura transformo, kaj kiel la teknostako de MegaFon similas al Netflix. , Guglo kaj Amazono.
Projekto "Unuigita Fakturado"
La koncerna projekto nomiĝas "Unuigita Fakturado". Estis ĉi tie ke Tarantool montris siajn plej bonajn kvalitojn.
La kresko de produktiveco de Hi-End-ekipaĵo ne samrapidis kun la kresko de la abonanto kaj la kresko de la nombro da servoj; plia kresko de la nombro da abonantoj kaj servoj estis atendita pro M2M, IoT kaj branĉoj gvidis. al plimalboniĝo de tempo-al-merkato. La firmao decidis krei unuigitan komercan sistemon kun unika mondklasa modula arkitekturo, anstataŭe de 8 nunaj malsamaj fakturaj sistemoj.
MegaFon estas ok kompanioj en unu. En 2009, la reorganizado estis kompletigita: branĉoj ĉie en Rusio kunfalis en ununuran firmaon, MegaFon OJSC (nun PJSC). Tiel, la kompanio havas 8 fakturajn sistemojn kun siaj propraj "kutimigitaj" solvoj, branĉoj kaj malsamaj organizaj strukturoj, IT kaj merkatado.
Ĉio estis bona ĝis ni devis lanĉi unu komunan federacian produkton. Ĉi tie aperis multaj malfacilaĵoj: por iuj tarifoj estas rondigitaj supren, por aliaj malsupre, kaj por aliaj - surbaze de la aritmetika meznombro. Estas miloj da tiaj momentoj.
Malgraŭ tio, ke ekzistis nur unu versio de la faktura sistemo, unu provizanto, la agordoj tiom diverĝis, ke necesis longa tempo por kunmeti. Ni provis redukti ilian nombron, kaj renkontis duan problemon, kiu estas konata al multaj korporacioj.
Vertikala skalo. Eĉ la plej bonega aparataro en tiu tempo ne renkontis la bezonojn. Ni uzis ekipaĵon Hewlett-Packard de la linio Superdome Hi-End, sed ĝi ne renkontis la bezonojn de eĉ du branĉoj. Mi volis horizontalan skalon sen grandaj operaciaj kostoj kaj kapitalinvestoj.
Atendado de kresko en la nombro da abonantoj kaj servoj. Konsultistoj longe alportis rakontojn pri IoT kaj M2M al la telekomunika mondo: venos la tempo, kiam ĉiu telefono kaj gladilo havos SIM-karton, kaj du en la fridujo. Hodiaŭ ni havas unu nombron da abonantoj, sed baldaŭ estos multaj pliaj.
Teknologiaj defioj
Ĉi tiuj kvar kialoj instigis nin fari seriozajn ŝanĝojn. Ekzistis elekto inter ĝisdatigi la sistemon kaj projekti de nulo. Ni longe pensis, faris seriozajn decidojn, ludis ofertojn. Kiel rezulto, ni decidis desegni de la komenco, kaj akceptis interesajn defiojn - teknologiajn defiojn.
Skalebleco
Se ĝi estis antaŭe, ni diru, ni diru 8 fakturadoj por 15 milionoj da abonantoj, kaj nun ĝi devus esti funkciinta 100 milionoj da abonantoj kaj pli - la ŝarĝo estas grandordo pli alta.
Ni fariĝis kompareblaj en skalo al grandaj interretaj ludantoj kiel Mail.ru aŭ Netflix.
Sed la plua movado por pliigi la ŝarĝon kaj abonantaron starigis gravajn defiojn por ni.
Geografio de nia vasta lando
Inter Kaliningrado kaj Vladivostok 7500 km kaj 10 horzonoj. La lumrapideco estas finia kaj ĉe tiaj distancoj la prokrastoj jam estas gravaj. 150 ms sur la plej bonegaj modernaj optikaj kanaloj estas tro multe por realtempa fakturado, precipe ĉar ĝi nun estas en telekomunikado en Rusio. Krome, vi devas ĝisdatigi en unu labortago, kaj kun malsamaj horzonoj ĉi tio estas problemo.
Ni ne nur provizas servojn por abonkotizo, ni havas kompleksajn tarifojn, pakaĵojn kaj diversajn modifilojn. Ni devas ne nur permesi aŭ nei al la abonanto paroli, sed doni al li certan kvoton - kalkuli vokojn kaj agojn en reala tempo, por ke li ne rimarku.
kulpo toleremo
Ĉi tio estas la alia flanko de centralizo.
Se ni kolektas ĉiujn abonantojn en unu sistemo, tiam iuj krizaj eventoj kaj katastrofoj estas katastrofaj por komerco. Tial ni dizajnas la sistemon tiel, ke ni eliminu la efikon de akcidentoj sur la tuta bazo de abonantoj.
Ĉi tio denove estas sekvo de la rifuzo grimpi vertikale. Kiam ni grimpis horizontale, ni pliigis la nombron da serviloj de centoj al miloj. Ili devas esti administritaj kaj interŝanĝeblaj, aŭtomate subtenitaj de la IT-infrastrukturo kaj restarigi la distribuitan sistemon.
Ni alfrontis tiajn interesajn defiojn. Ni desegnis la sistemon, kaj en tiu momento ni provis trovi tutmondajn plej bonajn praktikojn por kontroli kiom en tendenco ni estas, kiom ni sekvas altnivelajn teknologiojn.
Monda sperto
Surprize, ni ne trovis ununuran referencon en tutmonda telekomunikado.
Eŭropo falis laŭ la nombro de abonantoj kaj skalo, Usono - laŭ la plateco de siaj tarifoj. Ni rigardis kelkajn en Ĉinio, kaj trovis kelkajn en Hindio kaj dungis specialistojn de Vodafone Hindio.
Por analizi la arkitekturon, ni kunvenis Dream Team gviditan de IBM - arkitektoj de diversaj kampoj. Ĉi tiuj homoj povis adekvate taksi kion ni faris kaj alporti certan scion al nia arkitekturo.
Zoom
Kelkaj nombroj por ilustraĵo.
Ni desegnas la sistemon por 80 milionoj da abonantoj kun rezervo de unu miliardo. Jen kiel ni forigas estontajn sojlojn. Ĉi tio ne estas ĉar ni transprenos Ĉinion, sed pro la alsturmo de IoT kaj M2M.
300 milionoj da dokumentoj prilaboritaj en reala tempo. Kvankam ni havas 80 milionojn da abonantoj, ni laboras kaj kun eblaj klientoj kaj kun tiuj, kiuj forlasis nin, se ni bezonas kolekti ricevaĵojn. Tial, la realaj volumoj estas rimarkeble pli grandaj.
2 miliardoj da transakcioj La bilanco ŝanĝiĝas ĉiutage - ĉi tiuj estas pagoj, kotizoj, vokoj kaj aliaj eventoj. 200 TB da datumoj aktive ŝanĝiĝas, ŝanĝi iom pli malrapide 8 PB da datumoj, kaj ĉi tio ne estas arkivo, sed vivaj datumoj en ununura fakturado. Skalu laŭ datumcentro - 5 mil serviloj sur 14 retejoj.
Teknologia stako
Kiam ni planis la arkitekturon kaj komencis kunmeti la sistemon, ni importis la plej interesajn kaj altnivelajn teknologiojn. La rezulto estas teknologia stako konata al iu ajn Interreta ludanto kaj korporacioj kiuj faras altŝarĝajn sistemojn.
La stako similas al la stakoj de aliaj ĉefaj ludantoj: Netflix, Twitter, Viber. Ĝi konsistas el 6 komponantoj, sed ni volas mallongigi kaj unuigi ĝin.
Fleksebleco estas bona, sed en granda korporacio ne ekzistas maniero sen unuiĝo.
Ni ne ŝanĝos la saman orakolon al Tarantool. En la realaĵoj de grandaj kompanioj, ĉi tio estas utopio, aŭ krucmilito dum 5-10 jaroj kun neklara rezulto. Sed Cassandra kaj Couchbase povas facile esti anstataŭigitaj per Tarantool, kaj tion ni strebas.
Kial Tarantool?
Estas 4 simplaj kriterioj, kial ni elektis ĉi tiun datumbazon.
Rapido. Ni faris ŝarĝtestojn sur MegaFon industriaj sistemoj. Tarantool venkis - ĝi montris la plej bonan agadon.
Ĉi tio ne signifas, ke aliaj sistemoj ne plenumas la bezonojn de MegaFon. Nunaj memorsolvoj estas tiel produktivaj, ke la rezervoj de la firmao estas pli ol sufiĉaj. Sed ni interesiĝas pri trakti gvidanton, kaj ne kun iu, kiu postrestis, inkluzive en la ŝarĝtesto.
Tarantool kovras la bezonojn de la kompanio eĉ longtempe.
TCO-kosto. Subteno por Couchbase sur MegaFon-volumoj kostas astronomiajn monsumojn, sed kun Tarantool la situacio estas multe pli agrabla, kaj ili estas similaj laŭ funkcieco.
Alia bela trajto, kiu iomete influis nian elekton, estas ke Tarantool funkcias pli bone kun memoro ol aliaj datumbazoj. Li montras maksimuma efikeco.
Fidindeco. MegaFon investas en fidindeco, verŝajne pli ol iu ajn alia. Do kiam ni rigardis Tarantool, ni rimarkis, ke ni devas fari ĝin plenumi niajn postulojn.
Ni investis nian tempon kaj financon, kaj kune kun Mail.ru ni kreis entreprenan version, kiu nun estas uzata en pluraj aliaj kompanioj.
Tarantool-entrepreno tute kontentigis nin rilate al sekureco, fidindeco kaj arbohakado.
Partnereco
La plej grava afero por mi estas rekta kontakto kun la programisto. Ĝuste ĉi tio subaĉetis la uloj de Tarantool.
Se vi venas al ludanto, precipe tiu, kiu laboras kun ankrokliento, kaj diras, ke vi bezonas la datumbazon por povi fari ĉi tion, ĉi tion kaj ĉi tion, li kutime respondas:
- Bone, metu la postulojn ĉe la fundo de tiu amaso - iam, ni verŝajne atingos ilin.
Multaj havas vojmapon por la venontaj 2-3 jaroj, kaj estas preskaŭ neeble integri tie, sed Tarantool-programistoj allogas per sia malfermiteco, kaj ne nur de MegaFon, kaj adaptas sian sistemon al la kliento. Ĝi estas bonega kaj ni tre ŝatas ĝin.
Kie ni uzis Tarantool
Ni uzas Tarantool en pluraj elementoj. La unua estas en la piloto, kiun ni faris sur la adresa dosierujo-sistemo. Iam mi volis, ke ĝi estu sistemo simila al Yandex.Maps kaj Google Maps, sed ĝi rezultis iom alie.
Ekzemple, la adreskatalogo en la venda interfaco. En Oracle, serĉi la deziratan adreson daŭras 12-13 sekundojn. - malkomfortaj nombroj. Kiam ni ŝanĝas al Tarantool, anstataŭigas Oracle per alia datumbazo en la konzolo, kaj faras la saman serĉon, ni ricevas 200x-rapidigon! La urbo aperas post la tria letero. Nun ni adaptas la interfacon por ke tio okazas post la unua. Tamen, la respondrapideco estas tute malsama - milisekundoj anstataŭ sekundoj.
La dua aplikaĵo estas laŭmoda temo nomata du-rapida IT. Ĉi tio estas ĉar konsultistoj de ĉiu angulo diras, ke korporacioj devus iri tien.
Estas infrastruktura tavolo, super ĝi estas domajnoj, ekzemple, faktura sistemo kiel telekomunikado, kompaniaj sistemoj, kompania raportado. Ĉi tiu estas la kerno, kiu ne bezonas esti tuŝita. Tio estas, kompreneble, ĝi eblas, sed paranoje certigante kvaliton, ĉar ĝi alportas monon al la korporacio.
Poste venas la tavolo de mikroservoj - kio diferencigas la funkciigiston aŭ alian ludanton. Mikroservoj povas esti rapide kreitaj surbaze de certaj kaŝmemoroj, alportante datumojn de malsamaj domajnoj tien. Jen kampo por eksperimentoj — se io ne funkciis, mi fermis unu mikroservon kaj malfermis alian. Ĉi tio provizas vere pliigitan tempon al merkatado kaj pliigas la fidindecon kaj rapidecon de la kompanio.
Mikroservoj eble estas la ĉefa rolo de Tarantool ĉe MegaFon.
Kie ni planas uzi Tarantool
Se ni komparas nian sukcesan fakturan projekton kun la transformprogramoj ĉe Deutsche Telekom, Svyazcom, Vodafone India, ĝi estas surprize dinamika kaj krea. En la procezo de efektivigo de ĉi tiu projekto, ne nur MegaFon kaj ĝia strukturo estis transformitaj, sed ankaŭ Tarantool-entrepreno aperis ĉe Mail.ru, kaj nia vendisto Nexign (antaŭe Peter-Service) - BSS Box (skatolita faktura solvo).
Ĉi tio estas, iusence, historia projekto por la rusa merkato. Ĝi povas esti komparita kun tio, kio estas priskribita en la libro "La Mitika Homo-Monato" de Frederick Brooks. Tiam, en la 60-aj jaroj, IBM dungis 360 homojn por evoluigi la novan OS/5 operaciumon por komputilegoj. Ni havas malpli - 000, sed la niaj estas en veŝtoj, kaj konsiderante la uzon de malferma fonto kaj novaj aliroj, ni laboras pli produktive.
Malsupre estas la domajnoj de fakturado aŭ, pli larĝe parolante, komercaj sistemoj. Homoj de entrepreno tre bone konas CRM. Ĉiuj jam havu aliajn sistemojn: Open API, API Gateway.
Malferma API
Ni rigardu la nombrojn denove kaj kiel la Open API nuntempe funkcias. Ĝia ŝarĝo estas 10 transakcioj por sekundo. Ĉar ni planas aktive evoluigi la mikroservan tavolon kaj konstrui la publikan API de MegaFon, ni atendas pli grandan kreskon estontece en ĉi tiu parto. Nepre estos 100 transakcioj.
Mi ne scias ĉu ni povas kompari kun Mail.ru en SSO - la uloj ŝajnas havi 1 transakciojn sekundo. Ilia solvo estas ege interesa por ni kaj ni planas adopti ilian sperton - ekzemple, farante funkcian SSO-rezervon per Tarantool. Nun la programistoj de Mail.ru faras tion por ni.
CRM
CRM estas la samaj 80 milionoj da abonantoj, kiujn ni volas pliigi al miliardo, ĉar jam ekzistas 300 milionoj da dokumentoj, kiuj inkluzivas trijaran historion. Ni vere antaŭĝojas pri novaj servoj kaj ĉi tie kreskopunkto estas konektitaj servoj. Ĉi tio estas pilko, kiu kreskos, ĉar estos pli kaj pli da servoj. Sekve, ni bezonos rakonton; ni ne volas fali pri tio.
Fakturado mem laŭ emisiado de fakturoj, laborante kun klientaj kontoj riceveblaj transformita en apartan domajnon. Por plibonigi rendimenton, aplikata domajna arkitekturo arkitektura ŝablono.
La sistemo estas dividita en domajnojn, la ŝarĝo estas distribuita kaj faŭltoleremo estas certigita. Aldone, ni laboris kun distribuita arkitekturo.
Ĉio alia estas entrepren-nivelaj solvoj. En la vokostokado - 2 miliardoj tage, 60 miliardoj monate. Kelkfoje vi devas kalkuli ilin en monato, kaj estas pli bone rapide. Financa monitorado - tio estas ĝuste la samaj 300 milionoj, kiuj konstante kreskas kaj kreskas: abonantoj ofte kuras inter operatoroj, pliigante ĉi tiun parton.
La plej telekomunika komponanto de moveblaj komunikadoj estas interreta fakturado. Ĉi tiuj estas la sistemoj kiuj permesas al vi voki aŭ ne voki, fari decidojn en reala tempo. Ĉi tie la ŝarĝo estas 30 000 transakcioj por sekundo, sed konsiderante la kreskon de transdono de datumoj, ni planas 250 transakcioj, kaj tial ni tre interesiĝas pri Tarantool.
La antaŭa bildo estas la domajnoj, kie ni uzos Tarantool. CRM mem, kompreneble, estas pli larĝa kaj ni uzos ĝin en la kerno mem.
Nia taksita TTX-cifero de 100 milionoj da abonantoj konfuzas min kiel arkitekton - kaj se 101 milionoj? Ĉu vi devas denove ĉion refari? Por eviti ke tio okazu, ni uzas kaŝmemorojn, samtempe pliigante alireblecon.
Ĝenerale, ekzistas du aliroj por uzi Tarantool. Unue - konstrui ĉiujn kaŝmemorojn ĉe la mikroservo-nivelo. Laŭ mia kompreno, VimpelCom sekvas ĉi tiun vojon, kreante kaŝmemoron de klientoj.
Ni estas malpli dependaj de vendistoj, ni ŝanĝas la BSS-kernon, do ni havas ununuran klientdosieron el la skatolo. Sed ni volas vastigi ĝin. Tial ni prenas iomete malsaman aliron - fari kaŝmemorojn ene de sistemoj.
Tiel estas malpli da sinkronigado - unu sistemo respondecas pri kaj la kaŝmemoro kaj la ĉefa ĉeffonto.
La metodo kongruas bone kun la aliro de Tarantool kun transakcia skeleto, kiam nur partoj kiuj rilatas al ĝisdatigoj, tio estas, datumŝanĝoj, estas ĝisdatigitaj. Ĉio alia povas esti konservita aliloke. Ne ekzistas grandega datuma lago, neadministrata tutmonda kaŝmemoro. Kaŝmemoroj estas dizajnitaj por la sistemo, aŭ por produktoj, aŭ por klientoj, aŭ por faciligi la vivon por prizorgado. Kiam abonanto vokas kaj estas ĉagrenita pri la kvalito de via servo, vi volas provizi kvalitan servon.
RTO kaj RPO
Estas du terminoj en IT - OTR и RPO.
Reakira tempo objektivo estas la tempo necesa por restarigi la servon post malsukceso. RTO = 0 signifas, ke eĉ se io malsukcesas, la servo daŭre funkcias.
Reakira punkto objektivo - ĉi tio estas la tempo de reakiro de datumoj, kiom da datumoj ni povas perdi dum certa tempodaŭro. RPO = 0 signifas, ke ni ne perdas datumojn.
Tarantool-tasko
Ni provu solvi problemon por Tarantool.
Donita: korbo da aplikoj, kiujn ĉiuj komprenas, ekzemple, en Amazon aŭ ie aliloke. Postulita tiel ke la aĉetĉaro funkcias 24 horojn 7 tagojn semajne, aŭ 99,99% de la tempo. La mendoj, kiuj venas al ni, devas resti en ordo, ĉar ni ne povas hazarde ŝalti aŭ malŝalti la konekton de la abonanto - ĉio devas esti strikte konsekvenca. La antaŭa abono influas la sekvan, do la datumoj estas gravaj - nenio devus manki.
decido. Vi povas provi solvi ĝin rekte kaj demandi la datumbazajn programistojn, sed la problemo ne povas esti solvita matematike. Vi povas memori teoremojn, konservajn leĝojn, kvantuman fizikon, sed kial - ĝi ne povas esti solvita je la DB-nivelo.
La bona malnova arkitektura aliro funkcias ĉi tie - vi devas bone koni la temon kaj uzi ĝin por solvi ĉi tiun enigmon.
Nia solvo: krei distribuitan registron de aplikoj sur Tarantool - geo-distribuita areto. En la diagramo, ĉi tiuj estas tri malsamaj datumtraktadcentroj - du antaŭ la Uraloj, unu preter la Uraloj, kaj ni distribuas ĉiujn petojn inter ĉi tiuj centroj.
Netflix, kiu nun estas konsiderita unu el la gvidantoj en IT, havis nur unu datumcentron ĝis 2012. Antaŭtagmeze de katolika Kristnasko, la 24-an de decembro, ĉi tiu datumcentro malfunkciis. Uzantoj en Kanado kaj Usono restis sen siaj plej ŝatataj filmoj, tre ĉagreniĝis kaj skribis pri tio en sociaj retoj. Netflix nun havas tri datumcentrojn sur la okcidenta-orienta marbordo kaj unu en okcidenta Eŭropo.
Ni komence konstruas geo-distribuitan solvon - toleremo al misfunkciadoj estas grava por ni.
Do ni havas areton, sed kio pri RPO = 0 kaj RTO = 0? La solvo estas simpla, depende de la temo.
Kio estas grava en aplikoj? Du Partoj: Korboĵetado TO farante aĉetan decidon, kaj AFERO. La DO-parto en telekomunikado estas kutime nomita ordo kaptado aŭ ordo intertraktado. En telekomunikado, ĉi tio povas esti multe pli malfacila ol en reta vendejo, ĉar tie oni devas servi al la kliento, proponi 5-opciojn, kaj ĉi tio ĉio okazas dum kelka tempo, sed la korbo estas plenigita. En ĉi tiu momento, fiasko eblas, sed ĝi ne estas timiga, ĉar ĝi okazas interage sub homa superrigardo.
Se la Moskva datumcentro subite malsukcesas, tiam aŭtomate ŝanĝante al alia datumcentro, ni daŭre laboros. Teorie, unu produkto povas esti perdita en la ĉaro, sed vi vidas ĝin, aldonu al la ĉaro denove kaj daŭrigu labori. En ĉi tiu kazo RTO = 0.
En la sama momento, ekzistas dua opcio: kiam ni klakis "submeti", ni volas, ke la datumoj ne perdiĝu. Ekde ĉi tiu momento, aŭtomatigo komencas funkcii - ĉi tio estas RPO = 0. Uzante ĉi tiujn du malsamajn ŝablonojn, en unu kazo ĝi povus simple esti geo-distribuita areto kun unu ŝanĝebla majstro, en alia kazo ia kvoruma rekordo. Ŝablonoj povas varii, sed ni solvas la problemon.
Plue, havante distribuitan registron de aplikaĵoj, ni ankaŭ povas skali ĉion - havas multajn sendantojn kaj ekzekutistojn, kiuj aliras ĉi tiun registron.
Kasandra kaj Tarantool kune
Estas alia kazo - "montrilo de ekvilibroj". Jen interesa kazo de la komuna uzo de Kasandra kaj Tarantool.
Ni uzas Cassandra ĉar 2 miliardoj da vokoj tage ne estas la limo, kaj estos pli. Komercistoj amas kolorigi trafikon laŭ fonto; pli kaj pli da detaloj aperas en sociaj retoj, ekzemple. Ĉio aldonas al la rakonto.
Cassandra permesas vin grimpi horizontale al ajna grandeco.
Ni sentas nin komfortaj kun Kasandra, sed ĝi havas unu problemon - ĝi ne kapablas legi. Ĉio estas en ordo en la registrado, 30 sekundo ne estas problemo - problemo de legado.
Tial aperis temo kun kaŝmemoro, kaj samtempe ni solvis la jenan problemon: ekzistas malnova tradicia kazo, kiam ekipaĵo de ŝaltilo de interreta fakturado venas en la dosierojn, kiujn ni ŝarĝas en Cassandra. Ni luktis kun la problemo de fidinda elŝuto de ĉi tiuj dosieroj, eĉ uzante la konsilon de IBM-administranto-translokigo de dosieroj - ekzistas solvoj, kiuj administras dosiertranslokigon efike, uzante la protokolon UDP, ekzemple, anstataŭ TCP. Ĉi tio estas bona, sed ankoraŭ estas minutoj, kaj ni ankoraŭ ne ŝarĝis ĉion, la telefonisto en la telefoncentro ne povas respondi al la kliento, kio okazis al lia bilanco - ni devas atendi.
Por eviti ke tio okazu, ni ni uzas paralelan funkcian rezervon. Kiam ni sendas eventon per Kafka al Tarantool, rekalkulante agregaĵojn en reala tempo, ekzemple, por hodiaŭ, ni ricevas monsaloj, kiu povas transdoni saldojn je ajna rapido, ekzemple, 100 mil transakcioj por sekundo kaj tiuj samaj 2 sekundoj.
La celo estas, ke post voko, ene de 2 sekundoj en via persona konto estos ne nur la ŝanĝita saldo, sed informoj pri kial ĝi ŝanĝiĝis.
konkludo
Ĉi tiuj estis ekzemploj de uzado de Tarantool. Ni tre ŝatis la malfermitecon de Mail.ru kaj ilia volemo konsideri malsamajn kazojn.
Jam malfacilas por konsultistoj de BCG aŭ McKinsey, Accenture aŭ IBM surprizi nin per io nova - multe de tio, kion ili proponas, ni aŭ jam faras, faris aŭ planas fari. Mi pensas, ke Tarantool prenos sian ĝustan lokon en nia teknologia stako kaj anstataŭigos multajn ekzistantajn teknologiojn. Ni estas en la aktiva fazo de evoluo de ĉi tiu projekto.
La raporto de Oleg kaj Andrey estas unu el la plej bonaj ĉe la Tarantool-Konferenco pasintjare, kaj la 17-an de junio Oleg Ivlev prelegos ĉe kun raporto . Alexander Deulin ankaŭ faros prezenton de MegaFon . Ni eksciu, kio ŝanĝiĝis, kiaj planoj estis efektivigitaj. Aliĝu - la konferenco estas senpaga, vi nur devas fari ... Ĉio kaj la konferenca programo formiĝis: novaj kazoj, nova sperto pri uzado de Tarantool, arkitekturo, entrepreno, lerniloj kaj mikroservoj.
fonto: www.habr.com