🥇Algengar spurningar um arkitektúr og vinnu við VKontakte

Saga stofnunar VKontakte er á Wikipedia; það var sagt af Pavel sjálfum. Það virðast allir þekkja hana nú þegar. Um innviði, arkitektúr og uppbyggingu síðunnar á HighLoad++ Pavel sagði mér aftur árið 2010. Margir netþjónar hafa lekið síðan þá, þannig að við munum uppfæra upplýsingarnar: við munum kryfja þær, taka út innanverða, vega og skoða VK tækið frá tæknilegu sjónarhorni.

Alexey Akulovich (AterCattus) bakenda verktaki í VKontakte teyminu. Afrit þessarar skýrslu er sameiginlegt svar við algengum spurningum um rekstur vettvangsins, innviði, netþjóna og samskipti þeirra á milli, en ekki um þróun, þ.e. um járn. Sérstaklega um gagnagrunna og það sem VK hefur í staðinn, um söfnun logs og eftirlit með öllu verkefninu í heild. Upplýsingar undir klippingu.

Í meira en fjögur ár hef ég fengist við alls kyns verkefni sem tengjast bakendanum.

Hlaða upp, geyma, vinna, dreifa miðlum: myndbandi, streymi í beinni, hljóði, myndum, skjölum.
Innviðir, vettvangur, eftirlit þróunaraðila, annálar, svæðisbundin skyndiminni, CDN, sérsniðin RPC samskiptareglur.
Samþætting við ytri þjónustu: ýtt tilkynningar, þáttun ytri tengla, RSS straumur.
Að aðstoða samstarfsmenn með ýmsar spurningar, svörin við þeim krefjast þess að kafa í óþekktan kóða.

Á þessum tíma hafði ég hönd í bagga með mörgum hlutum síðunnar. Mig langar að deila þessari reynslu.

Almennur byggingarlist

Allt, eins og venjulega, byrjar á netþjóni eða hópi netþjóna sem samþykkja beiðnir.

Framþjónn

Framþjónninn tekur við beiðnum í gegnum HTTPS, RTMP og WSS.

HTTPS - þetta eru beiðnir um aðal- og farsímaútgáfur vefsvæðisins: vk.com og m.vk.com, og aðrir opinberir og óopinberir viðskiptavinir API okkar: farsímaviðskiptavinir, boðberar. Við erum með móttöku RTMP-umferð fyrir beinar útsendingar með aðskildum framþjónum og WSS- tengingar fyrir streymi API.

Fyrir HTTPS og WSS á netþjónum er það þess virði nginx. Fyrir RTMP útsendingar skiptum við nýlega yfir í okkar eigin lausn kive, en það er utan gildissviðs skýrslunnar. Fyrir bilanaþol auglýsa þessir netþjónar algengar IP tölur og starfa í hópum þannig að ef vandamál er á einum af netþjónunum tapast notendabeiðnir ekki. Fyrir HTTPS og WSS dulkóða þessir sömu netþjónar umferð til að taka hluta af CPU álaginu á sig.

Ekki verður talað frekar um WSS og RTMP, heldur aðeins um staðlaðar HTTPS beiðnir, sem venjulega eru tengdar vefverkefni.

Bakendi

Fyrir aftan framhliðina eru venjulega bakendaþjónar. Þeir vinna úr beiðnum sem framþjónninn fær frá viðskiptavinum.

Það kPHP netþjóna, þar sem HTTP púkinn er í gangi, vegna þess að HTTPS er þegar afkóðað. kPHP er þjónn sem keyrir á prefork módel: byrjar meistaraferli, fullt af barnaferlum, sendir hlustunarinnstungum til þeirra og þeir vinna úr beiðnum sínum. Í þessu tilviki eru ferli ekki endurræst á milli hverrar beiðni frá notanda, heldur einfaldlega endurstillt ástand þeirra í upprunalegt núllgildi - beiðni eftir beiðni, í stað þess að endurræsa.

Hlaða dreifingu

Allir bakendarnir okkar eru ekki stór hópur af vélum sem geta afgreitt hvaða beiðni sem er. Við þau skipt í aðskilda hópa: almennt, farsíma, API, myndband, sviðsetning... Vandamálið á sérstökum hópi véla mun ekki hafa áhrif á allar aðrar. Ef upp koma vandamál með myndband mun notandinn sem hlustar á tónlist ekki einu sinni vita um vandamálin. Til hvaða bakenda á að senda beiðnina er ákveðið af nginx að framan samkvæmt stillingunni.

Söfnun mæligilda og endurjafnvægi

Til að skilja hversu marga bíla við þurfum að hafa í hverjum hópi, gerum við ekki treysta á QPS. Bakendarnir eru mismunandi, þeir hafa mismunandi beiðnir, hver beiðni hefur mismunandi flókið útreikning QPS. Þess vegna erum við við vinnum með hugmyndina um álag á þjóninum í heild - á CPU og perf.

Við höfum þúsundir slíkra netþjóna. Hver líkamlegur netþjónn rekur kPHP hóp til að endurvinna alla kjarna (vegna þess að kPHP er einn þráður).

Efnisþjónn

CS eða Content Server er geymsla. CS er þjónn sem geymir skrár og vinnur einnig úr hlaðnum skrám og alls kyns samstilltum bakgrunnsverkefnum sem aðalframhlið vefsins úthlutar honum.

Við höfum tugþúsundir líkamlegra netþjóna sem geyma skrár. Notendur elska að hlaða upp skrám og við elskum að geyma og deila þeim. Sumum þessara netþjóna er lokað af sérstökum pu/pp netþjónum.

pú/bls

Ef þú opnaðir netflipann í VK, sástu pu/pp.

Hvað er pu/pp? Ef við lokum einum netþjóni á eftir öðrum, þá eru tveir möguleikar til að hlaða upp og hlaða niður skrá á netþjóninn sem var lokaður: beint gegnum http://cs100500.userapi.com/path eða í gegnum millimiðlara - http://pu.vk.com/c100500/path.

Pu er sögulegt nafn fyrir upphleðslu mynda og pp er umboð fyrir myndir. Það er, einn þjónn er til að hlaða upp myndum og annar er til að hlaða upp. Nú eru ekki aðeins myndir hlaðnar heldur hefur nafnið verið varðveitt.

Þessir netþjónar slíta HTTPS lotumtil að fjarlægja örgjörvaálagið úr geymslunni. Einnig, þar sem notendaskrár eru unnar á þessum netþjónum, því minna viðkvæmar upplýsingar sem eru geymdar á þessum vélum, því betra. Til dæmis, HTTPS dulkóðunarlyklar.

Þar sem vélunum er lokað af öðrum vélum okkar, höfum við efni á að gefa þeim ekki „hvítar“ ytri IP-tölur, og gefa "grátt". Þannig sparaðum við IP-laugina og tryggðum að vélarnar yrðu verndaðar fyrir utanaðkomandi aðgangi - það er einfaldlega engin IP til að komast inn í það.

Seiglu yfir sameiginlegum IP-tölum. Hvað varðar bilanaþol virkar kerfið eins - nokkrir líkamlegir netþjónar hafa sameiginlega líkamlega IP og vélbúnaðurinn fyrir framan þá velur hvert á að senda beiðnina. Ég mun tala um aðra valkosti síðar.

Hið umdeilda atriði er að í þessu tilfelli viðskiptavinurinn heldur færri tengingum. Ef það er sama IP-tala fyrir margar vélar - með sama hýsingaraðila: pu.vk.com eða pp.vk.com, hefur viðskiptavinavafrinn takmörk á fjölda beiðna samtímis til einn gestgjafa. En á tímum alls staðar nálægur HTTP/2 tel ég að þetta sé ekki lengur svo viðeigandi.

Augljósi ókosturinn við kerfið er að það þarf að gera það dæla allri umferð, sem fer í geymsluna, í gegnum annan netþjón. Þar sem við dælum umferð í gegnum vélar getum við ekki enn dælt þungri umferð, til dæmis myndbandi, með sama kerfi. Við sendum það beint - aðskilin bein tenging fyrir aðskildar geymslur sérstaklega fyrir myndband. Við sendum léttara efni í gegnum proxy.

Ekki er langt síðan við fengum endurbætta útgáfu af proxy. Nú skal ég segja þér hvernig þeir eru frábrugðnir venjulegum og hvers vegna þetta er nauðsynlegt.

Sun

Í september 2017, Oracle, sem áður hafði keypt Sun, sagt upp miklum fjölda starfsmanna Sun. Við getum sagt að á þessari stundu hafi fyrirtækið hætt að vera til. Við val á nafni á nýja kerfið ákváðu stjórnendur okkar að heiðra minningu þessa fyrirtækis og nefndu nýja kerfið Sun. Innbyrðis köllum við hana einfaldlega „sólir“.

pp átti í nokkrum vandamálum. Ein IP í hverjum hóp - óvirkt skyndiminni. Nokkrir líkamlegir netþjónar deila sameiginlegu IP-tölu og það er engin leið að stjórna hvaða netþjóni beiðnin fer á. Þess vegna, ef mismunandi notendur koma fyrir sömu skrána, þá ef það er skyndiminni á þessum netþjónum, endar skráin í skyndiminni hvers netþjóns. Þetta er mjög óhagkvæmt kerfi en ekkert hægt að gera.

Þar af leiðandi - við getum ekki brotið niður efni, vegna þess að við getum ekki valið ákveðinn netþjón fyrir þennan hóp - þeir hafa sameiginlega IP. Einnig af einhverjum innri ástæðum sem við höfum það var ekki hægt að setja upp slíka netþjóna á svæðum. Þeir stóðu aðeins í Pétursborg.

Með sólunum breyttum við valkerfinu. Nú höfum við anycast leið: kraftmikil leið, anycast, sjálfsskoðunarpúki. Hver netþjónn hefur sína eigin IP, en sameiginlegt undirnet. Allt er stillt á þann hátt að ef einn netþjónn bilar dreifist umferðin sjálfkrafa á aðra netþjóna í sama hópi. Nú er hægt að velja ákveðinn netþjón, engin óþarfi skyndiminni, og áreiðanleiki var ekki fyrir áhrifum.

Þyngdarstuðningur. Nú höfum við efni á að setja upp vélar af mismunandi afli eftir þörfum og einnig, ef upp koma tímabundin vandamál, breyta þyngd vinnu "sólanna" til að draga úr álagi á þær, þannig að þær "hvíli" og byrji að vinna aftur.

Deiling eftir auðkenni efnis. Fyndið við klippingu: við klippum venjulega efni þannig að mismunandi notendur fara í sömu skrána í gegnum sömu „sólina“ þannig að þeir hafi sameiginlegt skyndiminni.

Við opnuðum nýlega „Clover“ forritið. Þetta er spurningakeppni á netinu í beinni útsendingu þar sem gestgjafinn spyr spurninga og notendur svara í rauntíma og velja valkosti. Í appinu er spjall þar sem notendur geta spjallað. Getur tengst útsendingunni samtímis meira en 100 þúsund manns. Þeir skrifa allir skilaboð sem eru send til allra þátttakenda og avatar kemur með skilaboðunum. Ef 100 þúsund manns koma fyrir einn avatar í einni „sól“, þá getur það stundum rúllað á bak við ský.

Til að standast beiðnir um sömu skrá er það fyrir ákveðna tegund af efni sem við kveikjum á heimskulegu kerfi sem dreifir skrám yfir allar tiltækar „sólar“ á svæðinu.

Sól að innan

Reverse proxy á nginx, skyndiminni annað hvort í vinnsluminni eða á hröðum Optane/NVMe diskum. Dæmi: http://sun4-2.userapi.com/c100500/path — tengill á „sólina“ sem er staðsett á fjórða svæðinu, öðrum netþjónahópnum. Það lokar slóðaskránni, sem líkamlega liggur á þjóninum 100500.

Cache

Við bætum einum hnút í viðbót við byggingarkerfi okkar - skyndiminnisumhverfið.

Hér að neðan er útlitsmynd svæðisbundin skyndiminni, þeir eru um 20 talsins. Þetta eru staðirnir þar sem skyndiminni og „sólar“ eru staðsettar, sem geta vistað umferð í gegnum sig.

Þetta er skyndiminni margmiðlunarefnis; engin notendagögn eru geymd hér - bara tónlist, myndbönd, myndir.

Til að ákvarða svæði notandans, við við söfnum BGP netforskeytum sem tilkynnt eru um á þessum svæðum. Ef um er að ræða fallback, verðum við líka að flokka geoip gagnagrunninn ef við gátum ekki fundið IP með forskeytum. Við ákveðum svæðið út frá IP notanda. Í kóðanum getum við skoðað eitt eða fleiri svæði notandans - þá punkta sem hann er næst landfræðilega.

Hvernig virkar það?

Við teljum vinsældir skráa eftir svæðum. Það er númer svæðisskyndiminni þar sem notandinn er staðsettur og skráaauðkenni - við tökum þetta par og hækkum einkunnina með hverju niðurhali.

Á sama tíma koma djöflar - þjónustur á svæðum - af og til að API og segja: „Ég er svona og svo skyndiminni, gefðu mér lista yfir vinsælustu skrárnar á mínu svæði sem eru ekki ennþá á mér. ” API afhendir fullt af skrám flokkuðum eftir einkunn, púkinn halar þeim niður, fer með þær á svæðin og afhendir skrárnar þaðan. Þetta er grundvallarmunurinn á pu/pp og Sun úr skyndiminni: þeir gefa skrána í gegnum sjálfa sig strax, jafnvel þótt þessi skrá sé ekki í skyndiminni, og skyndiminni hleður skránni fyrst niður til sjálfs sín og byrjar síðan að gefa hana til baka.

Í þessu tilfelli fáum við efni nær notendum og dreifa netálaginu. Til dæmis, aðeins frá Moskvu skyndiminni dreifum við meira en 1 Tbit/s á álagstímum.

En það eru vandamál - skyndiminni þjónar eru ekki gúmmí. Fyrir ofurvinsælt efni er stundum ekki nóg netkerfi fyrir sérstakan netþjón. Skyndiminniþjónarnir okkar eru 40-50 Gbit/s en það er efni sem algjörlega stíflar slíka rás. Við erum að fara að innleiða geymslu á fleiri en einu eintaki af vinsælum skrám á svæðinu. Ég vona að við munum koma því í framkvæmd fyrir áramót.

Við skoðuðum hinn almenna arkitektúr.

Framþjónar sem samþykkja beiðnir.
Stuðlar að því ferli beiðnir.
Geymslur sem eru lokaðar með tvenns konar umboðum.
Svæðisgeymslur.

Hvað vantar á þessa skýringarmynd? Auðvitað, gagnagrunnarnir sem við geymum gögn í.

Gagnagrunnar eða vélar

Við köllum þá ekki gagnagrunna, heldur vélar - Vélar, vegna þess að við höfum nánast ekki gagnagrunna í almennum viðurkenndum skilningi.

Þetta er nauðsynleg ráðstöfun. Þetta gerðist vegna þess að á árunum 2008-2009, þegar VK naut mikillar vinsælda, virkaði verkefnið algjörlega á MySQL og Memcache og það voru vandamál. MySQL elskaði að hrynja og spilla skrám, eftir það myndi það ekki batna, og Memcache minnkaði smám saman í afköstum og þurfti að endurræsa.

Það kemur í ljós að sífellt vinsælla verkefnið hafði viðvarandi geymslu, sem skemmir gögn, og skyndiminni, sem hægir á sér. Við slíkar aðstæður er erfitt að þróa vaxandi verkefni. Ákveðið var að reyna að endurskrifa þá mikilvægu hluti sem verkefnið beindist að á okkar eigin reiðhjól.

Lausnin tókst. Það var tækifæri til að gera þetta, sem og ýtrustu nauðsyn, því aðrar leiðir til stigstærðar voru ekki til á þeim tíma. Það var ekki fullt af gagnagrunnum, NoSQL var ekki til ennþá, það voru bara MySQL, Memcache, PostrgreSQL - og það er það.

Alhliða rekstur. Þróunin var leidd af teymi okkar af C þróunaraðilum og allt var gert á samkvæman hátt. Burtséð frá vélinni, þeir voru allir með um það bil sama skráarsnið skrifað á diskinn, sömu ræsibreytur, unnu merki á sama hátt og hegðuðu sér nokkurn veginn eins ef upp koma jaðaraðstæður og vandamál. Með vexti véla er þægilegt fyrir stjórnendur að stjórna kerfinu - það er enginn dýragarður sem þarf að viðhalda og þeir verða að læra upp á nýtt hvernig á að stjórna hverjum nýjum þriðja aðila gagnagrunni, sem gerði það mögulegt að stækka á fljótlegan og þægilegan hátt númer þeirra.

Tegundir véla

Liðið skrifaði töluvert af vélum. Hér eru aðeins nokkrar af þeim: vinur, vísbendingar, mynd, ipdb, bréf, listar, logs, memcached, meowdb, fréttir, nostradamus, mynd, lagalistar, pmemcached, sandkassi, leit, geymsla, líkar við, verkefni, …

Fyrir hvert verkefni sem krefst sérstakrar gagnauppbyggingar eða vinnur af óhefðbundnum beiðnum, skrifar C teymið nýja vél. Af hverju ekki.

Við erum með sérstaka vél skyndiminni, sem er svipað og venjulegur, en með fullt af góðgæti, og sem hægir ekki á sér. Ekki ClickHouse, en það virkar líka. Fæst sér pmemcached - Er viðvarandi memcached, sem getur einnig geymt gögn á diski, þar að auki, en passar inn í vinnsluminni, svo að gögn tapist ekki við endurræsingu. Það eru ýmsar vélar fyrir einstök verkefni: biðraðir, listar, sett - allt sem verkefnið okkar krefst.

Klasar

Frá sjónarhóli kóðans er engin þörf á að hugsa um vélar eða gagnagrunna sem ferla, einingar eða tilvik. Kóðinn virkar sérstaklega með klasa, með hópum af vélum - ein tegund á hvern klasa. Segjum að það sé til geymd þyrping - þetta er bara hópur véla.

Kóðinn þarf alls ekki að vita staðsetningu, stærð eða fjölda netþjóna. Hann fer í þyrpinguna með því að nota ákveðið auðkenni.

Til að þetta virki þarftu að bæta við einni einingu í viðbót sem er staðsett á milli kóðans og vélanna - umboð.

RPC umboð

Umboð tengir strætó, sem nánast öll vefsvæðið keyrir á. Á sama tíma höfum við engin þjónustuuppgötvun — í staðinn er stilling fyrir þetta umboð, sem veit staðsetningu allra klasa og allra brota þessa klasa. Þetta er það sem stjórnendur gera.

Forriturum er alveg sama hversu mikið, hvar og hvað það kostar - þeir fara bara í þyrpinguna. Þetta gerir okkur mikið kleift. Þegar beiðni berst, vísar umboðsmaður beiðninni áfram, vitandi hvert - það ákvarðar þetta sjálfur.

Í þessu tilviki er umboð vörn gegn þjónustubilun. Ef einhver vél hægir á sér eða hrynur, þá skilur umboðsmaðurinn þetta og bregst við viðskiptavininum í samræmi við það. Þetta gerir þér kleift að fjarlægja tímamörkin - kóðinn bíður ekki eftir að vélin bregðist við, heldur skilur að hún virkar ekki og þarf að haga sér einhvern veginn öðruvísi. Kóðinn þarf að undirbúa fyrir þá staðreynd að gagnagrunnarnir virka ekki alltaf.

Sérstakar útfærslur

Stundum viljum við samt virkilega hafa einhvers konar óstaðlaða lausn sem vél. Á sama tíma var ákveðið að nota ekki tilbúna rpc-proxy okkar, sem er sérstaklega búinn til fyrir vélarnar okkar, heldur að búa til sérstakt umboð fyrir verkefnið.

Fyrir MySQL, sem við höfum enn hér og þar, notum við db-proxy, og fyrir ClickHouse - Kettlingahús.

Þetta virkar almennt svona. Það er ákveðinn netþjónn, hann keyrir kPHP, Go, Python - almennt hvaða kóða sem er sem getur notað RPC samskiptareglur okkar. Kóðinn keyrir staðbundið á RPC proxy - hver netþjónn þar sem kóðinn er staðsettur keyrir sinn staðbundna proxy. Ef þess er óskað, skilur umboðsmaður hvert hann á að fara.

Ef ein vél vill fara í aðra, jafnvel þótt hún sé nágranni, fer hún í gegnum proxy, því nágranninn gæti verið í öðru gagnaveri. Vélin ætti ekki að treysta á að vita staðsetningu neins annars en sjálfrar sín - þetta er staðallausnin okkar. En auðvitað eru undantekningar :)

Dæmi um TL-kerfi sem allar vélar starfa eftir.

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;

Þetta er tvöfaldur samskiptaregla, næst hliðstæða þeirra er frumefni. Skemanið lýsir fyrir valkvæðum sviðum, flóknum gerðum - framlengingum á innbyggðum stigstærðum og fyrirspurnum. Allt virkar samkvæmt þessari samskiptareglu.

RPC yfir TL yfir TCP/UDP… UDP?

Við erum með RPC samskiptareglur til að framkvæma vélarbeiðnir sem keyra ofan á TL kerfinu. Þetta virkar allt í gegnum TCP/UDP tengingu. TCP er skiljanlegt, en hvers vegna þurfum við UDP oft?

UDP hjálpar forðast vandamálið með miklum fjölda tenginga milli netþjóna. Ef hver netþjónn er með RPC proxy og almennt getur hann farið í hvaða vél sem er, þá eru tugþúsundir TCP tenginga á hvern netþjón. Það er álag, en það er ónýtt. Í tilviki UDP er þetta vandamál ekki til staðar.

Ekkert óþarfi TCP handaband. Þetta er dæmigert vandamál: þegar ný vél eða nýr netþjónn er ræstur eru margar TCP tengingar komið á í einu. Fyrir litlar, léttar beiðnir, til dæmis, UDP farmur, eru öll samskipti milli kóðans og vélarinnar tveir UDP pakkar: einn flýgur í aðra áttina, hinn í hina áttina. Ein ferð fram og til baka - og kóðinn fékk svar frá vélinni án handabandi.

Já, þetta virkar bara allt með mjög litlu hlutfalli af pakkatapi. Samskiptareglan hefur stuðning fyrir endursendingar og tímamörk, en ef við töpum miklu fáum við næstum TCP, sem er ekki arðbært. Við keyrum ekki UDP yfir höf.

Við höfum þúsundir slíkra netþjóna og kerfið er það sama: pakki af vélum er settur upp á hverjum líkamlegum netþjóni. Þær eru að mestu einþráðar til að keyra eins fljótt og auðið er án þess að stíflast, og eru brotnar sem einþráðar lausnir. Á sama tíma höfum við ekkert áreiðanlegra en þessar vélar og mikil athygli er lögð á viðvarandi gagnageymslu.

Viðvarandi geymsla gagna

Vélar skrifa binlogs. Binlog er skrá í lok þess sem atburði fyrir breytingu á ástandi eða gögnum er bætt við. Í mismunandi lausnum er það kallað öðruvísi: binary log, WAL, AOF, en meginreglan er sú sama.

Til að koma í veg fyrir að vélin lesi allt binlog aftur í mörg ár við endurræsingu, skrifa vélarnar skyndimyndir - núverandi ástand. Ef nauðsyn krefur lesa þeir fyrst úr því og klára síðan að lesa úr binlognum. Öll binlog eru skrifuð á sama tvöfalda sniði - samkvæmt TL kerfinu, svo að stjórnendur geti stjórnað þeim jafnt með því að nota verkfærin sín. Það er engin slík þörf fyrir skyndimyndir. Það er almennur haus sem gefur til kynna hvers mynd er int, galdur vélarinnar og hvaða líkami er ekki mikilvægur fyrir neinn. Þetta er vandamál með vélina sem tók upp skyndimyndina.

Ég mun fljótt lýsa meginreglunni um rekstur. Það er netþjónn sem vélin keyrir á. Hann opnar nýtt tómt binlog til að skrifa og skrifar atburði til að breyta því.

Á einhverjum tímapunkti ákveður hann annað hvort að taka mynd sjálfur eða hann fær merki. Miðlarinn býr til nýja skrá, skrifar allt ástand hennar inn í hana, bætir núverandi binlog stærð - offset - við lok skráarinnar og heldur áfram að skrifa. Nýtt binlog er ekki búið til.

Á einhverjum tímapunkti, þegar vélin fór í gang aftur, verður bæði binlog og skyndimynd á disknum. Vélin les alla skyndimyndina og hækkar stöðu sína á ákveðnum tímapunkti.

Les stöðuna sem var þegar skyndimyndin var búin til og stærð binlogsins.

Les lok binlogsins til að fá núverandi stöðu og heldur áfram að skrifa frekari atburði. Þetta er einfalt kerfi; allar vélar okkar vinna samkvæmt því.

Gagnaafritun

Þar af leiðandi er afritun gagna í okkar yfirlýsing byggð — við skrifum í binlog ekki neinar síðubreytingar, heldur þ.e breytingarbeiðnir. Mjög svipað því sem kemur yfir netið, aðeins breytt.

Sama kerfi er notað ekki aðeins til afritunar, heldur einnig til að búa til afrit. Við erum með vél - ritstjóra sem skrifar í binlog. Á hverjum öðrum stað þar sem stjórnendur setja það upp, er þetta binlog afritað, og það er það - við höfum öryggisafrit.

Ef þess er þörf lestrar eftirmyndTil að draga úr lestrarálagi CPU er lestrarvélin einfaldlega ræst, sem les lok binlogsins og framkvæmir þessar skipanir á staðnum.

Töfin hér er mjög lítil og hægt er að komast að því hversu mikið eftirmyndin er á eftir meistaranum.

Gagnaskiptingu í RPC proxy

Hvernig virkar klipping? Hvernig skilur umboðsmaðurinn hvaða klasabrot á að senda til? Kóðinn segir ekki: "Senda eftir 15 shards!" - nei, þetta er gert af umboðinu.

Einfaldasta kerfið er firstint — fyrsta númerið í beiðninni.

get(photo100_500) => 100 % N.

Þetta er dæmi um einfalda textasamskiptareglur sem eru í geymslu, en auðvitað geta fyrirspurnir verið flóknar og skipulagðar. Dæmið tekur fyrstu töluna í fyrirspurninni og afganginn þegar deilt er með klasastærðinni.

Þetta er gagnlegt þegar við viljum hafa gagnastað einni einingar. Segjum að 100 sé notanda- eða hópauðkenni og við viljum að öll gögn eins aðila séu á einni broti fyrir flóknar fyrirspurnir.

Ef okkur er alveg sama hvernig beiðnum er dreift um klasann, þá er annar möguleiki - að hassa allt brotið.

hash(photo100_500) => 3539886280 % N

Við fáum líka kjötkássa, afganginn af skiptingunni og brotanúmerið.

Báðir þessir valkostir virka aðeins ef við erum tilbúin fyrir þá staðreynd að þegar við aukum stærð klasans munum við skipta honum eða fjölga honum margfalt. Til dæmis áttum við 16 brot, við höfum ekki nóg, við viljum meira - við getum örugglega fengið 32 án niður í miðbæ. Ef við viljum auka ekki margfeldi, þá verður niður í miðbæ, vegna þess að við munum ekki geta skipt öllu upp nákvæmlega án taps. Þessir valkostir eru gagnlegir, en ekki alltaf.

Ef við þurfum að bæta við eða fjarlægja handahófskenndan fjölda netþjóna notum við Stöðugt hass á hringnum a la Ketama. En á sama tíma missum við algjörlega staðsetningu gagnanna; við verðum að sameina beiðnina við þyrpinguna þannig að hvert stykki skilar sínu litlu svari og sameina síðan svörin við umboðið.

Það eru mjög sérstakar beiðnir. Það lítur svona út: RPC umboðsmaður tekur á móti beiðninni, ákveður í hvaða þyrping á að fara og ákvarðar brotið. Svo eru annaðhvort ritmeistarar, eða ef þyrpingin hefur eftirlíkingarstuðning sendir hann á eftirmynd eftir beiðni. Umboðið gerir þetta allt.

Logs

Við skrifum logs á nokkra vegu. Það augljósasta og einfaldasta er skrifa logs í memcache.

ring-buffer: prefix.idx = line

Það er lykilforskeyti - nafn skrárinnar, lína, og það er stærðin á þessum annál - fjöldi lína. Við tökum slembitölu frá 0 í fjölda lína mínus 1. Lykillinn í memcache er forskeyti sem er samtengt þessari slembitölu. Við vistum loglínuna og núverandi tíma í gildi.

Þegar það er nauðsynlegt að lesa logs, framkvæma við Multi Get alla lykla, raðað eftir tíma, og fá þannig framleiðsludagbók í rauntíma. Kerfið er notað þegar þú þarft að kemba eitthvað í framleiðslu í rauntíma, án þess að brjóta neitt, án þess að stöðva eða leyfa umferð til annarra véla, en þessi skrá endist ekki lengi.

Fyrir áreiðanlega geymslu á trjábolum höfum við vél logs-vél. Þetta er einmitt ástæðan fyrir því að það var búið til og er mikið notað í miklum fjölda klasa. Stærsti klasi sem ég veit um geymir 600 TB af pakkaðri annál.

Vélin er mjög gömul, það eru klasar sem eru þegar orðnir 6-7 ára. Það eru vandamál með það sem við erum að reyna að leysa, til dæmis byrjuðum við að nota ClickHouse virkan til að geyma annála.

Söfnun annála í ClickHouse

Þessi skýringarmynd sýnir hvernig við göngum inn í vélarnar okkar.

Það er kóði sem fer staðbundið í gegnum RPC til RPC-proxy, og það skilur hvert á að fara í vélina. Ef við viljum skrifa logs í ClickHouse þurfum við að breyta tveimur hlutum í þessu kerfi:

skipta um einhverja vél með ClickHouse;
skipta um RPC proxy, sem hefur ekki aðgang að ClickHouse, með einhverri lausn sem getur, og í gegnum RPC.

Vélin er einföld - við skiptum henni út fyrir netþjón eða þyrping af netþjónum með ClickHouse.

Og til að fara í ClickHouse, gerðum við það KittenHouse. Ef við förum beint frá KittenHouse til ClickHouse mun það ekki takast á við það. Jafnvel án beiðna bætist það upp frá HTTP tengingum á gríðarlegum fjölda véla. Til að kerfið virki, á netþjóni með ClickHouse staðbundið umboð er hækkað, sem er skrifað á þann hátt að það þolir nauðsynlegt magn af tengingum. Það getur einnig biðminni gögn í sjálfu sér tiltölulega áreiðanlega.

Stundum viljum við ekki innleiða RPC kerfið í óstöðluðum lausnum, til dæmis í nginx. Þess vegna hefur KittenHouse getu til að taka á móti annálum í gegnum UDP.

Ef sendandi og viðtakandi annálanna vinna á sömu vélinni, þá eru líkurnar á því að tapa UDP pakka innan staðbundins hýsils frekar litlar. Sem málamiðlun milli þörfarinnar á að innleiða RPC í lausn frá þriðja aðila og áreiðanleika, notum við einfaldlega UDP sendingu. Við munum snúa aftur að þessu fyrirkomulagi síðar.

Eftirlit

Við erum með tvenns konar annála: þær sem stjórnendur safna á netþjónum sínum og þær sem forritarar skrifa úr kóða. Þeir samsvara tvenns konar mæligildum: kerfi og vöru.

Kerfismælingar

Það virkar á öllum netþjónum okkar Netgögn, sem safnar tölfræði og sendir til Grafít kolefni. Þess vegna er ClickHouse notað sem geymslukerfi en ekki Whisper til dæmis. Ef nauðsyn krefur geturðu lesið beint úr ClickHouse eða notað grafana fyrir mælikvarða, línurit og skýrslur. Sem verktaki höfum við nægan aðgang að Netdata og Grafana.

Vörumælingar

Til hægðarauka höfum við skrifað ýmislegt. Til dæmis, það er sett af venjulegum aðgerðum sem gera þér kleift að skrifa Counts, UniqueCounts gildi í tölfræði, sem eru send einhvers staðar lengra.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

Í kjölfarið getum við notað flokkunar- og flokkunarsíur og gert allt sem við viljum úr tölfræði - smíðað línurit, stillt varðhunda.

Við skrifum mjög margar mælikvarðar fjöldi atburða er frá 600 milljörðum til 1 billjón á dag. Við viljum hins vegar halda þeim að minnsta kosti nokkur árað skilja þróun í mæligildum. Að setja þetta allt saman er stórt vandamál sem við höfum ekki leyst ennþá. Ég skal segja þér hvernig það hefur virkað undanfarin ár.

Við höfum aðgerðir sem skrifa þessar mælingar í staðbundið minnisminniað fækka færslum. Einu sinni á stuttum tíma hleypt af stokkunum á staðnum tölfræði-púki safnar öllum gögnum. Næst sameinar púkinn mælikvarðana í tvö lög af netþjónum timbur-safnarar, sem safnar saman tölfræði úr fullt af vélum okkar svo að lagið fyrir aftan þær deyi ekki.

Ef nauðsyn krefur getum við skrifað beint til annálasafnara.

En að skrifa úr kóða beint til safnara, framhjá stas-daemom, er illa skalanleg lausn vegna þess að það eykur álagið á safnarann. Lausnin hentar aðeins ef af einhverjum ástæðum getum við ekki hækkað memcache stats-púkann á vélinni, eða hún hrundi og við fórum beint.

Næst sameina annálasafnarar tölfræði í mjáDB - þetta er gagnagrunnurinn okkar, sem getur einnig geymt mælikvarða.

Þá getum við valið tvöfalt „near-SQL“ úr kóðanum.

Tilraun

Sumarið 2018 vorum við með innra hackathon og þá kom upp sú hugmynd að reyna að skipta út rauða hluta skýringarmyndarinnar fyrir eitthvað sem gæti geymt mælikvarða í ClickHouse. Við erum með logs á ClickHouse - af hverju ekki að prófa það?

Við vorum með kerfi sem skrifaði logs í gegnum KittenHouse.

Við ákváðum bættu öðru „*Hús“ við skýringarmyndina, sem mun fá nákvæmlega mælikvarðana á sniðinu eins og kóðinn okkar skrifar þær í gegnum UDP. Síðan breytir þetta *Hús þau í innlegg, eins og stokka, sem KittenHouse skilur. Hann getur fullkomlega afhent þessa annála til ClickHouse, sem ætti að geta lesið þær.

Kerfinu með memcache, stats-daemon og logs-collectors gagnagrunni er skipt út fyrir þennan.

Það er sending frá kóða hér, sem er skrifaður á staðnum í StatsHouse.
StatsHouse skrifar UDP mæligildi, sem þegar hefur verið breytt í SQL innskot, í KittenHouse í lotum.
KittenHouse sendir þá til ClickHouse.
Ef við viljum lesa þær, þá lesum við þær framhjá StatsHouse - beint frá ClickHouse með venjulegum SQL.

Er það enn tilraun, en okkur líkar hvernig það kemur út. Ef við lagum vandamálin með kerfinu, þá munum við kannski skipta yfir í það algjörlega. Persónulega vona ég það.

Kerfið sparar ekki járn. Færri netþjóna er þörf, staðbundin tölfræðipúka og logsafnara er ekki þörf, en ClickHouse krefst stærri netþjóns en þeir sem eru í núverandi kerfi. Það þarf færri netþjóna en þeir verða að vera dýrari og öflugri.

Dreifa

Fyrst skulum við líta á PHP dreifinguna. Við erum að þróast í Git: nota GitLab и TeamCity til dreifingar. Þróunargreinar eru sameinaðar í aðalgrein, frá meistara til prófunar eru þær sameinaðar í sviðsetningu og frá sviðsetningu í framleiðslu.

Fyrir uppsetningu er núverandi framleiðslugrein og sú fyrri tekin og mismunandi skrár eru teknar fyrir í þeim - breytingar: búið til, eytt, breytt. Þessi breyting er skráð í binlog sérstakrar copyfast vél, sem getur fljótt endurtekið breytingar á öllum netþjónaflotanum okkar. Það sem er notað hér er ekki afritun beint, heldur slúðurafritun, þegar einn þjónn sendir breytingar til nánustu nágranna sinna, til nágranna þeirra, og svo framvegis. Þetta gerir þér kleift að uppfæra kóðann á tugum og sekúndnaeiningum yfir allan flotann. Þegar breytingin nær til staðbundinnar eftirmyndar, setur hún þessa plástra á hana staðbundið skráarkerfi. Afturköllun er einnig framkvæmd samkvæmt sama kerfi.

Við sendum líka kPHP mikið og það hefur líka sína eigin þróun Git samkvæmt skýringarmyndinni hér að ofan. Síðan þetta HTTP þjónn tvöfaldur, þá getum við ekki framleitt diff - útgáfutvíundirinn vegur hundruð MB. Þess vegna er annar valkostur hér - útgáfan er skrifuð til binlog copyfast. Með hverri byggingu eykst það og við afturköllun eykst það líka. Útgáfa endurtekið á netþjóna. Staðbundnir copyfasts sjá að ný útgáfa er komin inn í binlog, og með sömu slúðurafrituninni taka þeir nýjustu útgáfuna af tvöfaldanum fyrir sig, án þess að þreyta aðalþjóninn okkar, heldur dreifa álaginu vandlega yfir netið. Það sem á eftir kemur þokkafull endurræsing fyrir nýju útgáfuna.

Fyrir vélarnar okkar, sem einnig eru í meginatriðum tvíþættir, er kerfið mjög svipað:

git meistara grein;
tvöfaldur í .deb;
útgáfan er skrifuð á binlog copyfast;
endurtekið á netþjóna;
þjónninn dregur út ferskt .dep;
dpkg -i;
þokkafull endurræsing í nýja útgáfu.

Munurinn er sá að tvöfaldur okkar er pakkaður í skjalasafn .deb, og þegar þeir dæla út dpkg -i eru settar á kerfið. Af hverju er kPHP notað sem tvöfaldur, og vélar eru notaðar sem dpkg? Það gerðist þannig. Það virkar - ekki snerta það.

Gagnlegar hlekkir:

Skýrsla eftir Anton Kiryushkin „Vkontakte kerfisstjóri. Hvernig?" með upplýsingum um copyfast og slúður.
Skýrsla Yuri Nasretdinov „Hvernig VK setur gögn inn í CLickHouse frá tugþúsundum netþjóna“.
Skýrslan mín „Arkitektúr vaxandi verkefnis með því að nota dæmi um VKontakte“, en frá þróunarsjónarmiði, ekki vélbúnaði.

Alexey Akulovich er einn þeirra sem, sem hluti af dagskrárnefndinni, aðstoðar PHP Rússland þann 17. maí verður stærsti viðburðurinn fyrir PHP forritara í seinni tíð. Sjáðu hvað við eigum flotta tölvu, hvað hátalarar (tveir þeirra eru að þróa PHP kjarna!) - virðist vera eitthvað sem þú mátt ekki missa af ef þú skrifar PHP.

Heimild: www.habr.com

Algengar spurningar um arkitektúr og verk VKontakte