Bakit kailangan ng isang korporasyon tulad ng MegaFon ng Tarantool sa pagsingil? Mula sa labas, tila karaniwang dumarating ang nagtitinda, nagdadala ng ilang uri ng malaking kahon, isinasaksak ang plug sa socket - at iyon ang pagsingil! Ito ay dating kaso, ngunit ngayon ito ay lipas na, at ang mga naturang dinosaur ay nawala na o nawawala na. Sa una, ang pagsingil ay isang sistema para sa pag-isyu ng mga invoice - isang makinang pagbibilang o calculator. Sa modernong telecoms ito ay sistema ng automation para sa buong ikot ng buhay ng pakikipag-ugnayan sa isang subscriber mula sa pagtatapos ng isang kontrata hanggang sa pagtatapos, kabilang ang real-time na pagsingil, pagtanggap ng pagbabayad at marami pang iba. Ang pagsingil sa mga kumpanya ng telecom ay parang combat robot - malaki, makapangyarihan at puno ng mga armas.
Ano ang kinalaman ng Tarantool dito? Pag-uusapan nila ito Oleg Ivlev ΠΈ Andrey Knyazev. Si Oleg ang punong arkitekto ng kumpanya na may malawak na karanasan sa pagtatrabaho sa mga dayuhang kumpanya, si Andrey ay direktor ng mga sistema ng negosyo. Mula sa transcript ng kanilang ulat sa malalaman mo kung bakit kailangan ang R&D sa mga korporasyon, kung ano ang Tarantool, kung paano ang hindi pagkakasundo ng vertical scaling at globalization ay naging mga kinakailangan para sa paglitaw ng database na ito sa kumpanya, tungkol sa mga teknolohikal na hamon, pagbabago ng arkitektura, at kung paano ang technostack ng MegaFon ay katulad ng Netflix , Google at Amazon.
Project "Pinag-isang Pagsingil"
Ang proyektong pinag-uusapan ay tinatawag na "Pinag-isang Pagsingil." Dito ipinakita ng Tarantool ang pinakamahusay na mga katangian nito.
Ang paglago sa produktibidad ng Hi-End equipment ay hindi nakasabay sa paglaki ng subscriber base at paglaki ng bilang ng mga serbisyo; inaasahan ang karagdagang paglaki sa bilang ng mga subscriber at serbisyo dahil sa M2M, IoT, at mga feature ng sangay na pinangunahan. sa isang pagkasira sa time-to-market. Nagpasya ang kumpanya na lumikha ng pinag-isang sistema ng negosyo na may kakaibang world-class na modular na arkitektura, sa halip na 8 kasalukuyang magkakaibang sistema ng pagsingil.
Ang MegaFon ay walong kumpanya sa isa. Noong 2009, natapos ang muling pagsasaayos: ang mga sangay sa buong Russia ay pinagsama sa isang solong kumpanya, MegaFon OJSC (ngayon ay PJSC). Kaya, ang kumpanya ay may 8 billing system na may sariling "custom" na solusyon, mga feature ng sangay at iba't ibang istruktura ng organisasyon, IT at marketing.
Maayos ang lahat hanggang sa kinailangan naming maglunsad ng isang karaniwang produktong pederal. Dito maraming mga paghihirap ang lumitaw: para sa ilan, ang mga taripa ay bilugan, para sa iba ay bilugan pababa, at para sa iba - batay sa ibig sabihin ng aritmetika. Mayroong libu-libong mga ganoong sandali.
Sa kabila ng katotohanan na mayroon lamang isang bersyon ng sistema ng pagsingil, isang tagapagtustos, ang mga setting ay nag-iba nang husto kaya't tumagal ng mahabang panahon upang magkasama. Sinubukan naming bawasan ang kanilang bilang, at nakatagpo kami ng pangalawang problema na pamilyar sa maraming mga korporasyon.
Vertical scaling. Kahit na ang pinaka-cool na hardware sa oras na iyon ay hindi nakakatugon sa mga pangangailangan. Gumamit kami ng kagamitang Hewlett-Packard mula sa linya ng Superdome Hi-End, ngunit hindi nito natugunan ang mga pangangailangan ng kahit na dalawang sangay. Gusto ko ng pahalang na pag-scale nang walang malalaking gastos sa pagpapatakbo at pamumuhunan sa kapital.
Inaasahan ang paglaki sa bilang ng mga subscriber at serbisyo. Matagal nang dinala ng mga consultant ang mga kuwento tungkol sa IoT at M2M sa mundo ng telecom: darating ang panahon na ang bawat telepono at plantsa ay magkakaroon ng SIM card, at dalawa sa refrigerator. Ngayon mayroon kaming isang bilang ng mga tagasuskribi, ngunit sa malapit na hinaharap magkakaroon ng marami pa.
Mga hamon sa teknolohiya
Ang apat na dahilan na ito ang nag-udyok sa amin na gumawa ng mga seryosong pagbabago. Nagkaroon ng pagpipilian sa pagitan ng pag-upgrade ng system at pagdidisenyo mula sa simula. Nag-isip kami ng mahabang panahon, gumawa ng mga seryosong desisyon, naglaro ng mga tender. Bilang resulta, nagpasya kaming magdisenyo mula pa sa simula, at humarap sa mga kagiliw-giliw na hamon - mga teknolohikal na hamon.
Scalability
Kung dati, letβs say, letβs say 8 pagsingil para sa 15 milyong subscriber, at ngayon ito ay dapat na gumana 100 milyong subscriber at higit pa - ang load ay isang order ng magnitude na mas mataas.
Kami ay naging maihahambing sa sukat sa malalaking manlalaro ng Internet tulad ng Mail.ru o Netflix.
Ngunit ang karagdagang paggalaw upang madagdagan ang load at subscriber base ay nagtakda ng malubhang hamon para sa amin.
Heograpiya ng ating malawak na bansa
Sa pagitan ng Kaliningrad at Vladivostok 7500 km at 10 time zone. Ang bilis ng liwanag ay may hangganan at sa ganoong mga distansya ay makabuluhan na ang mga pagkaantala. Ang 150 ms sa pinakaastig na modernong optical channel ay sobra para sa real-time na pagsingil, lalo na't ito ay nasa telecom na ngayon sa Russia. Bilang karagdagan, kailangan mong mag-update sa isang araw ng negosyo, at may iba't ibang time zone ito ay isang problema.
Hindi lang kami nagbibigay ng mga serbisyo para sa bayad sa subscription, mayroon kaming kumplikadong mga taripa, pakete, at iba't ibang modifier. Kailangan nating hindi lamang payagan o tanggihan ang subscriber na makipag-usap, ngunit bigyan siya ng isang tiyak na quota - kalkulahin ang mga tawag at aksyon sa real time upang hindi niya mapansin.
pagpaparaya sa kasalanan
Ito ang kabilang panig ng sentralisasyon.
Kung kinokolekta namin ang lahat ng mga subscriber sa isang sistema, kung gayon ang anumang mga kaganapang pang-emergency at kalamidad ay mapaminsala para sa negosyo. Samakatuwid, idinisenyo namin ang system sa paraang maalis ang epekto ng mga aksidente sa buong base ng subscriber.
Isa na naman itong kinahinatnan ng pagtanggi sa pag-scale nang patayo. Kapag nag-scale kami nang pahalang, dinagdagan namin ang bilang ng mga server mula sa daan-daan hanggang sa libo-libo. Kailangan nilang pamahalaan at mapagpalit, awtomatikong i-back up ang imprastraktura ng IT at ibalik ang ipinamahagi na sistema.
Napaharap kami sa mga kagiliw-giliw na hamon. Dinisenyo namin ang system, at sa sandaling iyon sinubukan naming maghanap ng mga pandaigdigang pinakamahuhusay na kagawian upang suriin kung gaano kami nasa uso, kung gaano kami sumusunod sa mga advanced na teknolohiya.
karanasan sa mundo
Nakapagtataka, wala kaming nakitang isang sanggunian sa global telecom.
Ang Europa ay bumagsak sa mga tuntunin ng bilang ng mga tagasuskribi at sukat, ang USA - sa mga tuntunin ng pagiging patag ng mga taripa nito. Tiningnan namin ang ilan sa China, at nakita namin ang ilan sa India at kumuha ng mga espesyalista mula sa Vodafone India.
Upang pag-aralan ang arkitektura, nag-assemble kami ng Dream Team na pinamumunuan ng IBM - mga arkitekto mula sa iba't ibang larangan. Ang mga taong ito ay maaaring sapat na masuri kung ano ang aming ginagawa at magdala ng ilang kaalaman sa aming arkitektura.
Scale
Ang ilang mga numero para sa paglalarawan.
Idinisenyo namin ang sistema para sa 80 milyong subscriber na may reserbang isang bilyon. Ito ay kung paano namin inaalis ang mga limitasyon sa hinaharap. Hindi ito dahil sakupin natin ang China, ngunit dahil sa pagsalakay ng IoT at M2M.
300 milyong dokumento ang naproseso sa real time. Bagama't mayroon kaming 80 milyong subscriber, nakikipagtulungan kami sa parehong mga potensyal na kliyente at sa mga umalis sa amin kung kailangan naming mangolekta ng mga matatanggap. Samakatuwid, ang aktwal na mga volume ay kapansin-pansing mas malaki.
2 bilyong transaksyon Ang balanse ay nagbabago araw-araw - ito ay mga pagbabayad, singil, tawag at iba pang mga kaganapan. 200 TB ng data ay aktibong nagbabago, medyo mabagal ang pagbabago 8 PB ng data, at hindi ito isang archive, ngunit live na data sa isang pagsingil. I-scale ayon sa data center - 5 libong mga server sa 14 na mga site.
Salansan ng teknolohiya
Noong pinlano namin ang arkitektura at nagsimulang tipunin ang system, nag-import kami ng mga pinakakawili-wili at advanced na teknolohiya. Ang resulta ay isang salansan ng teknolohiya na pamilyar sa sinumang manlalaro ng Internet at mga korporasyon na gumagawa ng mga high-load system.
Ang stack ay katulad ng mga stack ng iba pang mga pangunahing manlalaro: Netflix, Twitter, Viber. Binubuo ito ng 6 na bahagi, ngunit gusto naming paikliin at pag-isahin ito.
Ang kakayahang umangkop ay mabuti, ngunit sa isang malaking korporasyon walang paraan nang walang pag-iisa.
Hindi namin babaguhin ang parehong Oracle sa Tarantool. Sa katotohanan ng malalaking kumpanya, ito ay isang utopia, o isang krusada sa loob ng 5-10 taon na may hindi malinaw na kinalabasan. Ngunit ang Cassandra at Couchbase ay madaling mapalitan ng Tarantool, at iyon ang aming sinisikap.
Bakit Tarantool?
Mayroong 4 na simpleng pamantayan kung bakit pinili namin ang database na ito.
bilis. Nagsagawa kami ng mga pagsubok sa pagkarga sa mga sistemang pang-industriya ng MegaFon. Nanalo ang Tarantool - ipinakita nito ang pinakamahusay na pagganap.
Hindi ito nangangahulugan na ang ibang mga sistema ay hindi nakakatugon sa mga pangangailangan ng MegaFon. Ang mga kasalukuyang solusyon sa memorya ay napakaproduktibo na ang mga reserba ng kumpanya ay higit pa sa sapat. Ngunit kami ay interesado sa pakikitungo sa isang pinuno, at hindi sa isang taong nahuhuli, kasama ang pagsubok sa pagkarga.
Sinasaklaw ng Tarantool ang mga pangangailangan ng kumpanya kahit na sa mahabang panahon.
Gastos ng TCO. Ang suporta para sa Couchbase sa mga volume ng MegaFon ay nagkakahalaga ng astronomical na halaga ng pera, ngunit sa Tarantool ang sitwasyon ay higit na kaaya-aya, at pareho sila sa functionality.
Ang isa pang magandang tampok na bahagyang nakaimpluwensya sa aming pinili ay ang Tarantool ay gumagana nang mas mahusay sa memorya kaysa sa iba pang mga database. Nagpapakita siya pinakamataas na kahusayan.
Pagkamaaasahan. Ang MegaFon ay namumuhunan sa pagiging maaasahan, marahil higit pa sa sinuman. Kaya nang tumingin kami sa Tarantool, napagtanto namin na kailangan naming gawin itong matugunan ang aming mga kinakailangan.
Namuhunan kami ng aming oras at pananalapi, at kasama ang Mail.ru lumikha kami ng isang bersyon ng enterprise, na ginagamit na ngayon sa maraming iba pang mga kumpanya.
Ang Tarantool-enterprise ay ganap na nasiyahan sa amin sa mga tuntunin ng seguridad, pagiging maaasahan, at pag-log.
Partnership
Ang pinakamahalagang bagay para sa akin ay direktang pakikipag-ugnayan sa developer. Ito mismo ang sinuhulan ng mga lalaki mula sa Tarantool.
Kung pupunta ka sa isang manlalaro, lalo na sa isang taong nagtatrabaho sa isang anchor client, at sasabihin na kailangan mo ang database upang magawa ito, ito at ito, karaniwan niyang sinasagot:
- Okay, ilagay ang mga kinakailangan sa ibaba ng pile na iyon - balang araw, malamang na makarating tayo sa kanila.
Marami ang may roadmap para sa susunod na 2-3 taon, at halos imposibleng isama doon, ngunit ang mga developer ng Tarantool ay nakakaakit sa kanilang pagiging bukas, at hindi lamang mula sa MegaFon, at iangkop ang kanilang system sa customer. Ito ay cool at talagang gusto namin ito.
Kung saan ginamit namin ang Tarantool
Ginagamit namin ang Tarantool sa maraming elemento. Ang una ay nasa piloto, na ginawa namin sa address directory system. Sa isang pagkakataon, gusto ko itong maging isang sistema na katulad ng Yandex.Maps at Google Maps, ngunit naging medyo iba ito.
Halimbawa, ang address catalog sa interface ng pagbebenta. Sa Oracle, ang paghahanap para sa nais na address ay tumatagal ng 12-13 segundo. - hindi komportable na mga numero. Kapag lumipat kami sa Tarantool, palitan ang Oracle ng isa pang database sa console, at gawin ang parehong paghahanap, makakakuha kami ng 200x speedup! Lumilitaw ang lungsod pagkatapos ng ikatlong titik. Ngayon ay inaangkop namin ang interface upang mangyari ito pagkatapos ng una. Gayunpaman, ang bilis ng pagtugon ay ganap na naiiba - millisecond sa halip na mga segundo.
Ang pangalawang application ay isang usong tema na tinatawag na two-speed IT. Ito ay dahil ang mga consultant mula sa bawat sulok ay nagsasabi na ang mga korporasyon ay dapat pumunta doon.
Mayroong isang layer ng imprastraktura, sa itaas nito ay may mga domain, halimbawa, isang sistema ng pagsingil tulad ng isang telecom, corporate system, corporate reporting. Ito ang ubod na hindi kailangang hawakan. Iyon ay, siyempre, posible, ngunit paranoid na tinitiyak ang kalidad, dahil nagdadala ito ng pera sa korporasyon.
Susunod ay ang layer ng microservices - kung ano ang pagkakaiba sa operator o iba pang manlalaro. Mabilis na magagawa ang mga microservice batay sa ilang partikular na cache, na nagdadala ng data mula sa iba't ibang domain doon. Dito larangan para sa mga eksperimento β kung may hindi gumana, isinara ko ang isang microservice at binuksan ko ang isa pa. Nagbibigay ito ng tunay na pagtaas ng oras-sa-market at pinatataas ang pagiging maaasahan at bilis ng kumpanya.
Ang mga microservice ay marahil ang pangunahing papel ng Tarantool sa MegaFon.
Kung saan plano naming gamitin ang Tarantool
Kung ihahambing namin ang aming matagumpay na proyekto sa pagsingil sa mga programa ng pagbabago sa Deutsche Telekom, Svyazcom, Vodafone India, ito ay nakakagulat na dynamic at malikhain. Sa proseso ng pagpapatupad ng proyektong ito, hindi lamang ang MegaFon at ang istraktura nito ang nabago, kundi pati na rin ang Tarantool-enterprise ay lumitaw sa Mail.ru, at ang aming vendor na Nexign (dating Peter-Service) - BSS Box (isang boxed billing solution).
Ito ay, sa isang kahulugan, isang makasaysayang proyekto para sa merkado ng Russia. Maihahalintulad ito sa inilarawan sa aklat na βThe Mythical Man-Monthβ ni Frederick Brooks. Pagkatapos, noong dekada 60, umarkila ang IBM ng 360 tao para bumuo ng bagong OS/5 operating system para sa mga mainframe. Mayroon kaming mas kaunti - 000, ngunit ang sa amin ay nasa vests, at isinasaalang-alang ang paggamit ng open source at mga bagong diskarte, nagtatrabaho kami nang mas produktibo.
Nasa ibaba ang mga domain ng pagsingil o, sa mas malawak na pagsasalita, mga sistema ng negosyo. Alam na alam ng mga tao mula sa enterprise ang CRM. Dapat mayroon nang iba pang mga system ang lahat: Open API, API Gateway.
Buksan ang API
Tingnan natin muli ang mga numero at kung paano kasalukuyang gumagana ang Open API. Ang load nito 10 transaksyon kada segundo. Dahil plano naming aktibong bumuo ng microservices layer at bumuo ng MegaFon public API, inaasahan namin ang mas malaking paglago sa hinaharap sa bahaging ito. Tiyak na magkakaroon ng 100 na transaksyon.
Hindi ko alam kung maihahambing natin sa Mail.ru sa SSO - ang mga lalaki ay tila may 1 na transaksyon sa bawat segundo. Ang kanilang solusyon ay lubhang kawili-wili sa amin at plano naming gamitin ang kanilang karanasan - halimbawa, paggawa ng isang gumaganang SSO backup gamit ang Tarantool. Ngayon ang mga developer mula sa Mail.ru ay ginagawa ito para sa amin.
CRM
Ang CRM ay ang parehong 80 milyong subscriber na gusto nating dagdagan sa isang bilyon, dahil mayroon nang 300 milyong mga dokumento na may kasamang tatlong taong kasaysayan. Talagang inaasahan namin ang mga bagong serbisyo at narito ang punto ng paglago ay mga konektadong serbisyo. Ito ay isang bola na lalago, dahil magkakaroon ng higit pang mga serbisyo. Alinsunod dito, kakailanganin namin ng isang kuwento; hindi namin nais na matisod dito.
Ang pagsingil mismo sa mga tuntunin ng pag-isyu ng mga invoice, pakikipagtulungan sa mga account ng customer na maaaring tanggapin binago sa isang hiwalay na domain. Upang mapabuti ang pagganap, inilapat na arkitektura ng domain na pattern ng arkitektura.
Ang sistema ay nahahati sa mga domain, ang load ay ipinamamahagi at ang fault tolerance ay sinisiguro. Bukod pa rito, nagtrabaho kami sa distributed architecture.
Lahat ng iba pa ay mga solusyon sa antas ng enterprise. Sa imbakan ng tawag - 2 bilyon kada araw, 60 bilyon kada buwan. Minsan kailangan mong bilangin ang mga ito sa loob ng isang buwan, at mas mabuti itong mabilis. Pagsubaybay sa pananalapi - ito ay eksaktong parehong 300 milyon na patuloy na lumalaki at lumalaki: ang mga subscriber ay madalas na tumatakbo sa pagitan ng mga operator, na nagdaragdag sa bahaging ito.
Ang pinaka-telecom na bahagi ng mga mobile na komunikasyon ay online na taripa. Ito ang mga system na nagbibigay-daan sa iyong tumawag o hindi tumawag, gumawa ng mga desisyon sa real time. Narito ang pag-load ay 30 mga transaksyon sa bawat segundo, ngunit isinasaalang-alang ang paglago sa paglipat ng data, pinaplano namin 250 transaksyon, at samakatuwid kami ay lubhang interesado sa Tarantool.
Ang nakaraang larawan ay ang mga domain kung saan gagamitin natin ang Tarantool. Ang CRM mismo, siyempre, ay mas malawak at gagamitin natin ito sa mismong core.
Ang aming tinantyang TTX figure na 100 milyong mga subscriber ay nalilito sa akin bilang isang arkitekto - paano kung 101 milyon? Kailangan mo bang ulitin ang lahat? Upang maiwasang mangyari ito, gumagamit kami ng mga cache, kasabay ng pagpapataas ng accessibility.
Sa pangkalahatan, mayroong dalawang diskarte sa paggamit ng Tarantool. Una - buuin ang lahat ng mga cache sa antas ng microservice. Sa pagkakaintindi ko, sinusunod ng VimpelCom ang landas na ito, na lumilikha ng cache ng mga kliyente.
Hindi kami gaanong umaasa sa mga vendor, binabago namin ang core ng BSS, kaya mayroon kaming isang file ng kliyente sa labas ng kahon. Ngunit nais naming palawakin ito. Samakatuwid, kumuha kami ng isang bahagyang naiibang diskarte - gumawa ng mga cache sa loob ng mga system.
Sa ganitong paraan mayroong mas kaunting pag-synchronize - isang sistema ang may pananagutan para sa parehong cache at ang pangunahing pinagmumulan ng master.
Tamang-tama ang pamamaraan sa diskarte ng Tarantool na may transactional skeleton, kapag ang mga bahagi lamang na nauugnay sa mga update, iyon ay, ang mga pagbabago sa data, ay ina-update. Ang lahat ng iba pa ay maaaring maimbak sa ibang lugar. Walang malaking data lake, hindi pinamamahalaang global cache. Ang mga cache ay idinisenyo para sa system, o para sa mga produkto, o para sa mga kliyente, o para gawing mas madali ang buhay para sa pagpapanatili. Kapag tumawag ang isang subscriber at nagalit tungkol sa kalidad ng iyong serbisyo, gusto mong magbigay ng de-kalidad na serbisyo.
RTO at RPO
Mayroong dalawang termino sa IT - RTO ΠΈ RPO.
Layunin ng oras ng pagbawi ay ang oras na kinakailangan upang maibalik ang serbisyo pagkatapos ng pagkabigo. Ang RTO = 0 ay nangangahulugan na kahit na may mabigo, ang serbisyo ay patuloy na gagana.
Layunin ng punto ng pagbawi - ito ang oras ng pagbawi ng data, kung gaano karaming data ang maaari nating mawala sa isang tiyak na tagal ng panahon. Ang ibig sabihin ng RPO = 0 ay hindi kami nawawalan ng data.
Gawain ng Tarantool
Subukan nating lutasin ang isang problema para sa Tarantool.
Ibinigay: isang basket ng mga application na naiintindihan ng lahat, halimbawa, sa Amazon o sa ibang lugar. kailangan para gumana ang shopping cart 24 oras 7 araw sa isang linggo, o 99,99% ng oras. Ang mga order na dumarating sa amin ay dapat manatiling maayos, dahil hindi namin maaaring random na i-on o i-off ang koneksyon ng subscriber - lahat ay dapat na mahigpit na pare-pareho. Ang nakaraang subscription ay nakakaapekto sa susunod, kaya ang data ay mahalaga - walang dapat mawala.
desisyon. Maaari mong subukang lutasin ito nang direkta at tanungin ang mga developer ng database, ngunit ang problema ay hindi malulutas sa matematika. Maaalala mo ang mga theorems, mga batas sa konserbasyon, quantum physics, ngunit bakit - hindi ito malulutas sa antas ng DB.
Gumagana dito ang magandang lumang diskarte sa arkitektura - kailangan mong malaman nang mabuti ang lugar ng paksa at gamitin ito upang malutas ang puzzle na ito.
Ang aming solusyon: paglikha ng isang distributed registry ng mga application sa Tarantool - isang geo-distributed cluster. Sa diagram, ito ay tatlong magkakaibang mga sentro ng pagpoproseso ng data - dalawa bago ang mga Urals, isa sa kabila ng mga Urals, at ipinamahagi namin ang lahat ng mga kahilingan sa mga sentrong ito.
Ang Netflix, na ngayon ay itinuturing na isa sa mga nangunguna sa IT, ay mayroon lamang isang data center hanggang 2012. Sa bisperas ng Pasko ng Katoliko, Disyembre 24, bumaba ang data center na ito. Ang mga gumagamit sa Canada at USA ay naiwan nang wala ang kanilang mga paboritong pelikula, labis na nabalisa at nagsulat tungkol dito sa mga social network. Ang Netflix ay mayroon na ngayong tatlong data center sa kanluran-silangang baybayin at isa sa kanlurang Europa.
Sa una kami ay gumagawa ng isang geo-distributed na solusyon - ang fault tolerance ay mahalaga sa amin.
Kaya mayroon kaming isang kumpol, ngunit paano ang RPO = 0 at RTO = 0? Ang solusyon ay simple, depende sa paksa.
Ano ang mahalaga sa mga aplikasyon? Dalawang Bahagi: Basket Throwing SA paggawa ng desisyon sa pagbili, at PAGKATAPOS. Ang bahaging DO sa telecom ay karaniwang tinatawag pagkuha ng order o order negosasyon. Sa telecom, ito ay maaaring maging mas mahirap kaysa sa isang online na tindahan, dahil doon ang kliyente ay dapat ihain, mag-alok ng 5 mga pagpipilian, at lahat ng ito ay nangyayari nang ilang panahon, ngunit ang basket ay puno. Sa sandaling ito, posible ang isang pagkabigo, ngunit hindi ito nakakatakot, dahil ito ay nangyayari nang interactive sa ilalim ng pangangasiwa ng tao.
Kung ang sentro ng data ng Moscow ay biglang nabigo, pagkatapos ay sa pamamagitan ng awtomatikong paglipat sa isa pang sentro ng data, patuloy kaming gagana. Sa teorya, maaaring mawala ang isang produkto sa cart, ngunit nakikita mo ito, idagdag muli sa cart at magpatuloy sa pagtatrabaho. Sa kasong ito RTO = 0.
Kasabay nito, mayroong pangalawang opsyon: kapag nag-click kami sa "isumite", gusto naming hindi mawala ang data. Mula sa sandaling ito, nagsisimula nang gumana ang automation - ito ay RPO = 0. Gamit ang dalawang magkaibang pattern na ito, sa isang kaso maaari lang itong isang geo-distributed cluster na may isang switchable master, sa ibang kaso ay isang uri ng quorum record. Maaaring mag-iba ang mga pattern, ngunit nilulutas namin ang problema.
Dagdag pa, ang pagkakaroon ng isang distributed registry ng mga application, maaari din nating sukatin ang lahat ng ito - magkaroon ng maraming dispatcher at executor na nag-a-access sa registry na ito.
Magkasama sina Cassandra at Tarantool
May isa pang kaso - "showcase ng mga balanse". Narito ang isang kawili-wiling kaso ng magkasanib na paggamit ng Cassandra at Tarantool.
Ginagamit namin si Cassandra dahil 2 bilyong tawag bawat araw ay hindi ang limitasyon, at magkakaroon pa. Gustung-gusto ng mga marketer na kulayan ang trapiko ayon sa pinagmulan; parami nang parami ang mga detalyeng lumalabas sa mga social network, halimbawa. Ang lahat ng ito ay nagdaragdag sa kuwento.
Pinapayagan ka ni Cassandra na i-scale nang pahalang sa anumang laki.
Kumportable kami kay Cassandra, ngunit mayroon itong isang problema - hindi ito mahusay sa pagbabasa. Ang lahat ay OK sa pag-record, 30 bawat segundo ay hindi isang problema - problema sa pagbabasa.
Samakatuwid, lumitaw ang isang paksa na may cache, at sa parehong oras nalutas namin ang sumusunod na problema: mayroong isang lumang tradisyunal na kaso kapag ang kagamitan mula sa isang switch mula sa online na pagsingil ay pumasok sa mga file na na-load namin sa Cassandra. Nakipaglaban kami sa problema ng maaasahang pag-download ng mga file na ito, kahit na gamit ang payo ng IBM manager file transfer - may mga solusyon na mahusay na namamahala sa paglilipat ng file, gamit ang UDP protocol, halimbawa, sa halip na TCP. Ito ay mabuti, ngunit ito ay minuto pa rin, at hindi pa namin na-load ang lahat, ang operator sa call center ay hindi makasagot sa kliyente kung ano ang nangyari sa kanyang balanse - kailangan nating maghintay.
Upang maiwasang mangyari ito, kami gumagamit kami ng parallel functional reserve. Kapag nagpadala kami ng kaganapan sa pamamagitan ng Kafka sa Tarantool, muling pagkalkula ng mga pinagsama-samang real time, halimbawa, para sa araw na ito, nakukuha namin mga balanse ng cash, na maaaring maglipat ng mga balanse sa anumang bilis, halimbawa, 100 libong mga transaksyon bawat segundo at ang parehong 2 segundo.
Ang layunin ay na pagkatapos gumawa ng isang tawag, sa loob ng 2 segundo sa iyong personal na account ay magkakaroon hindi lamang ang binagong balanse, ngunit ang impormasyon tungkol sa kung bakit ito nagbago.
Konklusyon
Ito ay mga halimbawa ng paggamit ng Tarantool. Talagang nagustuhan namin ang pagiging bukas ng Mail.ru at ang kanilang pagpayag na isaalang-alang ang iba't ibang mga kaso.
Mahirap na para sa mga consultant mula sa BCG o McKinsey, Accenture o IBM na sorpresahin tayo sa isang bagong bagay - karamihan sa kanilang inaalok, maaaring nagawa na natin, nagawa na, o pinaplanong gawin. Sa tingin ko ang Tarantool ay kukuha ng nararapat na lugar sa aming stack ng teknolohiya at papalitan ang maraming umiiral na teknolohiya. Kami ay nasa aktibong yugto ng pagbuo ng proyektong ito.
Ang ulat nina Oleg at Andrey ay isa sa mga pinakamahusay sa Tarantool Conference noong nakaraang taon, at sa Hunyo 17 si Oleg Ivlev ay magsasalita sa na may ulat . Si Alexander Deulin ay magbibigay din ng isang pagtatanghal mula sa MegaFon . Alamin natin kung ano ang nagbago, kung ano ang mga plano na ipinatupad. Sumali - ang kumperensya ay libre, ang kailangan mo lang gawin ay . Lahat at ang programa ng kumperensya ay nabuo: mga bagong kaso, bagong karanasan sa paggamit ng Tarantool, arkitektura, negosyo, mga tutorial at microservice.
Pinagmulan: www.habr.com