Kwa nini shirika kama MegaFon linahitaji Tarantool katika malipo? Kutoka nje inaonekana kwamba muuzaji kawaida huja, huleta aina fulani ya sanduku kubwa, huunganisha kuziba kwenye tundu - na hiyo ni bili! Hivi ndivyo ilivyokuwa, lakini sasa ni ya kizamani, na dinosaurs kama hizo tayari zimetoweka au zinatoweka. Hapo awali, bili ni mfumo wa kutoa ankara - mashine ya kuhesabu au kikokotoo. Katika mawasiliano ya kisasa hii ni mfumo wa otomatiki kwa mzunguko mzima wa maisha wa mwingiliano na mteja kutoka kwa hitimisho la mkataba hadi kumalizika, ikiwa ni pamoja na malipo ya wakati halisi, kukubalika kwa malipo na mengi zaidi. Malipo katika makampuni ya mawasiliano ya simu ni kama roboti ya kivita - kubwa, yenye nguvu na iliyosheheni silaha.
Tarantool ina uhusiano gani nayo? Watazungumza juu yake Oleg Ivlev ΠΈ Andrey Knyazev. Oleg ndiye mbunifu mkuu wa kampuni hiyo na uzoefu mkubwa wa kufanya kazi katika makampuni ya kigeni, Andrey ni mkurugenzi wa mifumo ya biashara. Kutoka kwa nakala ya ripoti yao utajifunza kwa nini R&D inahitajika katika mashirika, Tarantool ni nini, jinsi mkwamo wa kuongeza wima na utandawazi umekuwa sharti la kuonekana kwa hifadhidata hii katika kampuni, kuhusu changamoto za kiteknolojia, mabadiliko ya usanifu, na jinsi teknolojia ya MegaFon inavyofanana na Netflix. , Google na Amazon.
Mradi "Malipo ya Pamoja"
Mradi unaohusika unaitwa "Malipo ya Pamoja". Ilikuwa hapa kwamba Tarantool ilionyesha sifa zake bora.
Ukuaji wa tija ya vifaa vya Hi-End haukuendana na ukuaji wa wateja na ukuaji wa idadi ya huduma; ukuaji zaidi wa idadi ya waliojisajili na huduma ulitarajiwa kutokana na M2M, IoT, na vipengele vya tawi vinavyoongozwa. kwa kuzorota kwa wakati hadi soko. Kampuni iliamua kuunda mfumo wa biashara wa umoja na usanifu wa kipekee wa kiwango cha ulimwengu wa moduli, badala ya mifumo 8 ya sasa ya utozaji tofauti.
MegaFon ni kampuni nane katika moja. Mnamo 2009, upangaji upya ulikamilishwa: matawi kote Urusi yaliunganishwa kuwa kampuni moja, MegaFon OJSC (sasa PJSC). Kwa hivyo, kampuni ina mifumo 8 ya utozaji yenye masuluhisho yao ya "desturi", vipengele vya matawi na miundo tofauti ya shirika, IT na uuzaji.
Kila kitu kilikuwa sawa hadi tukalazimika kuzindua bidhaa moja ya kawaida ya shirikisho. Hapa shida nyingi ziliibuka: kwa wengine, ushuru umezungushwa, kwa wengine kuzungushwa chini, na kwa wengine - kulingana na maana ya hesabu. Kuna maelfu ya wakati kama huo.
Licha ya ukweli kwamba kulikuwa na toleo moja tu la mfumo wa bili, muuzaji mmoja, mipangilio ilitofautiana sana hivi kwamba ilichukua muda mrefu kuweka pamoja. Tulijaribu kupunguza idadi yao, na tukakutana na shida ya pili ambayo inajulikana kwa mashirika mengi.
Kuongeza wima. Hata vifaa vya baridi zaidi wakati huo havikukidhi mahitaji. Tulitumia vifaa vya Hewlett-Packard kutoka kwa laini ya Superdome Hi-End, lakini haikukidhi mahitaji ya matawi mawili. Nilitaka kuongeza usawa bila gharama kubwa za uendeshaji na uwekezaji wa mtaji.
Matarajio ya ukuaji wa idadi ya waliojisajili na huduma. Washauri kwa muda mrefu wameleta hadithi kuhusu IoT na M2M kwa ulimwengu wa mawasiliano: wakati utakuja ambapo kila simu na chuma vitakuwa na SIM kadi, na mbili kwenye jokofu. Leo tuna idadi moja ya waliojiandikisha, lakini katika siku za usoni kutakuwa na wengi zaidi.
Changamoto za kiteknolojia
Sababu hizi nne zilituchochea kufanya mabadiliko makubwa. Kulikuwa na chaguo kati ya kuboresha mfumo na kubuni kutoka mwanzo. Tulifikiria kwa muda mrefu, tukafanya maamuzi mazito, tukacheza zabuni. Kama matokeo, tuliamua kubuni tangu mwanzo, na tukachukua changamoto za kupendeza - changamoto za kiteknolojia.
Scalability
Ikiwa ilikuwa hapo awali, wacha tuseme, tuseme Bili 8 kwa watumizi milioni 15, na sasa ingepaswa kufanya kazi Wasajili milioni 100 na zaidi - mzigo ni amri ya ukubwa wa juu.
Tumelinganishwa kwa kiwango na wachezaji wakubwa wa Mtandao kama Mail.ru au Netflix.
Lakini harakati zaidi za kuongeza upakiaji na msingi wa watumiaji zimeweka changamoto kubwa kwetu.
Jiografia ya nchi yetu kubwa
Kati ya Kaliningrad na Vladivostok 7500 km na kanda 10 za wakati. Kasi ya mwanga ni kikomo na kwa umbali kama huo ucheleweshaji tayari ni muhimu. 150 ms kwenye chaneli nzuri za kisasa za macho ni nyingi mno kwa kutozwa kwa wakati halisi, hasa kama ilivyo sasa katika mawasiliano ya simu nchini Urusi. Kwa kuongeza, unahitaji kusasisha katika siku moja ya biashara, na kwa maeneo tofauti ya wakati hii ni tatizo.
Hatutoi tu huduma kwa ada ya usajili, tuna ushuru tata, vifurushi na virekebishaji mbalimbali. Hatuhitaji tu kuruhusu au kukataa mteja kuzungumza, lakini kumpa kiasi fulani - kuhesabu simu na vitendo kwa wakati halisi ili asitambue.
uvumilivu wa makosa
Huu ni upande mwingine wa centralization.
Ikiwa tutakusanya wanachama wote katika mfumo mmoja, basi matukio yoyote ya dharura na maafa ni mabaya kwa biashara. Kwa hivyo, tunaunda mfumo kwa njia ya kuondoa athari za ajali kwenye msingi wote wa watumiaji.
Haya ni matokeo ya kukataa kuongeza wima. Tulipoongeza usawa, tuliongeza idadi ya seva kutoka mamia hadi maelfu. Wanahitaji kusimamiwa na kubadilishana, kuunga mkono kiotomatiki miundombinu ya IT na kurejesha mfumo uliosambazwa.
Tulikabili changamoto hizo za kuvutia. Tulibuni mfumo, na wakati huo tulijaribu kutafuta mbinu bora za kimataifa ili kuangalia jinsi tulivyo katika mtindo, na kwa kiasi gani tunafuata teknolojia za hali ya juu.
Uzoefu wa ulimwengu
Kwa kushangaza, hatukupata rejeleo moja katika telecom ya kimataifa.
Ulaya imeporomoka kwa suala la idadi ya waliojiandikisha na kiwango, USA - kwa suala la usawa wa ushuru wake. Tuliangalia baadhi nchini Uchina, na tukapata baadhi nchini India na tukaajiri wataalamu kutoka Vodafone India.
Ili kuchambua usanifu, tulikusanya Timu ya Ndoto inayoongozwa na IBM - wasanifu kutoka nyanja tofauti. Watu hawa wanaweza kutathmini vya kutosha kile tulichokuwa tukifanya na kuleta ujuzi fulani kwenye usanifu wetu.
Kiwango
Nambari chache kwa mfano.
Tunatengeneza mfumo kwa milioni 80 waliojiandikisha na akiba ya bilioni moja. Hivi ndivyo tunavyoondoa vizingiti vya siku zijazo. Hii si kwa sababu tutaichukua China, lakini kwa sababu ya mashambulizi ya IoT na M2M.
Hati milioni 300 zilizochakatwa kwa wakati halisi. Ingawa tuna watumiaji milioni 80 wanaojisajili, tunafanya kazi na wateja watarajiwa na wale ambao wametuacha ikiwa tunahitaji kukusanya mapato. Kwa hivyo, idadi halisi ni kubwa zaidi.
2 bilioni miamala Salio hubadilika kila siku - haya ni malipo, malipo, simu na matukio mengine. 200 TB ya data inabadilika kikamilifu, badilisha polepole kidogo 8 PB ya data, na hii si kumbukumbu, lakini data ya moja kwa moja katika bili moja. Pima kwa kituo cha data - Seva elfu 5 kwenye tovuti 14.
Mkusanyiko wa teknolojia
Tulipopanga usanifu na kuanza kukusanyika mfumo, tuliagiza teknolojia za kuvutia zaidi na za juu. Matokeo yake ni mkusanyiko wa teknolojia unaojulikana kwa kicheza Intaneti na mashirika yoyote yanayotengeneza mifumo yenye upakiaji wa juu.
Mkusanyiko huo ni sawa na safu za wachezaji wengine wakuu: Netflix, Twitter, Viber. Inajumuisha vipengele 6, lakini tunataka kuifupisha na kuiunganisha.
Kubadilika ni nzuri, lakini katika shirika kubwa hakuna njia bila kuunganishwa.
Hatutabadilisha Oracle sawa kuwa Tarantool. Katika hali halisi ya makampuni makubwa, hii ni utopia, au crusade kwa miaka 5-10 na matokeo yasiyo wazi. Lakini Cassandra na Couchbase zinaweza kubadilishwa kwa urahisi na Tarantool, na hilo ndilo tunalojitahidi.
Kwa nini Tarantool?
Kuna vigezo 4 rahisi kwa nini tulichagua hifadhidata hii.
Kasi. Tulifanya vipimo vya mzigo kwenye mifumo ya viwanda ya MegaFon. Tarantool ilishinda - ilionyesha utendaji bora.
Hii haimaanishi kuwa mifumo mingine haikidhi mahitaji ya MegaFon. Suluhu za kumbukumbu za sasa zinazaa sana kwamba akiba ya kampuni ni zaidi ya kutosha. Lakini tuna nia ya kushughulika na kiongozi, na si kwa mtu ambaye ni nyuma, ikiwa ni pamoja na katika mtihani wa mzigo.
Tarantool inashughulikia mahitaji ya kampuni hata kwa muda mrefu.
gharama ya TCO. Usaidizi wa Couchbase kwenye juzuu za MegaFon hugharimu kiasi cha pesa cha astronomia, lakini kwa Tarantool hali ni ya kupendeza zaidi, na zinafanana katika utendakazi.
Kipengele kingine kizuri ambacho kiliathiri kidogo chaguo letu ni kwamba Tarantool inafanya kazi vizuri na kumbukumbu kuliko hifadhidata zingine. Anaonyesha ufanisi mkubwa.
Kuegemea. MegaFon inawekeza katika kuegemea, labda zaidi ya mtu mwingine yeyote. Kwa hivyo tulipoangalia Tarantool, tuligundua kwamba tulipaswa kuifanya kukidhi mahitaji yetu.
Tuliwekeza muda wetu na fedha, na pamoja na Mail.ru tuliunda toleo la biashara, ambalo sasa linatumika katika makampuni mengine kadhaa.
Tarantool-biashara ilitutosheleza kabisa katika masuala ya usalama, kuegemea, na ukataji miti.
Ushirikiano
Jambo muhimu zaidi kwangu ni mawasiliano ya moja kwa moja na msanidi programu. Hivi ndivyo watu wa Tarantool walihonga nayo.
Ikiwa unakuja kwa mchezaji, haswa anayefanya kazi na mteja wa nanga, na kusema kwamba unahitaji hifadhidata kuweza kufanya hivi, hivi na hivi, kawaida hujibu:
- Sawa, weka mahitaji chini ya rundo hilo - siku moja, labda tutafika kwao.
Wengi wana ramani ya barabara kwa miaka 2-3 ijayo, na karibu haiwezekani kuunganishwa huko, lakini watengenezaji wa Tarantool huvutia kwa uwazi wao, na sio tu kutoka kwa MegaFon, na kurekebisha mfumo wao kwa mteja. Ni poa na tunaipenda sana.
Ambapo tulitumia Tarantool
Tunatumia Tarantool katika vipengele kadhaa. Ya kwanza iko kwenye majaribio, ambayo tulifanya kwenye mfumo wa saraka ya anwani. Wakati mmoja nilitaka kuwa mfumo unaofanana na Yandex.Maps na Ramani za Google, lakini ikawa tofauti kidogo.
Kwa mfano, katalogi ya anwani katika kiolesura cha mauzo. Kwenye Oracle, kutafuta anwani inayotakiwa huchukua sekunde 12-13. - nambari zisizofurahi. Tunapobadilisha hadi Tarantool, badala ya Oracle na hifadhidata nyingine kwenye koni, na kufanya utafutaji sawa, tunapata kasi ya 200x! Jiji linaibuka baada ya herufi ya tatu. Sasa tunarekebisha kiolesura ili hii ifanyike baada ya ile ya kwanza. Walakini, kasi ya majibu ni tofauti kabisa - milliseconds badala ya sekunde.
Programu ya pili ni mada ya mtindo inayoitwa IT ya kasi mbili. Hii ni kwa sababu washauri kutoka kila kona wanasema kwamba mashirika yaende huko.
Kuna safu ya miundombinu, juu yake kuna vikoa, kwa mfano, mfumo wa utozaji kama vile mawasiliano ya simu, mifumo ya ushirika, kuripoti shirika. Huu ndio msingi ambao hauitaji kuguswa. Hiyo ni, bila shaka, inawezekana, lakini paranoidly kuhakikisha ubora, kwa sababu huleta fedha kwa shirika.
Ifuatayo inakuja safu ya huduma ndogo - ni nini kinachofautisha mwendeshaji au mchezaji mwingine. Microservices zinaweza kuundwa kwa haraka kulingana na cache fulani, kuleta data kutoka kwa vikoa tofauti huko. Hapa shamba kwa majaribio - ikiwa kitu haikufanya kazi, nilifunga microservice moja na kufungua nyingine. Hii inatoa kweli kuongezeka kwa wakati hadi soko na huongeza kuegemea na kasi ya kampuni.
Microservices labda ni jukumu kuu la Tarantool huko MegaFon.
Ambapo tunapanga kutumia Tarantool
Ikiwa tutalinganisha mradi wetu wa utozaji uliofaulu na programu za mabadiliko katika Deutsche Telekom, Svyazcom, Vodafone India, ni wa kushangaza na wenye ubunifu. Katika mchakato wa kutekeleza mradi huu, sio tu MegaFon na muundo wake ulibadilishwa, lakini pia Tarantool-biashara ilionekana kwenye Mail.ru, na muuzaji wetu Nexign (zamani Peter-Service) - BSS Box (suluhisho la bili la sanduku).
Hii ni, kwa maana, mradi wa kihistoria kwa soko la Urusi. Inaweza kulinganishwa na kile kinachofafanuliwa katika kitabu βThe Mythical Man-Monthβ na Frederick Brooks. Kisha, katika miaka ya 60, IBM iliajiri watu 360 ili kuendeleza mfumo mpya wa uendeshaji wa OS/5 kwa mainframes. Tuna chini - 000, lakini yetu ni katika vests, na kwa kuzingatia matumizi ya chanzo wazi na mbinu mpya, tunafanya kazi kwa tija zaidi.
Ifuatayo ni vikoa vya utozaji au, kwa upana zaidi, mifumo ya biashara. Watu kutoka kwa biashara wanajua CRM vizuri sana. Kila mtu anapaswa kuwa na mifumo mingine tayari: Fungua API, Lango la API.
Fungua API
Wacha tuangalie nambari tena na jinsi Open API inavyofanya kazi kwa sasa. Mzigo wake ni miamala 10 kwa sekunde. Kwa kuwa tunapanga kuendeleza kikamilifu safu ya huduma ndogo na kujenga API ya umma ya MegaFon, tunatarajia ukuaji mkubwa zaidi katika siku zijazo katika sehemu hii. Hakika kutakuwa na miamala 100.
Sijui kama tunaweza kulinganisha na Mail.ru katika SSO - wavulana wanaonekana kuwa na miamala 1 kwa sekunde. Suluhisho lao linatuvutia sana na tunapanga kutumia uzoefu wao - kwa mfano, kutengeneza nakala inayofanya kazi ya SSO kwa kutumia Tarantool. Sasa watengenezaji kutoka Mail.ru wanatufanyia hili.
CRM
CRM ni sawa na watumizi milioni 80 ambao tunataka kuongeza hadi bilioni, kwa sababu tayari kuna hati milioni 300 ambazo zinajumuisha historia ya miaka mitatu. Tunatazamia huduma mpya na hapa hatua ya ukuaji ni huduma zilizounganishwa. Huu ni mpira ambao utakua, kwa sababu kutakuwa na huduma zaidi na zaidi. Ipasavyo, tutahitaji hadithi; hatutaki kujikwaa juu ya hili.
Kujitoza yenyewe kulingana na utoaji wa ankara, kufanya kazi na akaunti za wateja zinazopokelewa kubadilishwa kuwa kikoa tofauti. Ili kuboresha utendaji, usanifu wa usanifu wa kikoa uliotumika.
Mfumo umegawanywa katika vikoa, mzigo unasambazwa na uvumilivu wa makosa huhakikishwa. Zaidi ya hayo, tulifanya kazi na usanifu uliosambazwa.
Kila kitu kingine ni suluhisho za kiwango cha biashara. Katika hifadhi ya simu - 2 bilioni kwa siku, bilioni 60 kwa mwezi. Wakati mwingine unapaswa kuzihesabu kwa mwezi, na ni bora haraka. Ufuatiliaji wa fedha - hii ni sawa na milioni 300 ambayo inakua na kukua mara kwa mara: wanachama mara nyingi huendesha kati ya waendeshaji, na kuongeza sehemu hii.
Sehemu kubwa ya mawasiliano ya simu ya rununu ni bili ya mtandaoni. Hizi ni mifumo inayokuwezesha kupiga simu au kutoita, kufanya maamuzi kwa wakati halisi. Hapa mzigo ni shughuli 30 kwa sekunde, lakini kwa kuzingatia ukuaji wa uhamishaji data, tunapanga. 250 shughuli, na kwa hivyo tunavutiwa sana na Tarantool.
Picha iliyotangulia ni vikoa ambapo tutatumia Tarantool. CRM yenyewe, bila shaka, ni pana na tutaitumia katika msingi yenyewe.
Idadi yetu ya makadirio ya TTX ya watumiaji milioni 100 inanichanganya kama mbunifu - vipi ikiwa milioni 101? Je, ni lazima ufanye upya kila kitu tena? Ili kuzuia hili kutokea, tunatumia cache, wakati huo huo kuongeza upatikanaji.
Kwa ujumla, kuna njia mbili za kutumia Tarantool. Kwanza - jenga cache zote kwenye kiwango cha huduma ndogo. Kwa kadiri ninavyoelewa, VimpelCom inafuata njia hii, na kuunda kashe ya wateja.
Hatutegemei zaidi wachuuzi, tunabadilisha msingi wa BSS, kwa hivyo tuna faili moja ya mteja nje ya boksi. Lakini tunataka kuipanua. Kwa hivyo, tunachukua njia tofauti kidogo - tengeneza cache ndani ya mifumo.
Kwa njia hii kuna maingiliano kidogo - mfumo mmoja unawajibika kwa kache na chanzo kikuu kikuu.
Njia hiyo inafaa vizuri na mbinu ya Tarantool na mifupa ya shughuli, wakati sehemu tu zinazohusiana na sasisho, yaani, mabadiliko ya data, yanasasishwa. Kila kitu kingine kinaweza kuhifadhiwa mahali pengine. Hakuna ziwa kubwa la data, akiba ya kimataifa isiyodhibitiwa. Akiba imeundwa kwa ajili ya mfumo, au kwa ajili ya bidhaa, au kwa ajili ya wateja, au kurahisisha maisha kwa ajili ya matengenezo. Wakati mteja anapiga simu na kusikitishwa na ubora wa huduma yako, unataka kutoa huduma bora.
RTO na RPO
Kuna maneno mawili katika IT - RTO ΠΈ RPO.
Lengo la muda wa kurejesha ni wakati inachukua kurejesha huduma baada ya kushindwa. RTO = 0 inamaanisha kuwa hata ikiwa kitu kitashindwa, huduma inaendelea kufanya kazi.
Lengo la hatua ya kurejesha - huu ni wakati wa kurejesha data, ni data ngapi tunaweza kupoteza kwa kipindi fulani cha muda. RPO = 0 inamaanisha kuwa hatupotezi data.
Kazi ya Tarantool
Hebu jaribu kutatua tatizo kwa Tarantool.
Imetolewa: kikapu cha maombi ambacho kila mtu anaelewa, kwa mfano, katika Amazon au mahali pengine. Inahitajika ili gari la ununuzi lifanye kazi masaa 24 siku 7 kwa wiki, au 99,99% ya wakati huo. Maagizo yanayokuja kwetu lazima yabaki kwa mpangilio, kwa sababu hatuwezi kuwasha au kuzima muunganisho wa mteja kwa nasibu - kila kitu lazima kiwe thabiti. Usajili uliopita unaathiri ijayo, kwa hivyo data ni muhimu - hakuna kitu kinachopaswa kukosa.
uamuzi. Unaweza kujaribu kuitatua ana kwa ana na kuuliza watengenezaji wa hifadhidata, lakini tatizo haliwezi kutatuliwa kihisabati. Unaweza kukumbuka nadharia, sheria za uhifadhi, fizikia ya quantum, lakini kwa nini - haiwezi kutatuliwa kwa kiwango cha DB.
Mbinu nzuri ya zamani ya usanifu inafanya kazi hapa - unahitaji kujua eneo la somo vizuri na utumie kutatua fumbo hili.
Suluhisho letu: kuunda sajili iliyosambazwa ya programu kwenye Tarantool - nguzo iliyosambazwa kijiografia.. Katika mchoro, hivi ni vituo vitatu tofauti vya usindikaji wa data - mbili kabla ya Urals, moja zaidi ya Urals, na tunasambaza maombi yote kati ya vituo hivi.
Netflix, ambayo sasa inachukuliwa kuwa mmoja wa viongozi katika IT, ilikuwa na kituo kimoja tu cha data hadi 2012. Katika mkesha wa Krismasi ya Kikatoliki, Desemba 24, kituo hiki cha data kilianguka. Watumiaji nchini Kanada na USA waliachwa bila filamu zao zinazopenda, walikasirika sana na waliandika juu yake kwenye mitandao ya kijamii. Netflix sasa ina vituo vitatu vya data kwenye pwani ya magharibi-mashariki na moja magharibi mwa Ulaya.
Hapo awali tunaunda suluhisho la kusambazwa kwa geo - uvumilivu wa makosa ni muhimu kwetu.
Kwa hivyo tunayo nguzo, lakini vipi kuhusu RPO = 0 na RTO = 0? Suluhisho ni rahisi, kulingana na mada.
Ni nini muhimu katika maombi? Sehemu Mbili: Kutupa Vikapu TO kufanya uamuzi wa ununuzi, na BAADA. Sehemu ya DO katika telecom kawaida huitwa kukamata amri au kuagiza mazungumzo. Katika telecom, hii inaweza kuwa ngumu zaidi kuliko katika duka la mtandaoni, kwa sababu kuna mteja lazima atumiwe, kutoa chaguzi 5, na hii yote hutokea kwa muda fulani, lakini kikapu kinajazwa. Kwa wakati huu, kutofaulu kunawezekana, lakini sio ya kutisha, kwa sababu hufanyika kwa maingiliano chini ya usimamizi wa mwanadamu.
Ikiwa kituo cha data cha Moscow kinashindwa ghafla, basi kwa kubadili moja kwa moja kwenye kituo kingine cha data, tutaendelea kufanya kazi. Kinadharia, bidhaa moja inaweza kupotea kwenye gari, lakini unaona, ongeza kwenye gari tena na uendelee kufanya kazi. Katika kesi hii, RTO = 0.
Wakati huo huo, kuna chaguo la pili: tulipobofya "wasilisha", tunataka data isipotee. Kuanzia wakati huu na kuendelea, otomatiki huanza kufanya kazi - hii ni RPO = 0. Kutumia mifumo hii miwili tofauti, katika hali moja inaweza tu kuwa nguzo iliyosambazwa kijiografia na bwana mmoja anayeweza kubadilika, katika hali nyingine aina fulani ya rekodi ya akidi. Sampuli zinaweza kutofautiana, lakini tunatatua tatizo.
Zaidi ya hayo, kuwa na sajili iliyosambazwa ya programu, tunaweza pia kuipima yote - kuwa na wapelekaji na watekelezaji wengi ambao wanapata sajili hii.
Cassandra na Tarantool pamoja
Kuna kesi nyingine - "maonyesho ya mizani". Hapa kuna kesi ya kuvutia ya matumizi ya pamoja ya Cassandra na Tarantool.
Tunatumia Cassandra kwa sababu simu bilioni 2 kwa siku sio kikomo, na kutakuwa na zaidi. Wauzaji wanapenda kupaka rangi trafiki kulingana na chanzo; maelezo zaidi na zaidi yanaonekana kwenye mitandao ya kijamii, kwa mfano. Yote yanaongeza kwenye hadithi.
Cassandra hukuruhusu kuongeza usawa kwa saizi yoyote.
Tunajisikia vizuri na Cassandra, lakini ina tatizo moja - si nzuri katika kusoma. Kila kitu kiko sawa kwenye kurekodi, 30 kwa sekunde sio shida - tatizo la kusoma.
Kwa hiyo, mada yenye cache ilionekana, na wakati huo huo tulitatua tatizo lifuatalo: kuna kesi ya jadi ya zamani wakati vifaa kutoka kwa kubadili kutoka kwa malipo ya mtandaoni vinakuja kwenye faili ambazo tunapakia kwenye Cassandra. Tulijitahidi na tatizo la upakuaji wa kuaminika wa faili hizi, hata kwa kutumia ushauri wa uhamisho wa faili wa meneja wa IBM - kuna ufumbuzi unaosimamia uhamisho wa faili kwa ufanisi, kwa kutumia itifaki ya UDP, kwa mfano, badala ya TCP. Hii ni nzuri, lakini bado ni dakika, na bado hatujapakia yote, mwendeshaji katika kituo cha simu hawezi kumjibu mteja kilichotokea kwa salio lake - tunapaswa kusubiri.
Ili kuzuia hili kutokea, sisi tunatumia hifadhi ya kazi sambamba. Tunapotuma tukio kupitia Kafka hadi Tarantool, tukikokotoa upya hesabu kwa wakati halisi, kwa mfano, kwa leo, tunapata mizani ya fedha, ambayo inaweza kuhamisha mizani kwa kasi yoyote, kwa mfano, shughuli elfu 100 kwa sekunde na sekunde hizo 2.
Lengo ni kwamba baada ya kupiga simu, ndani ya sekunde 2 katika akaunti yako ya kibinafsi hakutakuwa na usawa uliobadilishwa tu, lakini taarifa kuhusu kwa nini ilibadilika.
Hitimisho
Hii ilikuwa mifano ya kutumia Tarantool. Tulipenda sana uwazi wa Mail.ru na nia yao ya kuzingatia kesi tofauti.
Tayari ni vigumu kwa washauri kutoka BCG au McKinsey, Accenture au IBM kutushangaza na kitu kipya - mengi ya kile wanachotoa, ambacho tayari tunafanya, tumefanya, au tunapanga kufanya. Nadhani Tarantool itachukua nafasi yake ifaayo katika safu yetu ya teknolojia na itachukua nafasi ya teknolojia nyingi zilizopo. Tuko katika hatua hai ya maendeleo ya mradi huu.
Ripoti ya Oleg na Andrey ni moja ya bora zaidi katika Mkutano wa Tarantool mwaka jana, na mnamo Juni 17 Oleg Ivlev atazungumza huko. na ripoti . Alexander Deulin pia atatoa mada kutoka MegaFon . Wacha tujue ni nini kimebadilika, ni mipango gani imetekelezwa. Jiunge - mkutano haulipishwi, unachotakiwa kufanya ni . Wote na programu ya mkutano imeundwa: kesi mpya, uzoefu mpya katika kutumia Tarantool, usanifu, biashara, mafunzo na huduma ndogo ndogo.
Chanzo: mapenzi.com