Tá stair chruthú VKontakte ar Vicipéid; dúirt Pavel féin é. Dealraíonn sé go bhfuil aithne ag gach duine uirthi cheana féin. Maidir le gnéithe inmheánacha, ailtireacht agus struchtúr an tsuímh ar HighLoad++ Pavel . Tá go leor freastalaithe tar éis sceitheadh ó shin i leith, mar sin déanfaimid an t-eolas a nuashonrú: déanfaimid an fhaisnéis a dhíroinnt, bainfimid amach an taobh istigh, meáigh é, agus féachfaimid ar an bhfeiste VK ó thaobh teicniúil de.
Alexey Akulovich () forbróir inneall san fhoireann VKontakte. Is freagra comhchoiteann é tras-scríbhinn na tuarascála seo ar cheisteanna coitianta faoi oibriú an ardáin, an bhonneagair, na bhfreastalaithe agus an idirghníomhaíocht eatarthu, ach ní faoi fhorbairt, eadhon faoi iarann. Ar leithligh, faoi bhunachair shonraí agus cad atá ag VK ina ionad sin, faoi logs a bhailiú agus monatóireacht a dhéanamh ar an tionscadal iomlán ina iomláine. Sonraí faoin gearrtha.
Le breis is ceithre bliana tá mé ag déileáil le gach cineál tascanna a bhaineann leis an backend.
- Meáin a uaslódáil, a stóráil, a phróiseáil, a dháileadh: físeáin, sruthú beo, fuaime, grianghraif, doiciméid.
- Bonneagar, ardán, monatóireacht ar fhorbróirí, logaí, caches réigiúnacha, CDN, prótacal RPC dílseánaigh.
- Comhtháthú le seirbhísí seachtracha: fógraí brú, parsáil naisc sheachtracha, fotha RSS.
- Cabhrú le comhghleacaithe le ceisteanna éagsúla, na freagraí a éilíonn tumadóireacht isteach cód anaithnid.
Le linn an ama seo, bhí lámh agam i go leor comhpháirteanna den láithreán. Ba mhaith liom an taithí seo a roinnt.
Ailtireacht ghinearálta
Tosaíonn gach rud, mar is gnách, le freastalaí nó le grúpa freastalaithe a ghlacann le hiarratais.
Freastalaí tosaigh
Glacann an freastalaí tosaigh le hiarratais trí HTTPS, RTMP agus WSS.
HTTPS - is iarratais iad seo ar na príomhleaganacha gréasáin agus soghluaiste den láithreán: vk.com agus m.vk.com, agus cliaint oifigiúla agus neamhoifigiúla eile dár API: cliaint soghluaiste, teachtairí. Tá fáiltiú againn RTMP-traffic do chraoltaí Beo le freastalaithe tosaigh ar leith agus WSS- naisc le haghaidh Streaming API.
I gcás HTTPS agus WSS ar fhreastalaithe is fiú é nginx. Maidir le craoltaí RTMP, d'athraigh muid le déanaí chuig ár réiteach féin kive, ach tá sé lasmuigh de raon feidhme na tuarascála. Maidir le lamháltas lochtanna, fógraíonn na freastalaithe seo seoltaí IP coitianta agus gníomhaíonn siad i ngrúpaí ionas nach gcailltear iarratais úsáideora má bhíonn fadhb ar cheann de na freastalaithe. I gcás HTTPS agus WSS, criptíonn na freastalaithe céanna seo trácht chun cuid den ualach LAP a ghlacadh orthu féin.
Ní labhróimid a thuilleadh faoi WSS agus RTMP, ach amháin faoi iarratais chaighdeánacha HTTPS, a bhaineann de ghnáth le tionscadal gréasáin.
Inneall
Taobh thiar den tosach is gnách go mbíonn freastalaithe inneall ann. Próiseálann siad iarratais a fhaigheann an freastalaí tosaigh ó chliaint.
Tá sé freastalaithe kPHP, ar a bhfuil an deamhan HTTP ag rith, toisc go bhfuil HTTPS díchriptithe cheana féin. Is freastalaí é kPHP a ritheann ar samhlacha prefork: cuireann sé tús le máistirphróiseas, déanann cuid mhór próiseas leanaí, cuireann sé soicéid éisteachta ar aghaidh chucu agus próiseálann siad a n-iarratais. Sa chás seo, ní atosaítear próisis idir gach iarratas ón úsáideoir, ach go simplí athshocraigh siad a stát go dtí an stát luach nialasach - iarratas tar éis iarratas, in ionad atosú.
Dáileadh ualaigh
Ní líon mór meaisíní iad ár n-aisíní go léir ar féidir leo aon iarratas a phróiseáil. Táimid leo roinnte i ngrúpaí ar leith: ginearálta, soghluaiste, api, físeáin, stáitse... Ní bheidh aon tionchar ag an bhfadhb ar ghrúpa ar leith de mheaisíní ar gach ceann eile. I gcás fadhbanna le físeáin, ní bheidh an t-úsáideoir a éisteann le ceol ar an eolas faoi na fadhbanna fiú. Is é nginx a chinnfidh an t-inneall chun an t-iarratas a sheoladh chuige de réir an chumraíochta.
Bailiúchán méadrach agus athchothromú
Chun tuiscint a fháil ar cé mhéad gluaisteán a theastaíonn uainn i ngach grúpa, ní mór dúinn ná bí ag brath ar QPS. Tá na haiséil éagsúla, tá iarratais éagsúla acu, tá castacht dhifriúil ag gach iarratas maidir le QPS a ríomh. Sin an fáth linn oibrímid leis an gcoincheap ualach ar an bhfreastalaí ina iomláine - ar an LAP agus perf.
Tá na mílte freastalaithe den sórt sin againn. Ritheann gach freastalaí fisiciúil grúpa kPHP chun na croíleacáin go léir a athchúrsáil (toisc go bhfuil kPHP snáithithe singil).
Freastalaí Ábhar
Is stóras é CS nó Content Server. Is freastalaí é CS a stórálann comhaid agus a phróiseálann comhaid uaslódáilte agus gach cineál tascanna sioncrónacha cúlra a shanntar dó ag an bpríomhéadan Gréasáin.
Tá na mílte freastalaithe fisiceacha againn a stórálann comhaid. Is breá le húsáideoirí comhaid a uaslódáil, agus is breá linn iad a stóráil agus a roinnt. Tá cuid de na freastalaithe seo dúnta ag freastalaithe speisialta pu/pp.
pu/pp
Má d'oscail tú an cluaisín líonra i VK, chonaic tú pu/pp.
Cad is pu/pp ann? Má dhúnaimid freastalaí amháin i ndiaidh a chéile, tá dhá rogha ann chun comhad a uaslódáil agus a íoslódáil chuig an bhfreastalaí a dúnadh: go díreach trí http://cs100500.userapi.com/path nó Trí fhreastalaí idirmheánach - http://pu.vk.com/c100500/path.
Is é Pu an t-ainm stairiúil ar uaslódáil grianghraf, agus is seachfhreastalaí grianghraf é pp. Is é sin, tá freastalaí amháin le haghaidh grianghraif a uaslódáil, agus freastalaí eile le huaslódáil. Anois, ní hamháin go bhfuil grianghraif luchtaithe, ach tá an t-ainm caomhnaithe.
Na freastalaithe seo deireadh a chur le seisiúin HTTPSchun ualach an phróiseálaí a bhaint as an stóráil. Chomh maith leis sin, ós rud é go bpróiseáiltear comhaid úsáideora ar na freastalaithe seo, dá laghad faisnéis íogair a stóráiltear ar na meaisíní seo, is amhlaidh is fearr. Mar shampla, eochracha criptithe HTTPS.
Ós rud é go bhfuil na meaisíní dúnta ag ár n-innill eile, tá sé d'acmhainn againn gan IPanna seachtracha “bán” a thabhairt dóibh, agus tabhair "liath". Ar an mbealach seo shábháil muid ar an linn IP agus ráthaithe a chosaint ar na meaisíní ó rochtain lasmuigh - go simplí níl aon IP chun dul isteach ann.
Athléimneacht thar IPanna comhroinnte. Maidir le lamháltas locht, oibríonn an scéim mar an gcéanna - tá IP fisiceach coitianta ag roinnt freastalaithe fisiceacha, agus roghnaíonn na crua-earraí os a gcomhair an áit ar cheart an t-iarratas a sheoladh. Labhróidh mé faoi roghanna eile níos déanaí.
Is é an pointe conspóideach sin sa chás seo coinníonn an cliant naisc níos lú. Má tá an IP céanna le haghaidh roinnt meaisíní - leis an ósta céanna: pu.vk.com nó pp.vk.com, tá teorainn ag an mbrabhsálaí cliant ar líon na n-iarratas comhuaineach chuig óstach amháin. Ach le linn HTTP/2 uileláithreach, creidim nach bhfuil sé seo chomh hábhartha a thuilleadh.
Is é an míbhuntáiste soiléir a bhaineann leis an scéim ná go gcaithfidh sí gach trácht a phumpáil, a théann chuig an stóráil, trí fhreastalaí eile. Ós rud é go ndéanaimid an trácht a phumpáil trí mheaisíní, ní féidir linn trácht trom a chaidéil fós, mar shampla, físeáin, ag baint úsáide as an scéim chéanna. Déanaimid é a tharchur go díreach - nasc díreach ar leith le haghaidh stórála ar leithligh go sonrach le haghaidh físeáin. Tarchuirimid ábhar níos éadroime trí sheachvótálaí.
Ní fada ó shin fuaireamar leagan feabhsaithe de sheachvótálaí. Anois inseoidh mé duit cad iad na difríochtaí atá idir iad agus na gnáthdhaoine agus cén fáth go bhfuil sé seo riachtanach.
Sun
I mí Mheán Fómhair 2017, Oracle, a cheannaigh Sun roimhe seo, . Is féidir linn a rá gur scoir an chuideachta de bheith ann faoi láthair. Agus ainm á roghnú don chóras nua, chinn ár riarthóirí ómós a thabhairt do chuimhne na cuideachta seo agus d'ainmnigh siad an córas nua Sun. Idir sinn féin tugaimid “gréine” uirthi.
Bhí cúpla fadhb ag pp. IP amháin in aghaidh an ghrúpa - taisce neamhéifeachtach. Tá seoladh IP coitianta ag go leor freastalaithe fisiceacha, agus níl aon bhealach ann le rialú a dhéanamh ar an bhfreastalaí a rachaidh an t-iarratas chuige. Mar sin, má thagann úsáideoirí éagsúla don chomhad céanna, ansin má tá taisce ar na freastalaithe seo, críochnaíonn an comhad i dtaisce gach freastalaí. Is scéim an-mhí-éifeachtach í seo, ach ní fhéadfaí aon rud a dhéanamh.
Dá bharr sin - ní féidir linn ábhar a ghearradh, toisc nach féidir linn freastalaí ar leith a roghnú don ghrúpa seo - tá IP coiteann acu. Chomh maith leis sin ar roinnt cúiseanna inmheánacha atá againn níorbh fhéidir freastalaithe den sórt sin a shuiteáil i réigiúin. Sheas siad ach i St Petersburg.
Leis an ghrian, d'athraigh muid an córas roghnúcháin. Anois ní mór dúinn ródú anycast: ródú dinimiciúil, anycast, deamhan féin-seiceáil. Tá a IP aonair féin ag gach freastalaí, ach folíon coiteann. Tá gach rud cumraithe sa chaoi is go scaiptear an trácht ar fhreastalaithe eile an ghrúpa chéanna go huathoibríoch má theipeann ar fhreastalaí amháin. Anois is féidir freastalaí ar leith a roghnú, gan taisceadh iomarcach, agus níor cuireadh isteach ar iontaofacht.
Tacaíocht meáchain. Anois is féidir linn meaisíní de chumhacht éagsúil a shuiteáil de réir mar is gá, agus freisin, i gcás fadhbanna sealadacha, meáchain na “gréine” oibre a athrú chun an t-ualach orthu a laghdú, ionas go mbeidh siad “a shuí” agus ag tosú ag obair arís.
Roinnt de réir aitheantais ábhair. Rud greannmhar faoi sharding: de ghnáth déanaimid ábhar a bhearradh ionas go dtéann úsáideoirí éagsúla chuig an gcomhad céanna tríd an “ghrian” céanna ionas go mbeidh taisce coitianta acu.
Sheolamar an feidhmchlár “Seamair” le déanaí. Is tráth na gceist ar líne é seo i gcraoladh beo, áit a gcuireann an t-óstach ceisteanna agus freagraíonn úsáideoirí i bhfíor-am, ag roghnú roghanna. Tá comhrá ag an aip inar féidir le húsáideoirí comhrá a dhéanamh. Is féidir ceangal leis an gcraoladh ag an am céanna níos mó ná 100 míle duine. Scríobhann siad go léir teachtaireachtaí a sheoltar chuig na rannpháirtithe go léir, agus tagann avatar mar aon leis an teachtaireacht. Má thagann 100 míle duine le haghaidh abhatár amháin in aon “ghrian”, is féidir é a rolladh taobh thiar de scamall uaireanta.
Chun pléascanna iarratas ar an gcomhad céanna a sheasamh, is do chineál áirithe ábhair a chuirfimid scéim dúr ar siúl a scaipeann comhaid ar fud na “gréine” atá ar fáil sa réigiún.
An ghrian ón taobh istigh
seachfhreastalaí droim ar ais ar nginx, taisce i RAM nó ar dhioscaí tapa Optane/NVMe. Sampla: http://sun4-2.userapi.com/c100500/path — nasc chuig an “ghrian”, atá suite sa cheathrú réigiún, an dara grúpa freastalaí. Dúnann sé an comhad cosáin, atá suite go fisiciúil ar fhreastalaí 100500.
Taisce
Cuirimid nód amháin eile lenár scéim ailtireachta - an timpeallacht taisce.
Anseo thíos tá an léaráid leagan amach caches réigiúnacha, tá thart ar 20 acu. Is iad seo na háiteanna ina bhfuil caches agus “suns” suite, ar féidir leo trácht a thaisceadh trí iad féin.
Is taisceadh é seo d’ábhar ilmheán; ní stóráiltear aon sonraí úsáideora anseo - díreach ceol, físeáin, grianghraif.
Chun a chinneadh an úsáideora réigiún, táimid bailímid réimíreanna líonra BGP a fógraíodh sna réigiúin. I gcás cúltaca, ní mór dúinn an bunachar sonraí geoip a pharsáil freisin mura bhféadfaimis an IP a aimsiú trí réimíreanna. Socraímid an réigiún de réir IP an úsáideora. Sa chód, is féidir linn breathnú ar réigiún amháin nó níos mó den úsáideoir - na pointí sin a bhfuil sé is gaire dó go geografach.
Conas a oibríonn sé?
Áireamhaimid an tóir a bhí ar chomhaid de réir réigiúin. Tá roinnt de na taisce réigiúnach ina bhfuil an t-úsáideoir suite, agus aitheantóir comhaid - a chur orainn an péire agus incrimint an rátáil le gach íoslódáil.
Ag an am céanna, tagann deamhain - seirbhísí i réigiúin - go dtí an API ó am go chéile agus deir siad: “Is taisce den sórt sin mé, tabhair dom liosta de na comhaid is mó tóir i mo réigiún nach bhfuil fós orm. ” Seachadann an API dornán comhad curtha in eagar de réir rátála, íoslódálann an deamhan iad, tógann sé chuig na réigiúin iad agus seachadann sé na comhaid as sin. Is é seo an difríocht bhunúsach idir pu/pp agus Sun ó caches: tugann siad an comhad astu féin láithreach, fiú mura bhfuil an comhad seo sa taisce, agus íoslódálann an taisce an comhad chuige féin ar dtús, agus ansin tosaíonn sé á thabhairt ar ais.
Sa chás seo a fháil againn ábhar níos gaire d'úsáideoirí agus an t-ualach líonra a scaipeadh. Mar shampla, ó thaisce Moscó amháin a dháilimid níos mó ná 1 Tbit/s le linn buaicuaireanta.
Ach tá fadhbanna - nach rubar iad na freastalaithe taisce. Maidir le hábhar sár-choitianta, uaireanta ní bhíonn go leor líonra ann le haghaidh freastalaí ar leith. Is iad ár bhfreastalaithe taisce ná 40-50 Gbit/s, ach tá ábhar ann a chloiseann cainéal den sórt sin go hiomlán. Táimid ag bogadh i dtreo stóráil níos mó ná cóip amháin de chomhaid mhóréilimh sa réigiún a chur i bhfeidhm. Tá súil agam go gcuirfimid i bhfeidhm é faoi dheireadh na bliana.
D'fhéachamar ar an ailtireacht ghinearálta.
- Freastalaithe tosaigh a ghlacann le hiarratais.
- Backends a phróiseáil iarratais.
- Stórálacha atá dúnta ag dhá chineál proxies.
- Taisce réigiúnacha.
Cad atá ar iarraidh ón léaráid seo? Ar ndóigh, na bunachair sonraí ina bhfuil muid ag stóráil sonraí.
Bunachair sonraí nó innill
Tugaimid nach bunachair shonraí iad, ach innill - Innill, toisc go praiticiúil nach bhfuil bunachair shonraí againn sa chiall a nglactar leo go ginearálta.
Is beart riachtanach é seo. Tharla sé seo mar i 2008-2009, nuair a bhí fás pléascach sa tóir ar VK, d'oibrigh an tionscadal go hiomlán ar MySQL agus Memcache agus bhí fadhbanna ann. Ba bhreá le MySQL comhaid tuairteála agus truaillithe, agus ní athshlánódh sé ina dhiaidh sin, agus tháinig Memcache díghrádaithe de réir a chéile i bhfeidhmíocht agus b’éigean é a atosú.
Tharlaíonn sé go raibh stóráil leanúnach ag an tionscadal atá ag éirí níos coitianta, rud a éillíonn sonraí, agus taisce, a mhoillíonn. I gcoinníollacha den sórt sin, tá sé deacair tionscadal atá ag fás a fhorbairt. Socraíodh go ndéanfaí iarracht na rudaí ríthábhachtacha a raibh an tionscadal dírithe orthu a athscríobh ar ár rothair féin.
D'éirigh leis an réiteach. Bhí deis ann é seo a dhéanamh, chomh maith le fíorriachtanas, mar ní raibh bealaí eile scálú ann ag an am sin. Ní raibh mórán bunachair shonraí ann, ní raibh NoSQL ann fós, ní raibh ann ach MySQL, Memcache, PostrgreSQL - agus sin é.
Oibriú uilíoch. Bhí an fhorbairt i gceannas ag ár bhfoireann forbróirí C agus rinneadh gach rud ar bhealach comhsheasmhach. Beag beann ar an inneall, bhí thart ar an bhformáid comhaid chéanna acu go léir scríofa ar diosca, na paraiméadair seolta céanna, comharthaí próiseáilte ar an mbealach céanna, agus iad féin a bheag nó a mhór mar an gcéanna i gcás cásanna imeallacha agus fadhbanna. Le fás na n-inneall, tá sé áisiúil do riarthóirí an córas a oibriú - níl aon zú ann a chaithfear a choinneáil, agus caithfidh siad athfhoghlaim conas gach bunachar sonraí tríú páirtí nua a oibriú, rud a d'fhág go bhféadfaí é a mhéadú go tapa agus go áisiúil. a n-uimhir.
Cineálacha inneall
Scríobh an fhoireann go leor inneall. Seo cuid acu: cara, leideanna, íomhá, ipdb, litreacha, liostaí, logaí, memcached, meowdb, nuacht, nostradamus, grianghraf, seinmliostaí, pmemcached, bosca gainimh, cuardach, stóráil, is maith leat, tascanna,…
I gcás gach tasc a éilíonn struchtúr sonraí ar leith nó a phróiseálann iarratais aitíopúla, scríobhann foireann C inneall nua. Cén fáth nach bhfuil.
Tá inneall ar leith againn memcached, atá cosúil le gnáth, ach le bunch de goodies, agus nach mall síos. Ní ClickHouse, ach oibríonn sé freisin. Ar fáil ar leithligh pemcached - An bhfuil memcached leanúnach, ar féidir leo sonraí a stóráil ar dhiosca freisin, ina theannta sin, ná mar a luíonn isteach i RAM, ionas nach gcaillfidh tú sonraí nuair a atosaítear iad. Tá innill éagsúla ann le haghaidh tascanna aonair: scuainí, liostaí, tacair - gach rud a éilíonn ár dtionscadal.
Cnuasaigh
Ó thaobh an chóid de, ní gá smaoineamh ar innill nó bunachair shonraí mar phróisis, mar aonáin nó mar chásanna. Oibríonn an cód go sonrach le braislí, le grúpaí inneall - cineál amháin in aghaidh an bhraisle. Ligean le rá go bhfuil braisle memcached - níl ann ach grúpa meaisíní.
Ní gá go mbeadh a fhios ag an gcód suíomh fisiciúil, méid nó líon na bhfreastalaithe ar chor ar bith. Téann sé go dtí an braisle ag baint úsáide as aitheantóir áirithe.
Le go n-oibreoidh sé seo, ní mór duit aonán amháin eile a chur leis atá suite idir an cód agus na hinnill - seachfhreastalaí.
seachfhreastalaí RPC
Seachfhreastalaí bus ag nascadh, ar a ritheann beagnach an suíomh ar fad. Ag an am céanna ní mór dúinn aon fhionnachtain seirbhíse — ina ionad sin, tá cumraíocht ann don seachfhreastalaí seo, a bhfuil a fhios aige suíomh gach braisle agus gach shard den bhraisle seo. Seo a dhéanann riarthóirí.
Ní bhíonn cúram ar bith ar ríomhchláraitheoirí cé mhéad, cén áit agus cad a chosnaíonn sé - ní théann siad ach chuig an mbraisle. Ligeann sé seo dúinn go leor. Nuair a fhaigheann sé iarratas, déanann an seachfhreastalaí an t-iarratas a atreorú, agus fios aige cá háit - cinneann sé é sin féin.
Sa chás seo, is pointe cosanta é seachfhreastalaí i gcoinne teip seirbhíse. Má mhoillíonn inneall éigin nó má thiteann sé, tuigeann an seachfhreastalaí é seo agus freagraíonn sé dá réir sin do thaobh an chliaint. Ligeann sé seo duit an teorainn ama a bhaint - ní fhanann an cód go bhfreagróidh an t-inneall, ach tuigeann sé nach bhfuil sé ag obair agus go gcaithfidh sé é féin a iompar ar bhealach difriúil. Ní mór an cód a ullmhú ar an bhfíric nach n-oibríonn na bunachair shonraí i gcónaí.
Feidhmithe sonracha
Uaireanta ba mhaith linn i ndáiríre fós réiteach neamhchaighdeánach de chineál éigin a bheith againn mar inneall. Ag an am céanna, socraíodh gan ár seachfhreastalaí rpc réamhdhéanta, a cruthaíodh go sonrach dár n-innill, a úsáid, ach seachfhreastalaí ar leith a dhéanamh don tasc.
Maidir le MySQL, atá fós againn anseo agus ansiúd, úsáidimid db-proxy, agus le haghaidh ClickHouse - Kittenhouse.
Oibríonn sé go ginearálta mar seo. Tá freastalaí áirithe ann, ritheann sé kPHP, Téigh, Python - go ginearálta, aon chód is féidir lenár bprótacal RPC a úsáid. Ritheann an cód go háitiúil ar sheachvótálaí RPC - ritheann gach freastalaí ina bhfuil an cód suite a seachfhreastalaí áitiúil féin. Arna iarraidh sin, tuigeann an seachfhreastalaí cá háit le dul.
Más mian le hinneall amháin dul go dtí ceann eile, fiú más comharsa é, téann sé trí sheachvótálaí, toisc go bhféadfadh an comharsa a bheith i lárionad sonraí eile. Níor cheart go mbeadh an t-inneall ag brath ar shuíomh aon rud eile seachas é féin a fhios agam - is é seo ár réiteach caighdeánach. Ach ar ndóigh tá eisceachtaí ann :)
Sampla de scéim TL a n-oibríonn gach inneall dá réir.
memcache.not_found = memcache.Value;
memcache.strvalue value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;
tasks.task
fields_mask:#
flags:int
tag:%(Vector int)
data:string
id:fields_mask.0?long
retries:fields_mask.1?int
scheduled_time:fields_mask.2?int
deadline:fields_mask.3?int
= tasks.Task;
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;Is prótacal dénártha é seo, agus is é an analóg is gaire dó protobuf. Déanann an scéimre réamhshonrú ar réimsí roghnacha, cineálacha casta - síneadh scálaí ionsuite, agus ceisteanna. Oibríonn gach rud de réir an phrótacail seo.
RPC thar TL thar TCP/UDP… UDP?
Tá prótacal RPC againn chun iarratais innill a fheidhmiú a ritheann ar bharr na scéime TL. Oibríonn sé seo ar fad thar nasc TCP/UDP. Tá TCP intuigthe, ach cén fáth a dteastaíonn UDP uainn go minic?
Cuidíonn UDP seachain an fhadhb a bhaineann le líon mór nasc idir freastalaithe. Má tá seachfhreastalaí RPC ag gach freastalaí agus, go ginearálta, is féidir leis dul chuig aon inneall, ansin tá na mílte nasc TCP in aghaidh an fhreastalaí. Tá ualach ann, ach tá sé useless. I gcás an CDU níl an fhadhb seo ann.
Gan aon chroitheadh láimhe TCP iomarcach. Is fadhb tipiciúil é seo: nuair a sheoltar inneall nua nó freastalaí nua, bunaítear go leor nasc TCP ag an am céanna. I gcás iarratais éadroma beaga, mar shampla, ualach pá UDP, tá gach cumarsáid idir an cód agus an t-inneall dhá phaicéad UDP: cuileoga duine i dtreo amháin, an dara ceann sa treo eile. Turas cruinn amháin - agus fuair an cód freagra ón inneall gan croitheadh láimhe.
Sea, oibríonn sé go léir ach le céatadán an-bheag de chaillteanas paicéid. Tá tacaíocht ag an bprótacal le haghaidh ath-tharchuir agus tréimhsí ama, ach má chaillimid go leor, gheobhaidh muid beagnach TCP, rud nach bhfuil tairbheach. Ní thiomáineann muid UDP trasna na n-aigéan.
Tá na mílte freastalaithe den sórt sin againn, agus tá an scéim mar an gcéanna: tá pacáiste inneall suiteáilte ar gach freastalaí fisiceach. Tá siad den chuid is mó aon-snáithithe a reáchtáil chomh tapa agus is féidir gan blocáil, agus tá siad bearrtha mar réitigh aon-snáithithe. Ag an am céanna, níl aon rud níos iontaofa againn ná na hinnill seo, agus tugtar go leor aird ar stóráil sonraí leanúnach.
Stóráil sonraí marthanach
Scríobhann innill binlogaí. Comhad is ea binlog a gcuirtear imeacht le haghaidh athrú stáit nó sonraí leis ag an deireadh. I réitigh éagsúla a thugtar air go difriúil: logáil dhénártha, , , ach tá an prionsabal mar an gcéanna.
Chun cosc a chur ar an inneall an binlog iomlán a athléamh le blianta fada agus é ag atosú, scríobhann na hinnill snapshots - staid reatha. Más gá, léann siad uaidh ar dtús, agus ansin críochnaíonn siad léamh ón mbosca bruscair. Scríobhtar na boscaí bruscair go léir san fhormáid dhénártha chéanna - de réir na scéime TL, ionas gur féidir le riarthóirí iad a riar go cothrom lena n-uirlisí. Níl gá dá leithéid le pictiúir. Tá ceanntásc ginearálta ann a thugann le fios cé acu pictiúr atá istigh, draíocht an innill, agus cén corp nach bhfuil tábhachtach do dhuine ar bith. Is fadhb é seo leis an inneall a thaifead an pictiúr.
Déanfaidh mé cur síos go tapa ar phrionsabal na hoibríochta. Tá freastalaí ar a ritheann an t-inneall. Osclaíonn sé bosca bruscair folamh nua le haghaidh scríbhneoireachta agus scríobhann sé imeacht chun é a athrú.
Ag am éigin, socraíonn sé pictiúr a ghlacadh é féin, nó faigheann sé comhartha. Cruthaíonn an freastalaí comhad nua, scríobhann sé a staid iomlán isteach ann, cuireann sé an méid binlog reatha - fritháireamh - i gceangal le deireadh an chomhaid, agus leanann sé ag scríobh tuilleadh. Ní chruthaítear loga bruscair nua.
Ag am éigin, nuair a atosóidh an t-inneall, beidh binlog agus pictiúr ar an diosca. Léann an t-inneall an pictiúr iomlán agus ardaíonn sé a staid ag pointe áirithe.
Léann sé an t-ionad a bhí ag an am a cruthaíodh an pictiúr agus méid an loga bruscair.
Léann sé deireadh an loga bruscair chun an staid reatha a fháil agus leanann sé ag scríobh tuilleadh imeachtaí. Is scéim shimplí í seo; oibríonn ár n-innill go léir dá réir.
Macasamhlú sonraí
Mar thoradh air sin, sonraí a mhacasamhlú in ár ráiteas-bhunaithe — ní athraíonn muid aon leathanach sa bhosca bruscair, ach eadhon iarratais ar athrú. An-chosúil leis an méid a thagann thar an líonra, ach beagán modhnaithe.
Úsáidtear an scéim chéanna ní hamháin le haghaidh macasamhlú, ach freisin chun cúltacaí a chruthú. Tá inneall againn - máistir scríbhneoireachta a scríobhann don bhosca bruscair. In aon áit eile a shocraigh na riarthóirí é, déantar an binlog seo a chóipeáil, agus sin é - tá cúltaca againn.
Más gá duit macasamhail léitheoireachtaChun an t-ualach léitheoireachta LAP a laghdú, seoltar an t-inneall léitheoireachta go simplí, a léann deireadh an bhosca bruscair agus a fhorghníomhaíonn na horduithe seo go háitiúil.
Tá an mhoill anseo an-bheag, agus is féidir a fháil amach cé mhéad atá an macasamhail taobh thiar den mháistir.
Comhroinnt sonraí i seachfhreastalaí RPC
Conas a oibríonn bearradh? Conas a thuigeann an seachfhreastalaí cén braisle shard le seoladh chuige? Ní deir an cód: "Seol le haghaidh 15 shards!" - ní hea, déanann an seachfhreastalaí é seo.
Is é an scéim is simplí firstint — an chéad uimhir san iarraidh.
get(photo100_500) => 100 % N.
Is sampla é seo do phrótacal téacs memcached simplí, ach, ar ndóigh, is féidir le fiosrúcháin a bheith casta agus struchtúrtha. Tógann an sampla an chéad uimhir sa cheist agus an chuid eile nuair a roinntear é ar mhéid an bhraisle.
Tá sé seo úsáideach nuair is mian linn ceantar sonraí aonán amháin a bheith againn. Ligean le rá gur ID úsáideora nó grúpa é 100, agus ba mhaith linn go mbeadh sonraí uile aonáin amháin ar shard amháin le haghaidh ceisteanna casta.
Mura bhfuil suim againn conas a scaiptear iarratais ar fud an bhraisle, tá rogha eile ann - hashing an shard ar fad.
hash(photo100_500) => 3539886280 % N
Faighimid freisin an hash, an chuid eile den rannán agus an uimhir shard.
Ní oibríonn an dá rogha seo ach amháin má táimid réidh leis an bhfíric, nuair a mhéadaímid méid an bhraisle, go roinnfimid é nó go méadóimid é go minic. Mar shampla, bhí 16 shards againn, níl go leor againn, ba mhaith linn níos mó - is féidir linn 32 a fháil go sábháilte gan am downt. Más mian linn nach iolraí a mhéadú, beidh aga neamhfhónaimh ann, mar ní bheidh muid in ann gach rud a roinnt go cruinn gan aon chaillteanais. Tá na roghanna seo úsáideach, ach ní i gcónaí.
Más gá dúinn líon treallach freastalaithe a chur leis nó a bhaint, úsáidimid hashing comhsheasmhach ar an bhfáinne a la Ketama. Ach ag an am céanna, caillimid ceantar na sonraí go hiomlán; caithfimid an t-iarratas a chumasc leis an mbraisle ionas go dtabharfaidh gach píosa a fhreagra beag féin ar ais, agus ansin na freagraí ar an seachfhreastalaí a chumasc.
Tá iarratais shár-shonracha ann. Breathnaíonn sé mar seo: faigheann seachfhreastalaí RPC an t-iarratas, cinneann sé cén braisle le dul chuige agus socraíonn sé an shard. Ansin tá máistrí scríbhneoireachta ann, nó, má tá macasamhail tacaíochta ag an gcnuasach, seolann sé chuig macasamhail ar éileamh. Déanann an seachfhreastalaí seo go léir.
Logs
Scríobhaimid logaí ar bhealaí éagsúla. Is é an ceann is soiléire agus simplí logs a scríobh chuig memcache.
ring-buffer: prefix.idx = line
Tá réimír eochair - ainm an loga, líne, agus tá méid an loga seo - líon na línte. Glacaimid uimhir randamach ó 0 go dtí líon na línte lúide 1. Is réimír í an eochair i memcache atá comhcheangailte leis an uimhir randamach seo. Sábhálann muid an líne logála agus an t-am reatha go dtí an luach.
Nuair is gá logs a léamh, déanaimid amach Il Faigh gach eochair, curtha in eagar de réir ama, agus dá bhrí sin logáil táirgeachta a fháil i bhfíor-am. Úsáidtear an scéim nuair is gá duit rud éigin a dhífhabhtú i dtáirgeadh i bhfíor-am, gan aon rud a bhriseadh, gan trácht a stopadh nó a cheadú chuig meaisíní eile, ach ní mhaireann an logáil seo fada.
Le haghaidh stóráil iontaofa logs ní mór dúinn inneall logs-inneall. Is é seo go beacht an fáth gur cruthaíodh é agus úsáidtear go forleathan é i líon mór braislí. Is é an braisle is mó atá ar eolas agam ná siopaí 600 TB de logaí pacáilte.
Tá an t-inneall an-sean, tá braislí ann cheana féin 6-7 bliana d'aois. Tá fadhbanna leis go bhfuil muid ag iarraidh a réiteach, mar shampla, thosaigh muid ag úsáid go gníomhach ClickHouse chun logs a stóráil.
Logaí a bhailiú i ClickHouse
Taispeánann an léaráid seo conas a shiúilimid isteach inár n-innill.
Tá cód ann a théann go háitiúil trí RPC chuig an seachfhreastalaí RPC, agus tuigeann sé cá háit le dul chuig an inneall. Más mian linn logaí a scríobh i ClickHouse, ní mór dúinn dhá chuid a athrú sa scéim seo:
- ionad roinnt inneall le ClickHouse;
- ionad an seachvótálaí RPC, nach féidir leis rochtain a fháil ar ClickHouse, le réiteach éigin is féidir, agus trí RPC.
Tá an t-inneall simplí - cuirimid freastalaí nó braisle freastalaithe ina ionad le ClickHouse.
Agus chun dul go ClickHouse, rinneamar Teach Kitten. Má théimid díreach ó KittenHouse go ClickHouse, ní éireoidh leis. Fiú gan iarratais, cuireann sé suas ó naisc HTTP de líon mór meaisíní. Le go n-oibreoidh an scéim, ar fhreastalaí le ClickHouse ardaítear seachfhreastalaí droim ar ais áitiúil, atá scríofa sa chaoi is gur féidir leis na méideanna riachtanacha nasc a sheasamh. Is féidir leis sonraí laistigh di féin a mhaolánú go réasúnta iontaofa.
Uaireanta ní theastaíonn uainn an scéim RPC a chur i bhfeidhm i réitigh neamhchaighdeánacha, mar shampla, i nginx. Mar sin, tá an cumas ag KittenHouse logaí a fháil trí UDP.
Má oibríonn seoltóir agus faighteoir na logaí ar an meaisín céanna, ansin tá an dóchúlacht go gcaillfear paicéad UDP laistigh den ósta áitiúil íseal go leor. Mar chomhréiteach idir an gá atá le RPC a chur i bhfeidhm i réiteach tríú páirtí agus iontaofacht, ní úsáidimid ach seoladh UDP. Fillfimid ar an scéim seo níos déanaí.
Monatóireacht
Tá dhá chineál loga againn: iad siúd a bhailíonn riarthóirí ar a gcuid freastalaithe agus iad siúd a scríobhann forbróirí ó chód. Freagraíonn siad do dhá chineál méadrachta: córas agus táirge.
Méadracht chórais
Oibríonn sé ar ár freastalaithe go léir , a bhailíonn staitisticí agus a sheolann chuig Carbón grafite. Mar sin, úsáidtear ClickHouse mar chóras stórála, agus ní Whisper, mar shampla. Más gá, is féidir leat léamh go díreach ó ClickHouse, nó úsáid grafana le haghaidh méadrachta, graif agus tuarascálacha. Mar fhorbróirí, tá go leor rochtana againn ar Netdata agus Grafana.
Méadracht táirge
Ar mhaithe le caoithiúlacht, tá a lán rudaí scríofa againn. Mar shampla, tá sraith gnáthfheidhmeanna ann a ligeann duit Comhaireamh, luachanna UniqueCounts a scríobh isteach i staitisticí, a sheoltar áit éigin eile.
statlogsCountEvent ( ‘stat_name’, $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid, $key1, $key2, …)
statlogsValuetEvent ( ‘stat_name’, $value, $key1, $key2, …)
$stats = statlogsStatData($params)
Ina dhiaidh sin, is féidir linn scagairí sórtála agus grúpála a úsáid agus gach rud a theastaíonn uainn ó staitisticí a dhéanamh - graif a thógáil, Watchdogs a chumrú.
Scríobhaimid an- go leor méadrachta tá líon na n-imeachtaí ó 600 billiún go 1 trilliún in aghaidh an lae. Mar sin féin, ba mhaith linn iad a choinneáil ar a laghad cúpla bliaintreochtaí sa mhéadracht a thuiscint. Is fadhb mhór í é a chur le chéile nach bhfuil réitithe againn go fóill. Inseoidh mé duit conas atá sé ag obair le cúpla bliain anuas.
Tá feidhmeanna againn a scríobhann na méadrachtaí seo chuig memcache áitiúilchun líon na n-iontrálacha a laghdú. Uair amháin i dtréimhse ghearr ama seolta go háitiúil stats-daemon bailíonn gach taifead. Ansin, cumaisc an diabhal an mhéadracht i dhá shraith freastalaithe logs-bailitheoirí, a chomhiomlánaíonn staitisticí ó chuid dár n-innill ionas nach bhfaighidh an ciseal taobh thiar díobh bás.
Más gá, is féidir linn scríobh go díreach chuig na bailitheoirí logs.
Ach is droch-réiteach inscálaithe é scríobh ó chód go díreach chuig bailitheoirí, ag seachaint stas-daemom, toisc go méadaíonn sé an t-ualach ar an mbailitheoir. Níl an réiteach oiriúnach ach amháin más rud é ar chúis éigin nach féidir linn an memcache stats-daemon a ardú ar an meaisín, nó gur thit sé agus chuaigh muid go díreach.
Ansin, cumaisc logs-bailitheoirí staitisticí isteach meowDB - is é seo ár mbunachar sonraí, ar féidir leo méadracht a stóráil freisin.
Ansin is féidir linn roghanna dénártha “near-SQL” a dhéanamh ón gcód.
Turgnamh
I samhradh na bliana 2018, bhí hackathon inmheánach againn, agus tháinig an smaoineamh chun iarracht a dhéanamh an chuid dearg den léaráid a athsholáthar le rud éigin a d'fhéadfadh méadracht a stóráil i ClickHouse. Tá logs againn ar ClickHouse - cén fáth nach mbainfidh tú triail as?
Bhí scéim againn a scríobh logaí trí KittenHouse.
Shocraigh muid cuir “*Teach” eile leis an léaráid, a gheobhaidh go díreach na méadrachtaí san fhormáid mar a scríobhann ár gcód iad trí UDP. Ansin déanann an *Teach seo iad a thiontú ina ionsáigh, cosúil le logaí, a thuigeann KittenHouse. Is féidir leis na logaí seo a sheachadadh go foirfe chuig ClickHouse, agus ba cheart go mbeadh sé in ann iad a léamh.
Cuirtear an scéim seo in ionad na scéime le memcache, stats-daemon agus logs-collectors.
Cuirtear an scéim seo in ionad na scéime le memcache, stats-daemon agus logs-collectors.
- Tá seoladh ó chód anseo, atá scríofa go háitiúil i StatsHouse.
- Scríobhann StatsHouse méadracht UDP, atá tiontaithe cheana féin ina ionsáigh SQL, chuig KittenHouse i mbaisceanna.
- Seolann KittenHouse chuig ClickHouse iad.
- Más mian linn iad a léamh, ansin léigh muid iad ag seachaint StatsHouse - go díreach ó ClickHouse ag baint úsáide as SQL rialta.
An bhfuil sé fós turgnamh, ach is maith linn conas a tharlaíonn sé. Má shocraíonn muid na fadhbanna leis an scéim, ansin b’fhéidir go n-athróimid chuici go hiomlán. Go pearsanta, tá súil agam.
An scéim ní shábháil iarann. Tá níos lú freastalaithe ag teastáil, níl gá le stats-daemons áitiúla agus logs-bailitheoirí, ach tá freastalaí níos mó ag teastáil ó ClickHouse ná iad siúd sa scéim reatha. Tá gá le níos lú freastalaithe, ach caithfidh siad a bheith níos costasaí agus níos cumhachtaí.
Imscaradh
Ar dtús, déanaimis féachaint ar an imscaradh PHP. Táimid ag forbairt i git: úsáid GitLab и TeamCity le haghaidh imscaradh. Déantar brainsí forbartha a chumasc isteach sa mháistir-bhrainse, ón máistir le haghaidh tástála déantar iad a chumasc go céimniú, agus ó chéimniú go táirgeadh.
Sula n-imscartar, tógtar an brainse táirgthe reatha agus an ceann roimhe seo, agus breathnaítear comhaid diff iontu - athruithe: cruthaithe, scriosta, athraithe. Déantar an t-athrú seo a thaifeadadh sa bhosca bruscair d'inneall cóip-luath speisialta, ar féidir leis athruithe ar ár bhflít freastalaí iomlán a mhacasamhlú go tapa. Ní hé an rud a úsáidtear anseo a chóipeáil go díreach, ach macasamhlú gossip, nuair a sheolann freastalaí amháin athruithe chuig a chomharsana is gaire, iad siúd chuig a chomharsana, agus mar sin de. Ligeann sé seo duit an cód a nuashonrú i ndeicheanna agus aonaid soicind ar fud an chabhlaigh ar fad. Nuair a shroicheann an t-athrú an macasamhail áitiúil, baineann sé na paistí seo lena córas comhaid áitiúil. Déantar ais-rolladh freisin de réir na scéime céanna.
Bainimid úsáid as kPHP go leor freisin agus tá a fhorbairt féin aige freisin git de réir na léaráide thuas. Ós rud é seo Dénártha freastalaí HTTP, ansin ní féidir linn difr a tháirgeadh - meáchan an scaoileadh dénártha na céadta MB. Mar sin, tá rogha eile anseo - scríobhtar an leagan chuige binlog copyfast. Le gach tógáil méadaíonn sé, agus le linn rolladh siar méadaíonn sé freisin. Leagan a mhacasamhlú chuig freastalaithe. Feiceann cóip-fastanna áitiúla go bhfuil leagan nua curtha isteach sa bhosca bruscair, agus leis an macasamhlú gossip céanna a thógann siad an leagan is déanaí den dénártha dóibh féin, gan tuirseach ár bhfreastalaí, ach go cúramach leathadh an t-ualach ar fud an líonra. Cad a leanas athsheoladh galánta don leagan nua.
Le haghaidh ár n-innill, atá freisin go bunúsach dénártha, tá an scéim an-chosúil:
- brainse máistir git;
- dénártha i .deb;
- tá an leagan scríofa go binlog copyfast;
- a mhacasamhlú chuig freastalaithe;
- tarraingíonn an freastalaí amach .dep úr;
- dpkg -i;
- athsheoladh galánta go leagan nua.
Is é an difríocht ná go bhfuil ár dénártha pacáistithe i gcartlann .deb, agus nuair a phumpáil siad amach dpkg -i a chuirtear ar an gcóras. Cén fáth a ndéantar kPHP a imscaradh mar dhénártha, agus innill a imscaradh mar dpkg? Tharla sé mar sin. Oibríonn sé - ná déan teagmháil leis.
Naisc úsáideacha:
- Tuarascáil ag Anton Kiryushkin le sonraí faoi copyfast agus gossip.
- Tuarascáil ag Yuri Nasretdinov .
- Mo thuarascáil , ach ó thaobh forbartha de, ní crua-earraí.
Tá Alexey Akulovich ar dhuine díobh siúd a chabhraíonn, mar chuid de Choiste an Chláir ar 17 Bealtaine beidh an ócáid is mó d'fhorbróirí PHP le blianta beaga anuas. Féach cad ríomhaire fionnuar atá againn, cad é (tá dhá cheann acu ag forbairt croí PHP!) - cosúil le rud éigin nach féidir leat a chailleann má scríobhann tú PHP.
Foinse: will.com