Pam mae angen Tarantool ar gorfforaeth fel MegaFon mewn bilio? O'r tu allan mae'n ymddangos bod y gwerthwr fel arfer yn dod, yn dod â rhyw fath o flwch mawr, yn plygio'r plwg i'r soced - a dyna bilio! Roedd hyn yn wir unwaith, ond nawr mae'n hynafol, ac mae deinosoriaid o'r fath eisoes wedi diflannu neu'n diflannu. I ddechrau, mae bilio yn system ar gyfer cyhoeddi anfonebau - peiriant cyfrif neu gyfrifiannell. Mewn telathrebu modern mae hyn system awtomeiddio ar gyfer cylch bywyd cyfan rhyngweithio â thanysgrifiwr o ddiwedd contract hyd at derfynu, gan gynnwys bilio amser real, derbyn taliad a llawer mwy. Mae bilio mewn cwmnïau telathrebu fel robot ymladd - mawr, pwerus ac yn llawn arfau.
Beth sydd gan Tarantool i'w wneud ag ef? Byddan nhw'n siarad amdano Oleg Ivlev и Andrey Knyazev. Oleg yw prif bensaer y cwmni gyda phrofiad helaeth o weithio mewn cwmnïau tramor, mae Andrey yn gyfarwyddwr systemau busnes. O'r trawsgrifiad o'u hadroddiad ar byddwch yn dysgu pam mae angen ymchwil a datblygu mewn corfforaethau, beth yw Tarantool, sut y daeth cyfyngder graddio fertigol a globaleiddio yn rhagofynion ar gyfer ymddangosiad y gronfa ddata hon yn y cwmni, am heriau technolegol, trawsnewid pensaernïol, a sut mae technostack MegaFon yn debyg i Netflix , Google ac Amazon.
Prosiect "Biliau Unedig"
Enw’r prosiect dan sylw yw “Biliau Unedig”. Yma y dangosodd Tarantool ei rinweddau gorau.
Nid oedd y twf mewn cynhyrchiant offer Hi-End yn cyd-fynd â thwf y sylfaen tanysgrifwyr a'r twf yn nifer y gwasanaethau; roedd disgwyl twf pellach yn nifer y tanysgrifwyr a gwasanaethau oherwydd M2M, IoT, a nodweddion cangen dan arweiniad i ddirywiad mewn amser i'r farchnad. Penderfynodd y cwmni greu system fusnes unedig gyda phensaernïaeth fodiwlaidd unigryw o'r radd flaenaf, yn lle 8 system bilio wahanol gyfredol.
Mae MegaFon yn wyth cwmni mewn un. Yn 2009, cwblhawyd yr ad-drefnu: unodd canghennau ledled Rwsia yn un cwmni, MegaFon OJSC (PJSC bellach). Felly, mae gan y cwmni 8 system bilio gyda'u datrysiadau “cwsmer” eu hunain, nodweddion cangen a gwahanol strwythurau sefydliadol, TG a marchnata.
Roedd popeth yn iawn nes bod yn rhaid i ni lansio un cynnyrch ffederal cyffredin. Yma cododd llawer o anawsterau: i rai, mae tariffau'n cael eu talgrynnu, i eraill wedi'u talgrynnu i lawr, ac i eraill - yn seiliedig ar y cymedr rhifyddol. Mae miloedd o eiliadau o'r fath.
Er gwaethaf y ffaith mai dim ond un fersiwn o'r system filio oedd, sef un cyflenwr, roedd y gosodiadau'n amrywio cymaint nes iddi gymryd amser hir i'w rhoi at ei gilydd. Fe wnaethon ni geisio lleihau eu nifer, a dod ar draws ail broblem sy'n gyfarwydd i lawer o gorfforaethau.
Graddio fertigol. Nid oedd hyd yn oed y caledwedd oeraf ar y pryd yn bodloni'r anghenion. Fe wnaethon ni ddefnyddio offer Hewlett-Packard o linell Superdome Hi-End, ond nid oedd yn bodloni anghenion hyd yn oed dwy gangen. Roeddwn i eisiau graddio llorweddol heb gostau gweithredu mawr a buddsoddiadau cyfalaf.
Disgwyl twf yn nifer y tanysgrifwyr a gwasanaethau. Mae ymgynghorwyr wedi dod â straeon am IoT a M2M i'r byd telathrebu ers tro: daw'r amser pan fydd gan bob ffôn a haearn gerdyn SIM, a dau yn yr oergell. Heddiw mae gennym un nifer o danysgrifwyr, ond yn y dyfodol agos bydd llawer mwy.
Heriau technolegol
Roedd y pedwar rheswm hyn yn ein hysgogi i wneud newidiadau difrifol. Roedd dewis rhwng uwchraddio'r system a dylunio o'r newydd. Buom yn meddwl am amser hir, gwneud penderfyniadau difrifol, chwarae tendrau. O ganlyniad, penderfynasom ddylunio o'r cychwyn cyntaf, a chymerwyd heriau diddorol - heriau technolegol.
Scalability
Os oedd o'r blaen, gadewch i ni ddweud, gadewch i ni ddweud 8 bil ar gyfer 15 miliwn o danysgrifwyr, ac yn awr dylai fod wedi gweithio 100 miliwn o danysgrifwyr a mwy - mae'r llwyth yn orchymyn maint yn uwch.
Rydym wedi dod yn debyg o ran graddfa i chwaraewyr Rhyngrwyd mawr fel Mail.ru neu Netflix.
Ond mae'r symudiad pellach i gynyddu'r llwyth a'r sylfaen tanysgrifwyr wedi gosod heriau difrifol i ni.
Daearyddiaeth ein gwlad helaeth
Rhwng Kaliningrad a Vladivostok 7500 km a 10 parth amser. Mae cyflymder golau yn gyfyngedig ac ar bellteroedd o'r fath mae'r oedi eisoes yn sylweddol. Mae 150 ms ar y sianeli optegol modern cŵl yn ormod ar gyfer bilio amser real, yn enwedig gan ei fod nawr mewn telathrebu yn Rwsia. Yn ogystal, mae angen i chi ddiweddaru mewn un diwrnod busnes, a chyda gwahanol barthau amser mae hyn yn broblem.
Nid ydym yn darparu gwasanaethau am ffi tanysgrifio yn unig, mae gennym dariffau cymhleth, pecynnau, ac amrywiol addaswyr. Mae angen i ni nid yn unig ganiatáu neu wadu'r tanysgrifiwr i siarad, ond rhoi cwota penodol iddo - cyfrifo galwadau a chamau gweithredu mewn amser real fel nad yw'n sylwi.
goddefgarwch fai
Dyma ochr arall canoli.
Os byddwn yn casglu'r holl danysgrifwyr mewn un system, yna mae unrhyw ddigwyddiadau brys a thrychinebau yn drychinebus i fusnes. Felly, rydym yn dylunio'r system mewn ffordd sy'n dileu effaith damweiniau ar y sylfaen tanysgrifwyr gyfan.
Mae hyn eto o ganlyniad i'r gwrthodiad i raddfa fertigol. Pan wnaethom raddio'n llorweddol, fe wnaethom gynyddu nifer y gweinyddwyr o gannoedd i filoedd. Mae angen eu rheoli a'u cyfnewid, eu hategu'n awtomatig â'r seilwaith TG ac adfer y system ddosbarthedig.
Roeddem yn wynebu heriau mor ddiddorol. Fe wnaethon ni ddylunio'r system, ac ar y foment honno fe wnaethon ni geisio dod o hyd i arferion gorau byd-eang i wirio pa mor dueddol ydyn ni, faint rydyn ni'n dilyn technolegau uwch.
Profiad byd
Yn syndod, ni ddaethom o hyd i un cyfeiriad mewn telathrebu byd-eang.
Ewrop wedi gostwng i ffwrdd o ran nifer y tanysgrifwyr a graddfa, UDA - o ran gwastadrwydd ei tariffau. Edrychon ni ar rai yn Tsieina, a dod o hyd i rai yn India a llogi arbenigwyr o Vodafone India.
I ddadansoddi'r bensaernïaeth, fe wnaethom ymgynnull Tîm Dream dan arweiniad IBM - penseiri o wahanol feysydd. Gallai'r bobl hyn asesu'n ddigonol yr hyn yr oeddem yn ei wneud a dod â gwybodaeth benodol i'n pensaernïaeth.
Chwyddo
Ychydig o rifau er enghraifft.
Rydym yn dylunio'r system ar gyfer 80 miliwn o danysgrifwyr gyda chronfa o un biliwn. Dyma sut rydym yn cael gwared ar drothwyon y dyfodol. Nid yw hyn oherwydd ein bod yn mynd i gymryd drosodd Tsieina, ond oherwydd ymosodiad IoT ac M2M.
300 miliwn o ddogfennau wedi'u prosesu mewn amser real. Er bod gennym 80 miliwn o danysgrifwyr, rydym yn gweithio gyda chleientiaid posibl a'r rhai sydd wedi ein gadael os bydd angen i ni gasglu symiau derbyniadwy. Felly, mae'r cyfeintiau gwirioneddol yn amlwg yn fwy.
2 biliwn o drafodion Mae'r balans yn newid yn ddyddiol - taliadau, taliadau, galwadau a digwyddiadau eraill yw'r rhain. Mae 200 TB o ddata yn newid yn weithredol, newid ychydig yn arafach 8 PB o ddata, ac nid archif yw hwn, ond data byw mewn un bilio. Graddfa yn ôl canolfan ddata - 5 mil o weinyddion ar 14 safle.
pentwr technoleg
Pan wnaethom gynllunio'r bensaernïaeth a dechrau cydosod y system, fe wnaethom fewnforio'r technolegau mwyaf diddorol ac uwch. Y canlyniad yw pentwr technoleg sy'n gyfarwydd i unrhyw chwaraewr Rhyngrwyd a chorfforaethau sy'n gwneud systemau llwyth uchel.
Mae'r pentwr yn debyg i bentyrrau chwaraewyr mawr eraill: Netflix, Twitter, Viber. Mae'n cynnwys 6 cydran, ond rydym am ei fyrhau a'i uno.
Mae hyblygrwydd yn dda, ond mewn corfforaeth fawr nid oes unrhyw ffordd heb uno.
Nid ydym yn mynd i newid yr un Oracle i Tarantool. Yn realiti cwmnïau mawr, mae hwn yn iwtopia, neu'n groesgad am 5-10 mlynedd gyda chanlyniad aneglur. Ond mae'n hawdd disodli Cassandra a Couchbase gyda Tarantool, a dyna beth rydyn ni'n ymdrechu amdano.
Pam Tarantool?
Mae 4 maen prawf syml pam y gwnaethom ddewis y gronfa ddata hon.
Cyflymder. Fe wnaethom gynnal profion llwyth ar systemau diwydiannol MegaFon. Enillodd Tarantool - dangosodd y perfformiad gorau.
Nid yw hyn yn golygu nad yw systemau eraill yn diwallu anghenion MegaFon. Mae datrysiadau cof cyfredol mor gynhyrchiol fel bod cronfeydd wrth gefn y cwmni yn fwy na digon. Ond mae gennym ddiddordeb mewn delio ag arweinydd, ac nid gyda rhywun sydd ar ei hôl hi, gan gynnwys yn y prawf llwyth.
Mae Tarantool yn cwmpasu anghenion y cwmni hyd yn oed yn y tymor hir.
Cost TCO. Mae cefnogaeth i Couchbase ar gyfeintiau MegaFon yn costio symiau seryddol o arian, ond gyda Tarantool mae'r sefyllfa'n llawer mwy dymunol, ac maent yn debyg o ran ymarferoldeb.
Nodwedd braf arall a ddylanwadodd ychydig ar ein dewis yw bod Tarantool yn gweithio'n well gyda'r cof na chronfeydd data eraill. Mae'n dangos effeithlonrwydd mwyaf.
Dibynadwyedd. Mae MegaFon yn buddsoddi mewn dibynadwyedd, yn ôl pob tebyg yn fwy nag unrhyw un arall. Felly pan edrychon ni ar Tarantool, fe wnaethon ni sylweddoli bod yn rhaid i ni wneud iddo fodloni ein gofynion.
Buddsoddwyd ein hamser a'n cyllid, ac ynghyd â Mail.ru fe wnaethom greu fersiwn menter, sydd bellach yn cael ei ddefnyddio mewn sawl cwmni arall.
Tarantool-menter ein bodloni'n llwyr o ran diogelwch, dibynadwyedd, a logio.
Partneriaeth
Y peth pwysicaf i mi yw cyswllt uniongyrchol â'r datblygwr. Dyma'n union beth y bu'r bechgyn o Tarantool yn ei lwgrwobrwyo ag ef.
Os byddwch chi'n dod at chwaraewr, yn enwedig un sy'n gweithio gyda chleient angori, ac yn dweud bod angen y gronfa ddata arnoch i allu gwneud hyn, hwn a hwn, mae fel arfer yn ateb:
- Iawn, rhowch y gofynion ar waelod y pentwr hwnnw - ryw ddydd, mae'n debyg y byddwn yn cyrraedd atynt.
Mae gan lawer fap ffordd ar gyfer y 2-3 blynedd nesaf, ac mae bron yn amhosibl integreiddio yno, ond mae datblygwyr Tarantool yn swyno â'u natur agored, ac nid yn unig o MegaFon, ac yn addasu eu system i'r cwsmer. Mae'n cŵl ac rydyn ni'n ei hoffi'n fawr.
Lle wnaethon ni ddefnyddio Tarantool
Rydym yn defnyddio Tarantool mewn sawl elfen. Mae'r un cyntaf yn y peilot, a wnaethom ar y system cyfeiriadur cyfeiriadau. Ar un adeg roeddwn i eisiau iddi fod yn system a oedd yn debyg i Yandex.Maps a Google Maps, ond fe drodd allan ychydig yn wahanol.
Er enghraifft, y catalog cyfeiriad yn y rhyngwyneb gwerthu. Ar Oracle, mae chwilio am y cyfeiriad a ddymunir yn cymryd 12-13 eiliad. - niferoedd anghyfforddus. Pan fyddwn yn newid i Tarantool, disodli Oracle â chronfa ddata arall yn y consol, a pherfformio'r un chwiliad, rydym yn cael cyflymiad 200x! Mae'r ddinas yn ymddangos ar ôl y trydydd llythyr. Nawr rydym yn addasu'r rhyngwyneb fel bod hyn yn digwydd ar ôl yr un cyntaf. Fodd bynnag, mae'r cyflymder ymateb yn hollol wahanol - milieiliadau yn lle eiliadau.
Mae'r ail gymhwysiad yn thema ffasiynol o'r enw TG dau gyflymder. Mae hyn oherwydd bod ymgynghorwyr o bob cornel yn dweud y dylai corfforaethau fynd yno.
Mae yna haen seilwaith, uwch ei ben mae parthau, er enghraifft, system filio fel telathrebu, systemau corfforaethol, adrodd corfforaethol. Dyma'r craidd nad oes angen ei gyffwrdd. Mae hynny, wrth gwrs, yn bosibl, ond yn baranoiaidd yn sicrhau ansawdd, oherwydd mae'n dod ag arian i'r gorfforaeth.
Nesaf daw'r haen o ficrowasanaethau - yr hyn sy'n gwahaniaethu'r gweithredwr neu'r chwaraewr arall. Gellir creu microwasanaethau yn gyflym yn seiliedig ar rai caches, gan ddod â data o wahanol barthau yno. Yma maes ar gyfer arbrofion - os na weithiodd rhywbeth allan, caeais un microwasanaeth ac agor un arall. Mae hyn yn rhoi mwy o amser i'r farchnad ac yn cynyddu dibynadwyedd a chyflymder y cwmni.
Efallai mai microservices yw prif rôl Tarantool yn MegaFon.
Ble rydyn ni'n bwriadu defnyddio Tarantool
Os byddwn yn cymharu ein prosiect bilio llwyddiannus â'r rhaglenni trawsnewid yn Deutsche Telekom, Svyazcom, Vodafone India, mae'n rhyfeddol o ddeinamig a chreadigol. Yn y broses o weithredu'r prosiect hwn, nid yn unig y trawsnewidiwyd MegaFon a'i strwythur, ond hefyd ymddangosodd Tarantool-enterprise yn Mail.ru, a'n gwerthwr Nexign (Peter-Service gynt) - BSS Box (ateb bilio mewn bocs).
Mae hwn, ar un ystyr, yn brosiect hanesyddol ar gyfer marchnad Rwsia. Gellir ei gymharu â’r hyn a ddisgrifir yn y llyfr “The Mythical Man-Month” gan Frederick Brooks. Yna, yn y 60au, llogodd IBM 360 o bobl i ddatblygu'r system weithredu OS/5 newydd ar gyfer prif fframiau. Mae gennym lai - 000, ond mae ein un ni mewn festiau, a chan ystyried y defnydd o ddulliau ffynhonnell agored a newydd, rydym yn gweithio'n fwy cynhyrchiol.
Isod mae parthau bilio neu, yn fwy cyffredinol, systemau busnes. Mae pobl o fenter yn adnabod CRM yn dda iawn. Dylai fod gan bawb systemau eraill eisoes: API Agored, Porth API.
Agor API
Gadewch i ni edrych ar y niferoedd eto a sut mae'r API Agored yn gweithio ar hyn o bryd. Ei llwyth yw 10 o drafodion yr eiliad. Gan ein bod yn bwriadu datblygu'r haen microwasanaethau yn weithredol ac adeiladu API cyhoeddus MegaFon, rydym yn disgwyl mwy o dwf yn y dyfodol yn y rhan hon. Yn bendant bydd 100 o drafodion.
Nid wyf yn gwybod a allwn gymharu â Mail.ru yn SSO - mae'n ymddangos bod gan y dynion 1 o drafodion yr eiliad. Mae eu datrysiad yn hynod ddiddorol i ni ac rydym yn bwriadu mabwysiadu eu profiad - er enghraifft, gwneud copi wrth gefn SSO swyddogaethol gan ddefnyddio Tarantool. Nawr mae datblygwyr Mail.ru yn gwneud hyn i ni.
CRM
CRM yw'r un 80 miliwn o danysgrifwyr ag yr ydym am eu cynyddu i biliwn, oherwydd mae eisoes 300 miliwn o ddogfennau sy'n cynnwys hanes tair blynedd. Rydym yn edrych ymlaen yn fawr at wasanaethau newydd ac yma pwynt twf yw gwasanaethau cysylltiedig. Mae hon yn bêl a fydd yn tyfu, oherwydd bydd mwy a mwy o wasanaethau. Yn unol â hynny, bydd angen stori arnom; nid ydym am faglu ar hyn.
Bilio ei hun o ran cyhoeddi anfonebau, gweithio gyda chyfrifon cwsmeriaid derbyniadwy trawsnewid yn barth ar wahân. Er mwyn gwella perfformiad, patrwm pensaernïol pensaernïaeth parth cymhwysol.
Rhennir y system yn barthau, dosberthir y llwyth a sicrheir goddefgarwch bai. Yn ogystal, buom yn gweithio gyda phensaernïaeth ddosbarthedig.
Mae popeth arall yn atebion lefel menter. Yn y storfa alwadau - 2 biliwn y dydd, 60 biliwn y mis. Weithiau mae'n rhaid i chi eu cyfrif mewn mis, ac mae'n well yn gyflym. Monitro ariannol - mae hyn yn union yr un 300 miliwn sy'n tyfu ac yn tyfu'n gyson: mae tanysgrifwyr yn aml yn rhedeg rhwng gweithredwyr, gan gynyddu'r rhan hon.
Yr elfen fwyaf telathrebu o gyfathrebu symudol yw bilio ar-lein. Dyma'r systemau sy'n eich galluogi i ffonio neu beidio â galw, gwneud penderfyniadau mewn amser real. Yma, y llwyth yw 30 o drafodion yr eiliad, ond gan gymryd i ystyriaeth y twf mewn trosglwyddo data, rydym yn cynllunio 250 o drafodion, ac felly mae gennym ddiddordeb mawr yn Tarantool.
Y llun blaenorol yw'r parthau lle rydyn ni'n mynd i ddefnyddio Tarantool. Mae CRM ei hun, wrth gwrs, yn ehangach ac rydym yn mynd i'w ddefnyddio yn y craidd ei hun.
Mae ein ffigwr TTX amcangyfrifedig o 100 miliwn o danysgrifwyr yn fy nrysu fel pensaer - beth os 101 miliwn? Oes rhaid i chi ail-wneud popeth eto? Er mwyn atal hyn rhag digwydd, rydym yn defnyddio caches, ar yr un pryd yn cynyddu hygyrchedd.
Yn gyffredinol, mae dau ddull o ddefnyddio Tarantool. Yn gyntaf - adeiladu pob storfa ar y lefel microwasanaeth. Cyn belled ag y deallaf, mae VimpelCom yn dilyn y llwybr hwn, gan greu storfa o gleientiaid.
Rydym yn llai dibynnol ar werthwyr, rydym yn newid y craidd BSS, felly mae gennym un ffeil cleient allan o'r blwch. Ond rydym am ei ehangu. Felly, rydym yn cymryd agwedd ychydig yn wahanol - gwneud caches y tu mewn i systemau.
Fel hyn mae llai o gydamseru - mae un system yn gyfrifol am y storfa a'r brif ffynhonnell.
Mae'r dull yn cyd-fynd yn dda â dull Tarantool gyda sgerbwd trafodion, pan mai dim ond rhannau sy'n ymwneud â diweddariadau, hynny yw, newidiadau data, sy'n cael eu diweddaru. Gellir storio popeth arall yn rhywle arall. Nid oes llyn data enfawr, storfa fyd-eang heb ei reoli. Mae caches wedi'u cynllunio ar gyfer y system, neu ar gyfer cynhyrchion, neu ar gyfer cleientiaid, neu i wneud bywyd yn haws ar gyfer cynnal a chadw. Pan fydd tanysgrifiwr yn galw ac yn ofidus am ansawdd eich gwasanaeth, rydych chi am ddarparu gwasanaeth o safon.
RTO a RPO
Mae dau derm mewn TG - OTR и RPO.
Amcan amser adfer yw'r amser y mae'n ei gymryd i adfer y gwasanaeth ar ôl methiant. Mae RTO = 0 yn golygu hyd yn oed os bydd rhywbeth yn methu, mae'r gwasanaeth yn parhau i weithio.
Amcan pwynt adfer - dyma'r amser adfer data, faint o ddata y gallwn ei golli dros gyfnod penodol o amser. Mae RPO = 0 yn golygu nad ydym yn colli data.
Tasg Tarantool
Gadewch i ni geisio datrys problem ar gyfer Tarantool.
Wedi rhoi: basged o gymwysiadau y mae pawb yn eu deall, er enghraifft, yn Amazon neu yn rhywle arall. Angenrheidiol fel bod y drol siopa yn gweithio 24 awr 7 diwrnod yr wythnos, neu 99,99% o'r amser. Rhaid i'r gorchmynion a ddaw atom aros mewn trefn, oherwydd ni allwn droi ymlaen na diffodd cysylltiad y tanysgrifiwr ar hap - rhaid i bopeth fod yn hollol gyson. Mae'r tanysgrifiad blaenorol yn effeithio ar yr un nesaf, felly mae'r data yn bwysig - ni ddylai unrhyw beth fynd ar goll.
penderfyniad. Gallwch geisio ei ddatrys yn uniongyrchol a gofyn i ddatblygwyr y gronfa ddata, ond ni ellir datrys y broblem yn fathemategol. Gallwch gofio theoremau, cyfreithiau cadwraeth, ffiseg cwantwm, ond pam - ni ellir ei datrys ar y lefel DB.
Mae'r hen ddull pensaernïol da yn gweithio yma - mae angen i chi wybod y maes pwnc yn dda a'i ddefnyddio i ddatrys y pos hwn.
Ein datrysiad: creu cofrestrfa ddosbarthedig o geisiadau ar Tarantool - clwstwr geo-ddosbarthu. Yn y diagram, mae'r rhain yn dair canolfan brosesu data wahanol - dwy cyn yr Urals, un y tu hwnt i'r Urals, ac rydym yn dosbarthu pob cais ymhlith y canolfannau hyn.
Dim ond un ganolfan ddata oedd gan Netflix, sydd bellach yn cael ei ystyried yn un o arweinwyr TG, tan 2012. Ar drothwy Nadolig Catholig, Rhagfyr 24, aeth y ganolfan ddata hon i lawr. Gadawyd defnyddwyr yng Nghanada ac UDA heb eu hoff ffilmiau, roeddent yn ofidus iawn ac yn ysgrifennu amdano ar rwydweithiau cymdeithasol. Bellach mae gan Netflix dair canolfan ddata ar arfordir gorllewin-ddwyreiniol ac un yng ngorllewin Ewrop.
I ddechrau rydym yn adeiladu datrysiad geo-ddosbarthedig - mae goddef diffygion yn bwysig i ni.
Felly mae gennym ni glwstwr, ond beth am RPO = 0 a RTO = 0? Mae'r ateb yn syml, yn dibynnu ar y pwnc.
Beth sy'n bwysig mewn ceisiadau? Dwy Ran: Taflu Basged TO gwneud penderfyniad prynu, a AR ÔL. Gelwir y rhan DO mewn telathrebu fel arfer gorchymyn cipio neu trafod archeb. Mewn telathrebu, gall hyn fod yn llawer anoddach nag mewn siop ar-lein, oherwydd yno mae'n rhaid i'r cleient gael ei weini, cynnig 5 opsiwn, ac mae hyn i gyd yn digwydd ers peth amser, ond mae'r fasged wedi'i llenwi. Ar hyn o bryd, mae methiant yn bosibl, ond nid yw'n frawychus, oherwydd mae'n digwydd yn rhyngweithiol o dan oruchwyliaeth ddynol.
Os bydd canolfan ddata Moscow yn methu'n sydyn, yna trwy newid yn awtomatig i ganolfan ddata arall, byddwn yn parhau i weithio. Yn ddamcaniaethol, efallai y bydd un cynnyrch yn cael ei golli yn y drol, ond rydych chi'n ei weld, yn ychwanegu at y drol eto ac yn parhau i weithio. Yn yr achos hwn RTO = 0.
Ar yr un pryd, mae yna ail opsiwn: pan wnaethom glicio ar “cyflwyno”, rydym am i'r data beidio â chael ei golli. O'r eiliad hon ymlaen, mae awtomeiddio yn dechrau gweithio - dyma RPO = 0. Gan ddefnyddio'r ddau batrwm gwahanol hyn, mewn un achos gallai fod yn glwstwr geo-ddosbarthedig gydag un meistr y gellir ei newid, mewn achos arall rhyw fath o gofnod cworwm. Gall patrymau amrywio, ond rydym yn datrys y broblem.
Ymhellach, gyda chofrestrfa ddosbarthu o geisiadau, gallwn hefyd raddfa'r cyfan - mae gennym lawer o anfonwyr a ysgutorion sy'n cyrchu'r gofrestrfa hon.
Cassandra a Tarantool gyda'i gilydd
Mae achos arall - "arddangosfa balansau". Dyma achos diddorol o'r defnydd ar y cyd o Cassandra a Tarantool.
Rydym yn defnyddio Cassandra oherwydd nid 2 biliwn o alwadau y dydd yw'r terfyn, a bydd mwy. Mae marchnatwyr wrth eu bodd yn lliwio traffig yn ôl ffynhonnell; mae mwy a mwy o fanylion yn ymddangos ar rwydweithiau cymdeithasol, er enghraifft. Mae'r cyfan yn ychwanegu at y stori.
Mae Cassandra yn caniatáu ichi raddio'n llorweddol i unrhyw faint.
Teimlwn yn gyfforddus gyda Cassandra, ond mae ganddo un broblem - nid yw'n dda am ddarllen. Mae popeth yn iawn ar y recordiad, nid yw 30 yr eiliad yn broblem - problem darllen.
Felly, ymddangosodd pwnc gyda storfa, ac ar yr un pryd fe wnaethom ddatrys y broblem ganlynol: mae hen achos traddodiadol pan fydd offer o switsh o filio ar-lein yn dod i mewn i'r ffeiliau rydyn ni'n eu llwytho i mewn i Cassandra. Cawsom drafferth gyda'r broblem o lawrlwytho'r ffeiliau hyn yn ddibynadwy, hyd yn oed gan ddefnyddio cyngor trosglwyddo ffeiliau rheolwr IBM - mae yna atebion sy'n rheoli trosglwyddo ffeiliau yn effeithlon, gan ddefnyddio'r protocol CDU, er enghraifft, yn hytrach na TCP. Mae hyn yn dda, ond mae'n dal i fod munudau, ac nid ydym wedi llwytho'r cyfan eto, ni all y gweithredwr yn y ganolfan alwadau ateb y cleient beth ddigwyddodd i'w gydbwysedd - mae'n rhaid i ni aros.
Er mwyn atal hyn rhag digwydd, rydym ni rydym yn defnyddio cronfa swyddogaethol gyfochrog. Pan fyddwn yn anfon digwyddiad trwy Kafka i Tarantool, yn ailgyfrifo agregau mewn amser real, er enghraifft, ar gyfer heddiw, rydym yn cael balansau arian parod, sy'n gallu trosglwyddo balansau ar unrhyw gyflymder, er enghraifft, 100 mil o drafodion yr eiliad a'r rhai yr un 2 eiliad.
Y nod yw, ar ôl gwneud galwad, o fewn 2 eiliad yn eich cyfrif personol bydd nid yn unig y balans wedi'i newid, ond gwybodaeth am pam y newidiodd.
Casgliad
Roedd y rhain yn enghreifftiau o ddefnyddio Tarantool. Roeddem yn wirioneddol hoffi natur agored Mail.ru a'u parodrwydd i ystyried gwahanol achosion.
Mae eisoes yn anodd i ymgynghorwyr o BCG neu McKinsey, Accenture neu IBM ein synnu gyda rhywbeth newydd - llawer o'r hyn y maent yn ei gynnig, rydym naill ai eisoes yn ei wneud, wedi'i wneud, neu'n bwriadu ei wneud. Credaf y bydd Tarantool yn cymryd ei le haeddiannol yn ein pentwr technoleg a bydd yn disodli llawer o dechnolegau presennol. Rydym yng nghyfnod gweithredol datblygiad y prosiect hwn.
Mae'r adroddiad gan Oleg ac Andrey yn un o'r goreuon yng Nghynhadledd Tarantool y llynedd, ac ar Fehefin 17 bydd Oleg Ivlev yn siarad yn gydag adroddiad . Bydd Alexander Deulin hefyd yn rhoi cyflwyniad gan MegaFon . Gadewch i ni ddarganfod beth sydd wedi newid, pa gynlluniau sydd wedi'u rhoi ar waith. Ymunwch - mae'r gynhadledd am ddim, y cyfan sy'n rhaid i chi ei wneud yw . Pawb ac mae rhaglen y gynhadledd wedi'i ffurfio: achosion newydd, profiad newydd o ddefnyddio Tarantool, pensaernïaeth, menter, tiwtorialau a microwasanaethau.
Ffynhonnell: hab.com