Dîroka afirandina VKontakte li ser Wîkîpediya ye; ew ji hêla Pavel bixwe ve hatî gotin. Wusa dixuye ku her kes wê jixwe nas dike. Di derbarê hundurîn, mîmarî û avahiya malperê de li ser HighLoad ++ Pavel . Ji wê hingê ve gelek server derketine, ji ber vê yekê em ê agahdarî nûve bikin: em ê wê veqetînin, hundurê xwe derxînin, giran bikin, û ji hêla teknîkî ve li cîhaza VK binihêrin.
Alexey Akulovich () di tîmê VKontakte de pêşdebirê paşîn. Veguhastina vê raporê bersivek kolektîf e ji pirsên pir caran di derbarê xebata platformê, binesaziyê, servers û danûstendina di navbera wan de, lê ne di derbarê pêşkeftinê de, yanî li ser hesin. Ji hev veqetandî, di derheqê databasan de û tiştê ku VK li şûna wê heye, di derbarê berhevkirina têketin û şopandina tevahiya projeyê de bi tevahî. Details di bin cut.
Zêdetirî çar sal in ku ez bi her cûre peywirên ku bi paşverû ve girêdayî ne re mijûl dibim.
- Barkirin, hilanîn, hilanîn, belavkirina medyayê: vîdyo, weşana zindî, deng, wêne, belge.
- Binesaz, platform, çavdêriya pêşdebiran, têketin, kaşên herêmî, CDN, protokola xwedan RPC.
- Bi karûbarên derveyî re yekbûnek: agahdariya push, parkirina girêdana derveyî, feed RSS.
- Alîkariya hevkaran bi pirsên cûrbecûr re, bersivên wan hewce dike ku di kodek nenas de bin.
Di vê demê de, destê min di gelek beşên malperê de hebû. Ez dixwazim vê ezmûnê parve bikim.
Mîmariya Giştî
Her tişt, wekî gelemperî, bi serverek an komek serverên ku daxwazan qebûl dikin dest pê dike.
Pêşkêşkara pêşîn
Pêşkêşkara pêşîn bi HTTPS, RTMP û WSS daxwazan qebûl dike.
HTTPS - ev daxwazên ji bo guhertoyên webê yên sereke û mobîl ên malperê ne: vk.com û m.vk.com, û xerîdarên din ên fermî û nefermî yên API-ya me: xerîdarên mobîl, peyamber. Pêşwaziya me heye RTMP-trafîka ji bo weşanên Zindî bi pêşkêşkerên pêşîn ên cihê û WSS- girêdanên ji bo Streaming API.
Ji bo HTTPS û WSS li ser serveran ew hêja ye nginx. Ji bo weşanên RTMP, me vê dawîyê veguherî çareseriya xwe kive, lê ew li derveyî çarçoveya raporê ye. Ji bo tolerasyona xeletiyê, van server navnîşanên IP-ya hevpar reklam dikin û di koman de tevdigerin da ku heke li ser yek ji serveran pirsgirêkek hebe, daxwazên bikarhêner winda nebin. Ji bo HTTPS û WSS, van heman serveran seyrûseferê şîfre dikin da ku beşek ji barkirina CPU li ser xwe bigirin.
Em ê bêtir li ser WSS û RTMP neaxivin, lê tenê li ser daxwazên standard HTTPS, ku bi gelemperî bi projeyek malperê ve girêdayî ne.
Backend
Li pişt pêşê bi gelemperî serverên paşverû hene. Ew daxwazên ku servera pêşîn ji xerîdaran distîne pêvajoyê dikin.
ev pêşkêşkerên kPHP, ku li ser HTTP daemon dimeşîne, ji ber ku HTTPS jixwe veşartiye. kPHP serverek e ku li ser dixebite modelên prefork: pêvajoyeke sereke dide destpêkirin, komek pêvajoyên zarokan, soketên guhdarîkirinê ji wan re derbas dike û ew daxwazên wan pêk tînin. Di vê rewşê de, pêvajo di navbera her daxwazek bikarhêner de ji nû ve nayên destpêkirin, lê tenê rewşa xwe vedigere rewşa nirxa sifir - daxwaz li dû daxwazê, li şûna ku ji nû ve dest pê bike.
Belavkirina barkirinê
Hemî paşnavên me ne hewzek mezin a makîneyan in ku dikarin her daxwaziyekê bikin. Em wan di nav komên cuda de dabeş kirin: giştî, mobîl, api, vîdyoy, sehniyet... Pirsgirêka li ser komek makîneyên cûda dê bandorê li hemî yên din neke. Di rewşên pirsgirêkên vîdyoyê de, bikarhênerê ku muzîkê guhdarî dike dê ji pirsgirêkan jî nizanibe. Kîjan paşîn ku daxwaznameyê bişîne ji hêla nginx ve li pêş li gorî vesazkirinê biryar dide.
Berhevkirin û hevsengkirina Metric
Ji bo ku em fêm bikin ka em di her komê de çend gerîdeyên hewce ne ku hebin, em pişta xwe nedin QPS. Piştgiran cûda ne, daxwazên wan ên cûda hene, her daxwazek xwedan tevliheviyek cûda ya hesabkirina QPS ye. Ji ber vê em em bi têgîna barkirinê ya li ser serverê bi tevahî - li ser CPU û perf dixebitin.
Bi hezaran serverên me yên weha hene. Her serverek laşî komek kPHP-ê dimeşîne da ku hemî naverok ji nû ve vegerîne (ji ber ku kPHP yek xêzkirî ye).
Servera naverokê
CS an Pêşkêşkara Naverokê depoyek e. CS serverek e ku pelan hildide û di heman demê de pelên barkirî û her cûre peywirên hevdem ên paşerojê yên ku eniya sereke ya webê jê re destnîşan dike jî pêvajoyê dike.
Bi deh hezaran serverên me yên laşî hene ku pelan diparêzin. Bikarhêner ji barkirina pelan hez dikin, û em hez dikin ku wan hilînin û parve bikin. Hin ji van serveran ji hêla serverên pu/pp yên taybetî ve têne girtin.
pu/pp
Ger we tabloya torê di VK de vekir, we pu/pp dît.
pu/pp çi ye? Ger em serverek li dû yê din bigrin, wê hingê du vebijark ji bo barkirin û dakêşana pelek li servera ku hatî girtin hene: rasterast bi saya http://cs100500.userapi.com/path an bi rêya server navîn - http://pu.vk.com/c100500/path.
Pu navê dîrokî ye ji bo barkirina wêneyê, û pp wekîlê wêneyê ye. Ango serverek ji bo barkirina wêneyan e, ya din jî ji bo barkirinê ye. Niha ne tenê wêne têne barkirin, lê nav jî hatiye parastin.
Ev server danişînên HTTPS biqedîninji bo rakirina barkirina pêvajoyê ji hilanînê. Di heman demê de, ji ber ku pelên bikarhêner li ser van serveran têne hilberandin, agahdariya kêmtir hesas ku li ser van makîneyan têne hilanîn, çêtir e. Mînakî, bişkojkên şîfrekirina HTTPS.
Ji ber ku makîneyên ji hêla makîneyên me yên din ve têne girtin, em dikarin ji wan re IP-yên derveyî yên "spî" nedin, û bide "gewr". Bi vî rengî me li hewza IP-yê tomar kir û garantî da ku em makîneyan ji gihandina derveyî biparêzin - bi tenê IP-ya ku têkevin hundurê wê tune.
Berxwedana li ser IP-yên hevpar. Di warê tolerasyona xeletiyê de, nexşe bi heman rengî dixebite - çend serverên laşî xwedan IP-ya fizîkî ya hevpar in, û hardware li pêş wan bijartin ku derê daxwazê bişîne. Ez ê paşê li ser vebijarkên din biaxivim.
Xala nakokî di vê rewşê de ye xerîdar kêm girêdan digire. Ger ji bo çend makîneyan heman IP hebe - bi heman mêvandarê: pu.vk.com an pp.vk.com, geroka xerîdar li ser hejmara daxwazên hevdemî ji yek mêvandar re sînorek heye. Lê di dema HTTP/2-ya berbelav de, ez bawer dikim ku ev êdî ne ew qas têkildar e.
Kêmasiya eşkere ya nexşeyê ew e ku pêdivî ye pompe hemû trafîkê, ku diçe hilanînê, bi riya serverek din. Ji ber ku em seyrûseferê di nav makîneyan de pomp dikin, em hîna jî nikarin seyrûsefera giran, mînakî vîdyoyê, bi karanîna heman pileyê derxînin. Em wê rasterast veguhezînin - pêwendiyek rasterast a cihêreng ji bo depoyên cihêreng bi taybetî ji bo vîdyoyê. Em naveroka siviktir bi navgînek veguhezînin.
Ne demek berê me guhertoyek pêşkeftî ya proxy wergirt. Naha ez ê ji we re vebêjim ka ew ji yên normal çawa cûda dibin û çima ev hewce ye.
tav
Di Îlona 2017 de, Oracle, ku berê Sun kirîbû, . Em dikarin bêjin ku di vê gavê de pargîdanî rawestiya. Dema ku navek ji bo pergala nû hilbijart, rêveberên me biryar dan ku rêzê li bîranîna vê pargîdaniyê bidin û navê pergala nû kirin Sun. Di nav xwe de em bi tenê jê re dibêjin "roj".
pp çend pirsgirêk hebûn. Yek IP ji her komê - cache bêbandor. Gelek pêşkêşkerên laşî navnîşek IP-ya hevpar parve dikin, û rêyek tune ku meriv daxwazê biçe kîjan serverê kontrol bike. Ji ber vê yekê, heke bikarhênerên cihêreng ji bo heman pelê werin, wê hingê heke li ser van serveran cache hebe, pel di cache ya her serverê de diqede. Ev planek pir bêkêmasî ye, lê tiştek nehat kirin.
Di encamê de - em nikarin naverokê parve bikin, ji ber ku em nikarin serverek taybetî ji bo vê komê hilbijêrin - IP-ya wan a hevpar heye. Her wiha ji ber hin sedemên navxweyî em hene ne mimkun bû ku serverên weha li herêman saz bikin. Ew tenê li St.
Bi rojê re, me pergala hilbijartinê guhert. Niha em hene rêveçûna anycast: rêveçûna dînamîk, anycast, şeyda xwe-kontrolkirinê. Her server IP-ya xweya ferdî heye, lê subnetek hevpar. Her tişt bi vî rengî hatî mîheng kirin ku ger serverek têk biçe, seyrûsefer bixweber li ser serverên din ên heman komê belav dibe. Naha gengaz e ku meriv serverek taybetî hilbijêrin, no caching zêde, û pêbawerî bandor nebû.
Piştgiriya giraniyê. Naha em dikarin li gorî hewcedariyê makîneyên hêzdar ên cihêreng saz bikin, û her weha, di dema pirsgirêkên demkî de, giraniya "rojên" xebitandinê biguhezînin da ku barê wan kêm bikin, da ku ew "rehet bibin" û dîsa dest bi xebatê bikin.
Parvekirina bi nasnameya naverokê. Tiştek xweş di derbarê parvekirinê de: em bi gelemperî naverokê dişoxilînin da ku bikarhênerên cihêreng bi heman "roj"ê ve biçin heman pelê da ku ew xwedî cacheyek hevpar bin.
Me vê dawiyê sepana "Clover" da destpêkirin. Ev quizek serhêl e di weşanek zindî de, ku mêvandar pirsan dipirse û bikarhêner di demek rast de bersiv didin, vebijarkan hilbijêrin. The app heye chat ku bikarhêner dikarin chat. Dikare bi hevdemî bi weşanê ve were girêdan zêdetir ji 100 hezar kes. Ew hemî peyamên ku ji hemî beşdaran re têne şandin dinivîsin, û avatarek bi peyamê re tê. Ger 100 hezar kes ji bo yek avatarê di yek "rojê" de werin, wê hingê ew carinan dikare li pişt ewrekî bizivire.
Ji bo ku em li ber teqîna daxwazên heman pelê bisekinin, ji bo celebek naverokê ye ku em nexşeyek ehmeqî vedikin ku pelan li hemî "roj"ên heyî yên li herêmê belav dike.
Roj ji hundir
Li ser nginx proxy berevajî, cache an di RAM-ê de an jî li ser dîskên Optane / NVMe yên bilez. Mînak: http://sun4-2.userapi.com/c100500/path - girêdanek bi "roj", ku li herêma çaremîn, koma servera duyemîn e. Ew pelê rê, ku bi fîzîkî li ser servera 100500-ê ye, digire.
cover
Em yek nodek din li nexşeya xweya mîmarî zêde dikin - hawîrdora caching.
Li jêr diagrama layout e kaşên herêmî, nêzîkî 20 ji wan hene. Vana ew cihên ku keş û "roj" lê ne, ku dikarin trafîkê bi nav xwe veşêrin.
Ev cachkirina naveroka multimedia ye; tu daneyên bikarhêner li vir nayê hilanîn - tenê muzîk, vîdyo, wêne.
Ji bo diyarkirina herêma bikarhêner, em em pêşpirtikên tora BGP yên ku li herêman hatine ragihandin berhev dikin. Di doza paşvekêşanê de, ger me nikarîbû IP-ê bi pêşgiran bibînin, pêdivî ye ku em databasa geoip-ê jî parsek bikin. Em herêmê bi IP-ya bikarhêner diyar dikin. Di kodê de, em dikarin li yek an çend deverên bikarhêner binihêrin - ew xalên ku ew ji hêla erdnîgarî ve herî nêzîk e.
Çawa dixebite?
Em populerbûna pelan li gorî herêmê dihejmêrin. Hejmarek cacheya herêmî ya ku bikarhêner lê ye, û nasnameyek pelê heye - em vê cotê digirin û bi her dakêşanê re rêjeyê zêde dikin.
Di heman demê de, cin - karûbarên li herêman - dem bi dem têne API-yê û dibêjin: "Ez cacheyek wusa û wusa me, navnîşek pelên herî populer ên li herêma min ên ku hîn li ser min nîn in bidin min. ” API komek pelên ku li gorî rêjeyê hatine rêz kirin radigihîne, daemon wan dakêşîne, wan digihîne herêman û pelan ji wir radest dike. Cûdahiya bingehîn di navbera pu/pp û Sun ji kaşeyan de ev e: ew pelê tavilê di nav xwe de didin, her çend ev pel ne di cache de be jî, û cache pêşî pelê ji xwe re dadixe, û dûv re dest bi vegerandina wê dike.
Di vê rewşê de em digirin naverok nêzîkî bikarhêneran û barkirina torê belav dike. Mînakî, tenê ji cacheya Moskowê em di demjimêrên lûtkeyê de ji 1 Tbit/s zêdetir belav dikin.
Lê pirsgirêk hene - pêşkêşkerên cache ne lastîkî ne. Ji bo naveroka super populer, carinan ji bo serverek cûda torgilokek têr tune. Pêşkêşkerên meya cache 40-50 Gbit / s in, lê naverok heye ku kanalek wusa bi tevahî digire. Em ber bi pêkanîna hilanîna zêdetirî kopiyek pelên populer ên li herêmê diçin. Hêvîdar im heta dawiya salê em ê bi cih bînin.
Me li mîmariya giştî nêrî.
- Pêşkêşkerên pêşîn ên ku daxwazan qebûl dikin.
- Piştgiriyên ku daxwazên pêvajoyê dikin.
- Depoyên ku ji hêla du celeb proxy ve têne girtin.
- Veşartinên herêmî.
Çi ji vê diagramê kêm dibe? Bê guman, databasên ku em tê de daneyan hilînin.
Databases an motorên
Em ji wan re ne databas, lê motoran dibêjin - Motor, ji ber ku em di pratîkê de di wateya gelemperî de ne xwediyê databasan in.
Ev tedbîrek pêwîst e. Ev çêbû ji ber ku di 2008-2009 de, dema ku VK di populerbûna xwe de mezinbûnek teqîner bû, proje bi tevahî li ser MySQL û Memcache xebitî û pirsgirêk hebûn. MySQL hez dikir ku pelan hilweşîne û xera bike, piştî ku ew ê baş nebe, û Memcache hêdî hêdî di performansê de kêm bû û neçar ma ku ji nû ve were destpêkirin.
Derket holê ku projeya ku her diçe populer dibe xwedî hilanîna domdar, ku daneyan xera dike, û cache, ku hêdî dibe, heye. Di şert û mercên wiha de pêşxistina projeyek mezin zehmet e. Biryar hat dayîn ku em hewl bidin ku tiştên krîtîk ên ku proje li ser disekine li ser bisîkletên xwe ji nû ve binivîsin.
Çareserî serkeftî bû. Derfetek ji bo vê yekê û her weha pêdiviyek giran hebû, ji ber ku wê demê rêyên din ên pîvandinê tune bûn. Komek databas tune bûn, NoSQL hîn nebû, tenê MySQL, Memcache, PostrgreSQL hebûn - û ew e.
Operasyona gerdûnî. Pêşveçûn ji hêla tîmê me ya pêşdebiran C ve hatî rêve kirin û her tişt bi rengek domdar hate kirin. Bêyî motorê, wan hemîyan hema hema heman forma pelê li ser dîskê hatî nivîsandin, heman pîvanên destpêkirinê, bi heman rengî îşaretan pêvajo kirin, û di rewş û pirsgirêkan de hema hema bi heman rengî tevdigerin. Bi mezinbûna motoran re, ji rêveberan re hêsan e ku pergalê bixebitînin - zozanek ku pêdivî ye ku were domandin tune ye, û ew neçar in ku ji nû ve fêr bibin ka meriv çawa databasa partiya sêyemîn a nû dixebitîne, ku ev gengaz kir ku zû û bi hêsanî zêde bibe. hejmara wan.
Cureyên motorên
Tîmê çend motoran nivîsand. Li vir tenê hinek ji wan hene: heval, nîşan, wêne, ipdb, tîp, navnîş, têketin, memcached, meowdb, nûçe, nostradamus, wêne, lîsteyên lîstikê, pmemcached, sandbox, lêgerîn, hilanînê, ecibandin, peywir,…
Ji bo her karekî ku avahiyek daneya taybetî hewce dike an daxwazên netîpîkî pêvajo dike, tîmê C motorek nû dinivîse. Çima na.
Motoreke me ya cuda heye bîranîn, ya ku dişibihe yekî birêkûpêk, lê bi komek xweş ve, û ku hêdî nake. Ne ClickHouse, lê ew jî dixebite. Ji hev cuda heye pmemcached Ye persistent memcached, ku di heman demê de dikare daneyan li ser dîskê jî hilîne, ji bilî ku di RAM-ê de cîh digire, da ku dema ji nû ve destpêkirinê daneyan winda neke. Ji bo karên kesane motorên cihêreng hene: rêz, navnîş, set - her tiştê ku projeya me hewce dike.
Clusters
Ji perspektîfek kodê, ne hewce ye ku meriv motor an databas wekî pêvajo, sazî, an mînakan bifikire. Kod bi taybetî bi koman, bi komên motoran re dixebite - yek cure her komê. Em bêjin komek memcached heye - ew tenê komek makîneyan e.
Kod qet hewce nake ku cîhê fîzîkî, mezinahî, an hejmara serveran bizanibe. Ew bi karanîna nasnameyek diyar diçe komê.
Ji bo ku ev bixebite, hûn hewce ne ku saziyek din ku di navbera kod û motoran de ye lê zêde bikin - proxy.
RPC proxy
Proxy otobusa girêdanê, ku hema hema tevahiya malper li ser dimeşe. Di heman demê de em hene tu vedîtina xizmetê - Li şûna wê, ji bo vê proxy vesazkirinek heye, ku cîhê hemî koman û hemî perçeyên vê komê dizane. Ya ku admîn dikin ev e.
Bernamesaz qet eleqedar nakin ka çiqas, li ku û çi lêçû - ew tenê diçin komê. Ev gelek rê dide me. Dema ku daxwazek distîne, proxy daxwazê beralî dike, zanibe li ku derê - ew bixwe vê yekê destnîşan dike.
Di vê rewşê de, proxy xalek parastinê ye li hember têkçûna karûbarê. Ger hin motor hêdî bibe an têk bibe, wê hingê proxy vê yekê fêm dike û li gorî wê bersivê dide aliyê xerîdar. Ev rê dide we ku hûn wextê derxînin - kod li benda bersivdana motorê namîne, lê fêm dike ku ew nexebite û pêdivî ye ku bi rengek cûda tevbigere. Pêdivî ye ku kod ji bo rastiya ku databas her gav naxebitin were amadekirin.
pêkanînên taybetî
Carinan em hîn jî bi rastî dixwazin wekî motorek celebek çareseriyek ne-standard hebe. Di heman demê de, biryar hate girtin ku em rpc-proxy-ya xweya amade ne bikar bînin, ku bi taybetî ji bo motorên me hatî afirandin, lê ji bo peywirê proxyek veqetandî çêbikin.
Ji bo MySQL, ku em hîn jî li vir û wir hene, em db-proxy bikar tînin, û ji bo ClickHouse - Kittenhouse.
Bi gelemperî bi vî rengî dixebite. Serverek diyar heye, ew kPHP, Go, Python dimeşîne - bi gelemperî, her kodek ku dikare protokola meya RPC bikar bîne. Kod bi herêmî li ser proxyek RPC-ê dimeşîne - her serverek ku kod lê ye proxya xweya herêmî dimeşîne. Li ser daxwazê, proxy fêm dike ku biçe ku derê.
Ger motorek bixwaze biçe yekî din, her çend ew cîran be jî, ew bi navgînek derbas dibe, ji ber ku cîran dibe ku li navendek daneya din be. Pêdivî ye ku motor bi zanîna cîhê tiştek din ji bilî xwe ve nesekine - ev çareseriya meya standard e. Lê helbet îstîsna hene :)
Nimûneya plansaziyek TL-ê ku li gorî wê hemî motor dixebitin.
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;Ev protokolek binary e, ku analoga herî nêzîk a wê ye protobuf. Şema qadên vebijarkî, celebên tevlihev - dirêjkirina scalarên çêkirî, û pirsan pêşdibistanê dike. Her tişt li gorî vê protokolê dixebite.
RPC li ser TL li ser TCP/UDP… UDP?
Protokolek me ya RPC heye ji bo pêkanîna daxwazên motorê ku li ser nexşeya TL-ê dimeşîne. Ev hemî li ser pêwendiyek TCP / UDP dixebite. TCP tê fêm kirin, lê çima em bi gelemperî UDP hewce ne?
UDP alîkarî dike ji pirsgirêka hejmareke mezin a girêdanên di navbera serveran de dûr bixin. Ger her serverek proxyek RPC heye û, bi gelemperî, ew dikare biçe her motorê, wê hingê bi deh hezaran girêdanên TCP-ê li ser serverek hene. Barek heye, lê bêkêr e. Di mijara UDP de ev pirsgirêk tune.
Destê TCP-ê zêde tune. Ev pirsgirêkek tîpîk e: dema ku motorek nû an serverek nû tê destpêkirin, gelek girêdanên TCP bi carekê ve têne saz kirin. Ji bo daxwazên piçûk ên sivik, mînakî, barkirina UDP, hemî ragihandina di navbera kod û motorê de ye du pakêtên UDP: yek li hêlekê difire, yê diduyan li aliyê din difire. Yek gera dor - û kodê bersivek ji motorê bêyî destan wergirt.
Erê, ew hemî tenê dixebite bi rêjeyek pir piçûk a windabûna pakêtê. Protokol ji bo veguheztin û demandan piştgirî heye, lê heke em pir winda bikin, em ê hema TCP-ê bistînin, ku ne sûdmend e. Em UDP-ê li deryayan dernaxin.
Bi hezaran serverên me hene, û nexşe yek e: pakêtek motoran li ser her serverek laşî tê saz kirin. Ew bi piranî yek-têlek in ku bi lez û bez bêyî astengkirinê bimeşin, û wekî çareseriyên yek-têl têne şilandin. Di heman demê de, ji van motoran pêbawertir tiştek me tune, û gelek bal tê kişandin ser hilanîna daneya domdar.
Hilberîna daneya domdar
Motoran binlogan dinivîsin. Binlog pelek e ku di dawiya wê de bûyerek ji bo guhertina rewş an daneyê tê zêdekirin. Di çareseriyên cûda de ew bi rengek cûda tê gotin: têketina binary, , , lê prensîb yek e.
Ji bo ku motor ji nû ve destpêkirina gelek salan tevahiya binlogê ji nû ve nexwîne, motor dinivîsin snapshots - rewşa niha. Ger hewce be, ew pêşî jê dixwînin, û paşê xwendina ji binlogê diqedînin. Hemî binlog di heman forma binary de - li gorî nexşeya TL-yê têne nivîsandin, da ku rêvebir bi karanîna amûrên xwe wan bi heman rengî îdare bikin. Hewcedariya bi vî rengî bi dîmenan tune. Sernivîsek gelemperî heye ku destnîşan dike ku wêneya kê int, sêhra motorê ye, û kîjan laş ji kesî re ne girîng e. Ev pirsgirêkek bi motora ku wêneyê tomar kiriye re ye.
Ez ê bi lez prensîba operasyonê vebêjim. Serverek heye ku motor li ser dixebitîne. Ew ji bo nivîsandinê binlogek nû ya vala vedike û ji bo guhertina wê bûyerek dinivîse.
Di demekê de, ew an biryar dide ku bi xwe wêneyek bikişîne, an jî îşaretek distîne. Pêşkêşkar pelek nû diafirîne, hemî rewşa xwe tê de dinivîse, mezinahiya binlogê ya heyî - offset - li dawiya pelê zêde dike, û nivîsandina bêtir berdewam dike. Bînlogek nû nehatiye çêkirin.
Di hin xalan de, dema ku motor ji nû ve dest pê kir, dê hem binlog û hem jî wêneyek li ser dîskê hebe. Motor tevahiya dîmenê dixwîne û di xalek diyar de rewşa xwe bilind dike.
Helwesta ku di dema çêkirina wêneyê de bû û mezinahiya binlogê dixwîne.
Dawiya binlogê dixwîne da ku rewşa heyî bigire û nivîsandina bûyerên din didomîne. Ev nexşeyek hêsan e; hemî motorên me li gorî wê dixebitin.
Replication Data
Wekî encamek, dubarekirina daneyan di me de li ser bingeha daxuyaniyê - em di binlogê de dinivîsin ne tu guhertinên rûpelan, lê bi navê daxwazên guhertin. Pir dişibihe ya ku li ser torê tê, tenê hinekî hatî guheztin.
Heman plan ne tenê ji bo dubarekirinê, lê di heman demê de jî tê bikar anîn ji bo afirandina hilanînê. Me motorek heye - mamosteyek nivîsandinê ku ji binlogê re dinivîse. Li her cîhek din ku rêvebiran ew saz kirine, ev binlog tê kopî kirin, û ew e - parêzek me heye.
Ger hewce be xwendina replicaJi bo kêmkirina barkirina xwendina CPU-yê, motora xwendinê bi hêsanî tê destpêkirin, ku dawiya binlogê dixwîne û van fermanan li herêmî pêk tîne.
Derengiya li vir pir hindik e, û meriv dikare fêr bibe ka kopya çiqas li paş masterê dimîne.
Parvekirina daneyê di proxy RPC de
Parvekirin çawa dixebite? Proxy çawa fam dike ku ji kîjan komê re bişîne? Kod nabêje: "Ji bo 15 perçeyan bişînin!" - Na, ev ji hêla proxy ve tê kirin.
Plana herî hêsan firstint e - hejmara yekem di daxwazê de.
get(photo100_500) => 100 % N.
Ev mînakek ji bo protokola nivîsê ya hêsan a memcached e, lê, bê guman, pirs dikarin tevlihev û sazkirî bin. Mînak di pirsê de jimareya yekem digire û dema ku bi mezinahiya komê ve tê dabeş kirin jimareya mayî digire.
Ev bikêr e dema ku em dixwazin xwedan cîhê daneya yek yekane bin. Ka em bibêjin 100 nasnameyek bikarhêner an komê ye, û em dixwazin ku hemî daneyên yek saziyek ji bo pirsên tevlihev li ser yek perçeyê bin.
Ger em bala xwe nedin ka daxwaz li ser komê çawa têne belav kirin, vebijarkek din heye - hejandina tevaya şûşê.
hash(photo100_500) => 3539886280 % N
Di heman demê de em haş, mayî ya dabeşkirinê û hêjmara şikestî jî digirin.
Van her du vebijarkan tenê dixebitin heke em ji vê rastiyê re amade bin ku gava em mezinahiya komê zêde bikin, em ê wê perçe bikin an çend caran zêde bikin. Mînakî, me 16 perçeyên me hebûn, têra me tune, em bêtir dixwazin - em dikarin bi ewlehî 32-ê bêyî demdirêjiyê bistînin. Ger em bixwazin ne pirjimar zêde bikin, dê demdirêj hebe, ji ber ku em ê nikaribin her tiştî bi awakî rast û bêyî windahiyan parçe bikin. Van vebijarkan bikêr in, lê ne her gav.
Ger hewce be ku em hejmareke keyfî pêşkêşkeran lê zêde bikin an jê bikin, em bikar tînin Haşkirina domdar li ser zengil a la Ketama. Lê di heman demê de, em bi tevahî cîhê daneyê winda dikin; pêdivî ye ku em daxwazê li komê bikin yek, da ku her perçeyek bersiva xweya piçûk vegerîne, û dûv re bersivên bi proxy re yek bikin.
Daxwazên super-taybet hene. Wusa dixuye: RPC proxy daxwazê distîne, diyar dike ku dê biçe kîjan komê û şiklê diyar dike. Dûv re an serwerên nivîsandinê hene, an jî, heke komê piştgirîya replikayê hebe, ew li gorî daxwazê ji kopiyek re dişîne. Proxy van hemûyan dike.
Logs
Em têketin bi çend awayan dinivîsin. Ya herî zelal û hêsan e têketinên memcache binivîse.
ring-buffer: prefix.idx = line
Pêşgirek sereke heye - navê têketinê, rêzek, û mezinahiya vê têketinê heye - hejmara rêzan. Em ji 0-ê heya hejmara rêzan ji 1-ê jimareyek tesadufî digirin. Mifteya memcache pêşgirek e ku bi vê jimareya random ve girêdayî ye. Em xeta têketinê û dema niha li nirxê hilînin.
Dema ku pêdivî bi xwendina tomaran hebe, em pêk tînin Multi Get hemî bişkok, li gorî demê têne rêz kirin, û bi vî rengî têketinek hilberînê di wextê rast de digirin. Pîlana dema ku hûn hewce ne ku tiştek di hilberînê de di wextê rast de xelet bikin, bêyî ku tiştek bişkînin, bêyî sekinandin an destûrdayîna seyrûsefera makîneyên din tê bikar anîn, lê ev têketin dirêj dirêj nake.
Ji bo hilanîna pêbawer a têketin motorek me heye têketin-motor. Bi rastî ji ber vê yekê ew hate afirandin û bi berfirehî di hejmareke mezin a koman de tê bikar anîn. Koma herî mezin a ku ez dizanim 600 TB têketinên pakkirî vedihewîne.
Motora pir kevn e, komikên ku jixwe 6-7 salî ne hene. Pirsgirêkên wê hene ku em hewl didin çareser bikin, mînakî, me dest bi karanîna çalak a ClickHouse kir da ku têketin hilînin.
Komkirina têketinên li ClickHouse
Ev diagram nîşan dide ku em çawa di motorên xwe de dimeşin.
Kodek heye ku bi navgîniya RPC-ê ve diçe RPC-proxy, û ew fêm dike ku meriv biçe motorê. Ger em bixwazin têketinên li ClickHouse binivîsin, divê em di vê nexşeyê de du beşan biguherînin:
- li şûna hin motor bi ClickHouse;
- proxy RPC, ku nikare xwe bigihîne ClickHouse, bi hin çareseriyên ku dikare, û bi riya RPC-ê veguherîne.
Motor hêsan e - em wê bi serverek an komek serverên bi ClickHouse re diguhezînin.
Û ku em biçin ClickHouse, me kir KittenHouse. Ger em rasterast ji KittenHouse biçin ClickHouse, ew ê bi ser nekeve. Tewra bêyî daxwazan, ew ji girêdanên HTTP yên hejmareke mezin a makîneyan zêde dike. Ji bo ku nexşe bixebite, li ser serverek bi ClickHouse proxeya berevajî ya herêmî tê rakirin, ku bi vî rengî hatî nivîsandin ku ew dikare li hember cildên pêwendiyê yên pêdivî bisekine. Di heman demê de ew dikare daneyên di hundurê xwe de bi rengek pêbawer tampon bike.
Carinan em naxwazin nexşeya RPC di çareseriyên ne-standard de bicîh bikin, mînakî, di nginx de. Ji ber vê yekê, KittenHouse xwedan şiyana wergirtina têketin bi navgîniya UDP ye.
Ger şander û wergirê têketin li ser heman makîneyê bixebitin, wê hingê îhtîmala windakirina pakêtek UDP di nav mêvandarê herêmî de pir kêm e. Wekî lihevkirinek di navbera hewcedariya pêkanîna RPC-ê di çareseriyek sêyemîn û pêbaweriyê de, em tenê şandina UDP bikar tînin. Em ê paşê vegerin ser vê planê.
Ingopandin
Du celeb têketinên me hene: yên ku ji hêla rêvebiran ve li ser serverên xwe têne berhev kirin û yên ku ji hêla pêşdebiran ve ji kodê têne nivîsandin. Ew bi du celeb pîvanan re têkildar in: sîstem û berhem.
Metrîkên pergalê
Ew li ser hemî serverên me dixebite , ku amaran berhev dike û dişîne Karbona Grafît. Ji ber vê yekê, ClickHouse wekî pergala hilanînê, û ne Whisper, mînakî tê bikar anîn. Ger hewce be, hûn dikarin rasterast ji ClickHouse bixwînin, an bikar bînin Grafana ji bo metrics, grafîk û raporên. Wekî pêşdebiran, me têra xwe gihîştina Netdata û Grafana heye.
Metrîkên hilberê
Ji bo rehetiyê me gelek tişt nivîsandine. Mînakî, komek fonksiyonên asayî hene ku dihêle hûn jimartin, nirxên UniqueCounts di statîstîkê de binivîsin, ku li cîhek din têne şandin.
statlogsCountEvent ( ‘stat_name’, $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid, $key1, $key2, …)
statlogsValuetEvent ( ‘stat_name’, $value, $key1, $key2, …)
$stats = statlogsStatData($params)
Dûv re, em dikarin fîlterên cûrbecûr û komkirinê bikar bînin û her tiştê ku em ji statîstîkê dixwazin bikin - grafikan çêbikin, Watchdogs mîheng bikin.
Em pir dinivîsin gelek metrîk hejmara bûyeran rojane ji 600 milyar heta 1 trîlyon e. Lêbelê, em dixwazin wan biparêzin herî kêm çend salji bo fêmkirina meylên metrîkan. Tevlihevkirina wan pirsgirêkek mezin e ku me hêj çareser nekiriye. Ez ê ji we re vebêjim ka ev çend salên dawî çawa dixebite.
Fonksiyonên me hene ku van metrîkan dinivîsin ji bo memcache herêmîji bo kêmkirina hejmara navnîşan. Carek di demek kurt de li herêmî hate destpêkirin stats-daemon hemû tomar berhev dike. Dûv re, cin metrîkan di du qatên pêşkêşkeran de dike yek têketin-berhevkar, ku statîstîkên ji komek makîneyên me berhev dike da ku qata li pişt wan nemire.
Ger hewce be, em dikarin rasterast ji têketin-berhevkeran re binivîsin.
Lê nivîsandina ji kodê rasterast ji berhevkeran re, derbaskirina stas-daemom, çareseriyek qelsbar e ji ber ku ew barê berhevkerê zêde dike. Çareserî guncav e heke ji ber hin sedeman em nikaribin stats-daemona memcache li ser makîneyê bilind bikin, an ew têk çû û em rasterast çûn.
Dûv re, têketin-berhevkar statîstîkan li hev dikin meowDB - ev databasa me ye, ku dikare metrîkan jî hilîne.
Wê hingê em dikarin ji kodê vebijarkên "nêzîkî SQL" yên binary bikin.
Experiment
Di havîna 2018-an de, me hackathonek navxweyî hebû, û fikir hat ku em hewl bidin ku beşa sor a diagramê bi tiştek ku bikaribe metrîkan li ClickHouse hilîne biguhezîne. Li ser ClickHouse têketinên me hene - çima wê biceribînin?
Me nexşeyek hebû ku têketin bi navgîniya KittenHouse ve dinivîsand.
Me biryar da "* Xanî" din li diagramê zêde bike, ku dê tam metrîkan di forma ku koda me wan bi UDP dinivîse werbigire. Dûv re ev * Xanî wan dizivirîne navdêran, mîna têketin, ku KittenHouse fêm dike. Ew dikare van têketinên bêkêmasî radestî ClickHouse bike, ku divê bikaribe wan bixwîne.
Plana bi databasa memcache, stats-daemon û logs-collectors bi vê yekê tê guheztin.
Plana bi databasa memcache, stats-daemon û logs-collectors bi vê yekê tê guheztin.
- Li vir şandinek ji kodê heye, ku di StatsHouse-ê de herêmî tête nivîsandin.
- StatsHouse metrîkên UDP-ê, ku berê di nav têlên SQL-ê de hatine veguheztin, di koman de li KittenHouse dinivîse.
- KittenHouse wan dişîne ClickHouse.
- Ger em dixwazin wan bixwînin, wê hingê em wan dixwînin StatsHouse - rasterast ji ClickHouse bi karanîna SQL-ya birêkûpêk.
Ma ew hê jî ezmûnek, lê em hez dikin ka ew çawa derdikeve. Ger em pirsgirêkên nexşeyê çareser bikin, wê hingê dibe ku em ê bi tevahî wê veguherînin. Bi xwe, ez hêvî dikim.
Scheme hesin xilas nake. Kêm pêşkêşker hewce ne, stats-daemon û têketin-berhevkerên herêmî ne hewce ne, lê ClickHouse serverek ji yên di pilana heyî de mezintir hewce dike. Kêm server hewce ne, lê divê ew bihatir û bihêztir bin.
Bikaranîn
Pêşîn, bila em li bicîhkirina PHP-ê binêrin. Em di nav de pêşve diçin git: bikaranîn GitLab и TeamCity ji bo belavkirinê. Şaxên pêşkeftinê di şaxê masterê de têne yek kirin, ji masterê ji bo ceribandinê ew di nav qonaxê de, û ji qonaxkirinê di hilberînê de têne yek kirin.
Berî bicîhkirinê, şaxê hilberîna heyî û ya berê têne girtin, û pelên cûda di wan de têne hesibandin - guhertin: afirandin, jêbirin, guherandin. Ev guhertin di binloga motorek kopîfastê ya taybetî de tête tomar kirin, ku dikare zû guhertinan li tevahiya fîloya servera me dubare bike. Ya ku li vir tê bikar anîn ne rasterast kopî ye, lê dubarekirina gossip, gava serverek guheztinan ji cîranên xwe yên herî nêzîk re, yên ji cîranên xwe re, û hwd dişîne. Ev dihêle hûn kodê bi dehan û yekîneyên saniyeyê li seranserê fîloya nûve bikin. Dema ku guherîn digihîje kopyaya herêmî, ew van pêçanan li ser xwe bicîh tîne pergala pelê herêmî. Rollback jî li gorî heman nexşeyê tête kirin.
Em kPHP-ê jî pir belav dikin û ew jî pêşkeftina xwe li ser heye git li gor diyagrama jorîn. Ji ber vê yekê Pêşkêşkara HTTP binary, wê hingê em nikarin cûdahiyê hilberînin - binariya berdanê bi sedan MB giran dike. Ji ber vê yekê, vebijarkek din li vir heye - guhertoya ku tê nivîsandin binlog copyfast. Bi her çêkirinê re ew zêde dibe, û di dema vegerandinê de jî zêde dibe. Awa ji pêşkêşkeran re dubare kirin. Kopîfastên herêmî dibînin ku guhertoyek nû ketiye binlogê, û bi heman dubarekirina gotegotan ew guhertoya herî dawî ya binaryê ji xwe re digirin, bêyî ku servera meya sereke westînin, lê bi baldarî barkirinê li seranserê torê belav dikin. Çi li pey jinûve destpêkirina xweş ji bo guhertoya nû.
Ji bo motorên me, ku di heman demê de bi bingehîn binar in, nexşe pir dişibin hev:
- git master branch;
- binary in .deb;
- versiyon ji bo binlog copyfast hatiye nivîsandin;
- ji pêşkêşkeran re dubare kirin;
- server .depek nû derdixe;
- dpkg -i;
- nûvekirina xweş a guhertoya nû.
Cûdahî ev e ku binarya me di arşîvan de hatî pak kirin .deb, û dema pompekirina wan dpkg -i li ser pergalê têne danîn. Çima kPHP wekî binaryek, û motor wekî dpkg têne bicîh kirin? Bi vî awayî çêbû. Ew dixebite - dest nede.
Zencîreyên bikêr:
- Rapor ji hêla Anton Kiryushkin bi hûrguliyên li ser copyfast û gotegotan.
- Rapora Yuri Nasretdinov .
- Rapora min , lê ji hêla pêşveçûnê ve, ne hardware.
Alexey Akulovich yek ji wan e ku, wekî beşek Komîteya Bernameyê, alîkariyê dike 17ê Gulanê dê ji bo pêşdebirên PHP-ê di van demên dawî de bibe mezintirîn bûyer. Binêrin çi PC-ya me ya xweş heye, çi (du ji wan bingeha PHP-ê pêşve dibin!) - wekî tiştek xuya dike ku hûn nikanin ji bîr nekin ger hûn PHP-ê binivîsin.
Source: www.habr.com