VKontakte izveides vÄsture ir atrodama VikipÄdijÄ, to stÄstÄ«ja pats PÄvels. Å Ä·iet, ka visi viÅu jau pazÄ«st. Par HighLoad++ Pavel vietnes iekÅ”Äjo elementu, arhitektÅ«ru un struktÅ«ru . KopÅ” tÄ laika ir noplÅ«duÅ”i daudzi serveri, tÄpÄc mÄs atjauninÄsim informÄciju: izgriezÄ«sim to, izÅemsim iekÅ”pusi, nosvÄrsim un apskatÄ«sim VK ierÄ«ci no tehniskÄ viedokļa.
Aleksejs AkuloviÄs () aizmugursistÄmas izstrÄdÄtÄjs VKontakte komandÄ. Å Ä« ziÅojuma atÅ”ifrÄjums ir kolektÄ«va atbilde uz bieži uzdotajiem jautÄjumiem par platformas darbÄ«bu, infrastruktÅ«ru, serveriem un mijiedarbÄ«bu starp tiem, bet ne par attÄ«stÄ«bu, proti, par dzelzi. AtseviŔķi par datu bÄzÄm un to, kas VK vietÄ ir, par žurnÄlu apkopoÅ”anu un visa projekta uzraudzÄ«bu kopumÄ. SÄ«kÄka informÄcija zem griezuma.
VairÄk nekÄ Äetrus gadus esmu nodarbojies ar visdažÄdÄkajiem uzdevumiem, kas saistÄ«ti ar backend.
- AugÅ”upielÄdÄt, uzglabÄt, apstrÄdÄt, izplatÄ«t medijus: video, tieÅ”raides, audio, fotogrÄfijas, dokumentus.
- InfrastruktÅ«ra, platforma, izstrÄdÄtÄju uzraudzÄ«ba, žurnÄli, reÄ£ionÄlÄs keÅ”atmiÅas, CDN, patentÄts RPC protokols.
- IntegrÄcija ar ÄrÄjiem pakalpojumiem: push paziÅojumi, ÄrÄjo saiÅ”u parsÄÅ”ana, RSS plÅ«sma.
- PalÄ«dzu kolÄÄ£iem ar dažÄdiem jautÄjumiem, uz kuriem atbildÄm ir jÄiedziļinÄs nezinÄmÄ kodÄ.
Å ajÄ laikÄ es iesaistÄ«jos daudzos vietnes komponentos. Gribu padalÄ«ties ar Å”o pieredzi.
VispÄrÄjÄ arhitektÅ«ra
Viss, kÄ parasti, sÄkas ar serveri vai serveru grupu, kas pieÅem pieprasÄ«jumus.
PriekÅ”Äjais serveris
PriekÅ”Äjais serveris pieÅem pieprasÄ«jumus, izmantojot HTTPS, RTMP un WSS.
HTTPS - tie ir pieprasÄ«jumi vietnes galvenajai un mobilajai tÄ«mekļa versijai: vk.com un m.vk.com, kÄ arÄ« citiem oficiÄlajiem un neoficiÄlajiem mÅ«su API klientiem: mobilajiem klientiem, kurjeriem. Mums ir pieÅemÅ”ana RTMP-Trafika tieÅ”raidÄm ar atseviŔķiem priekÅ”Äjiem serveriem un WSS- StraumÄÅ”anas API savienojumi.
HTTPS un WSS serveros ir vÄrts nginx. RTMP apraides gadÄ«jumÄ mÄs nesen pÄrgÄjÄm uz savu risinÄjumu kive, taÄu tas ir Ärpus ziÅojuma darbÄ«bas jomas. Lai nodroÅ”inÄtu kļūdu toleranci, Å”ie serveri reklamÄ kopÄ«gas IP adreses un darbojas grupÄs, lai, ja kÄdÄ no serveriem rodas problÄma, lietotÄju pieprasÄ«jumi nepazustu. HTTPS un WSS gadÄ«jumÄ Å”ie paÅ”i serveri Å”ifrÄ trafiku, lai paÅ”i uzÅemtos daļu CPU slodzes.
MÄs nerunÄsim tÄlÄk par WSS un RTMP, bet tikai par standarta HTTPS pieprasÄ«jumiem, kas parasti ir saistÄ«ti ar tÄ«mekļa projektu.
aizmugure
Aiz priekÅ”puses parasti ir aizmugures serveri. ViÅi apstrÄdÄ pieprasÄ«jumus, ko priekÅ”Äjais serveris saÅem no klientiem.
TÄ kPHP serveri, kurÄ darbojas HTTP dÄmons, jo HTTPS jau ir atÅ”ifrÄts. kPHP ir serveris, kas darbojas sagatavju modeļi: sÄk galveno procesu, virkni bÄrnu apstrÄdÄ, nodod viÅiem klausÄ«Å”anÄs ligzdas, un viÅi apstrÄdÄ viÅu pieprasÄ«jumus. Å ajÄ gadÄ«jumÄ procesi netiek restartÄti starp katru lietotÄja pieprasÄ«jumu, bet vienkÄrÅ”i atiestata to stÄvokli uz sÄkotnÄjo nulles vÄrtÄ«bas stÄvokli ā pieprasÄ«jums pÄc pieprasÄ«juma, nevis restartÄÅ”ana.
Slodzes sadalījums
Visas mÅ«su aizmugursistÄmas nav liels iekÄrtu kopums, kas var apstrÄdÄt jebkuru pieprasÄ«jumu. MÄs viÅus sadalÄ«tas atseviŔķÄs grupÄs: vispÄrÄ«gs, mobilais, api, video, inscenÄjums... ProblÄma atseviŔķÄs maŔīnu grupÄs neietekmÄs visas pÄrÄjÄs. Ja rodas problÄmas ar video, lietotÄjs, kurÅ” klausÄs mÅ«ziku, pat nezinÄs par problÄmÄm. Uz kuru aizmugursistÄmu nosÅ«tÄ«t pieprasÄ«jumu, nosaka nginx priekÅ”pusÄ atbilstoÅ”i konfigurÄcijai.
Metrikas vÄkÅ”ana un lÄ«dzsvaroÅ”ana
Lai saprastu, cik automaŔīnu mums ir jÄbÅ«t katrÄ grupÄ, mÄs nepaļaujieties uz QPS. AizmugursistÄmas ir dažÄdas, tÄm ir dažÄdi pieprasÄ«jumi, katram pieprasÄ«jumam ir atŔķirÄ«ga QPS aprÄÄ·inÄÅ”anas sarežģītÄ«ba. TÄpÄc mÄs mÄs darbojamies ar jÄdzienu slodze uz serveri kopumÄ - uz CPU un perf.
Mums ir tÅ«kstoÅ”iem Å”Ädu serveru. Katrs fiziskais serveris vada kPHP grupu, lai pÄrstrÄdÄtu visus kodolus (jo kPHP ir viens pavediens).
Satura serveris
CS vai satura serveris ir krÄtuve. CS ir serveris, kas glabÄ failus, kÄ arÄ« apstrÄdÄ augÅ”upielÄdÄtos failus un visa veida fona sinhronos uzdevumus, ko tam pieŔķir galvenÄ tÄ«mekļa saskarne.
Mums ir desmitiem tÅ«kstoÅ”u fizisku serveru, kas glabÄ failus. LietotÄjiem patÄ«k augÅ”upielÄdÄt failus, un mums patÄ«k tos uzglabÄt un koplietot. Daži no Å”iem serveriem ir slÄgti ar Ä«paÅ”iem pu/pp serveriem.
pu/pp
Ja VK atvÄrÄt tÄ«kla cilni, jÅ«s redzÄjÄt pu/pp.
Kas ir pu/pp? Ja mÄs aizveram vienu serveri pÄc otra, ir divas iespÄjas faila augÅ”upielÄdei un lejupielÄdei serverÄ«, kas tika aizvÄrts: tieÅ”i caur http://cs100500.userapi.com/path vai caur starpserveri SÄkot no http://pu.vk.com/c100500/path.
Pu ir fotoattÄlu augÅ”upielÄdes vÄsturiskais nosaukums, un pp ir fotoattÄlu starpniekserveris. Tas ir, viens serveris ir paredzÄts fotoattÄlu augÅ”upielÄdei, bet otrs - augÅ”upielÄdei. Tagad tiek ielÄdÄtas ne tikai fotogrÄfijas, bet arÄ« saglabÄts nosaukums.
Å ie serveri pÄrtraukt HTTPS sesijaslai noÅemtu procesora slodzi no krÄtuves. TurklÄt, tÄ kÄ lietotÄju faili tiek apstrÄdÄti Å”ajos serveros, jo mazÄk sensitÄ«va informÄcija tiek glabÄta Å”ajÄs iekÄrtÄs, jo labÄk. PiemÄram, HTTPS Å”ifrÄÅ”anas atslÄgas.
TÄ kÄ iekÄrtas ir slÄgtas ar citÄm mÅ«su maŔīnÄm, mÄs varam atļauties tÄm nepieŔķirt "baltos" ÄrÄjos IP, un dot "pelÄku". TÄdÄ veidÄ mÄs ietaupÄ«jÄm IP pÅ«lu un garantÄjÄm, ka maŔīnas aizsargÄs no ÄrÄjÄs piekļuves - vienkÄrÅ”i nav IP, lai tajÄ iekļūtu.
NoturÄ«ba, izmantojot koplietotus IP. AttiecÄ«bÄ uz kļūdu toleranci shÄma darbojas tÄpat - vairÄkiem fiziskajiem serveriem ir kopÄ«gs fiziskais IP, un tiem priekÅ”Ä esoÅ”Ä aparatÅ«ra izvÄlas, kur nosÅ«tÄ«t pieprasÄ«jumu. Par citÄm iespÄjÄm es runÄÅ”u vÄlÄk.
PretrunÄ«gi vÄrtÄtais ir tas, ka Å”ajÄ gadÄ«jumÄ klients saglabÄ mazÄk savienojumu. Ja vairÄkÄm maŔīnÄm ir viena un tÄ pati IP ā ar vienu un to paÅ”u resursdatoru: pu.vk.com vai pp.vk.com, klienta pÄrlÅ«kprogrammÄ ir ierobežots vienlaicÄ«gu pieprasÄ«jumu skaits vienam resursdatoram. Bet visuresoÅ”Ä HTTP/2 laikÄ uzskatu, ka tas vairs nav tik aktuÄli.
ShÄmas acÄ«mredzamais trÅ«kums ir tÄds, ka tas ir jÄdara sÅ«knÄjiet visu satiksmi, kas nonÄk krÄtuvÄ caur citu serveri. TÄ kÄ mÄs sÅ«knÄjam satiksmi caur maŔīnÄm, mÄs vÄl nevaram sÅ«knÄt smago satiksmi, piemÄram, video, izmantojot to paÅ”u shÄmu. MÄs to pÄrraidÄm tieÅ”i - atseviŔķs tieÅ”s savienojums atseviŔķÄm krÄtuvÄm Ä«paÅ”i video. MÄs pÄrsÅ«tÄm vieglÄku saturu, izmantojot starpniekserveri.
Pirms neilga laika mÄs saÅÄmÄm uzlabotu starpniekservera versiju. Tagad es jums pastÄstÄ«Å”u, kÄ tie atŔķiras no parastajiem un kÄpÄc tas ir nepiecieÅ”ams.
Saule
2017. gada septembrÄ« Oracle, kas iepriekÅ” bija iegÄdÄjies Sun, . Var teikt, ka uz Å”o brÄ«di uzÅÄmums beidza pastÄvÄt. IzvÄloties nosaukumu jaunajai sistÄmai, mÅ«su administratori nolÄma godinÄt Ŕī uzÅÄmuma piemiÅu un nosauca jauno sistÄmu Sun. MÄs savÄ starpÄ viÅu vienkÄrÅ”i saucam par "saulÄ«tÄm".
pp bija dažas problÄmas. Viena IP katrai grupai - neefektÄ«va keÅ”atmiÅa. VairÄkiem fiziskiem serveriem ir kopÄ«ga IP adrese, un nav iespÄjams kontrolÄt, uz kuru serveri tiks nosÅ«tÄ«ts pieprasÄ«jums. TÄpÄc, ja vienam un tam paÅ”am failam nÄk dažÄdi lietotÄji, tad, ja Å”ajos serveros ir keÅ”atmiÅa, fails nonÄk katra servera keÅ”atmiÅÄ. Å Ä« ir ļoti neefektÄ«va shÄma, taÄu neko nevarÄja darÄ«t.
SekojoÅ”i - mÄs nevaram sadalÄ«t saturu, jo Å”ai grupai nevaram izvÄlÄties konkrÄtu serveri ā tiem ir kopÄ«gs IP. ArÄ« dažu iekÅ”Äju iemeslu dÄļ mums ir reÄ£ionos nebija iespÄjams uzstÄdÄ«t Å”Ädus serverus. ViÅi stÄvÄja tikai SanktpÄterburgÄ.
Ar sauli mainÄ«jÄm atlases sistÄmu. Tagad mums ir Anycast marÅ”rutÄÅ”ana: dinamiskÄ marÅ”rutÄÅ”ana, Anycast, paÅ”pÄrbaudes dÄmons. Katram serverim ir savs individuÄlais IP, bet kopÄ«gs apakÅ”tÄ«kls. Viss ir konfigurÄts tÄ, ka, ja viens serveris neizdodas, trafiks automÄtiski tiek izplatÄ«ts pa citiem tÄs paÅ”as grupas serveriem. Tagad ir iespÄjams izvÄlÄties konkrÄtu serveri, nav liekas keÅ”atmiÅas, un uzticamÄ«ba netika ietekmÄta.
Svara atbalsts. Tagad varam atļauties uzstÄdÄ«t dažÄdas jaudas maŔīnas pÄc vajadzÄ«bas, kÄ arÄ« Ä«slaicÄ«gu problÄmu gadÄ«jumÄ mainÄ«t darba āsaulÄ«Å”uā svarus, lai samazinÄtu to slodzi, lai tÄs āatpÅ«stosā un atsÄktu strÄdÄt.
DalÄ«Å”ana pÄc satura ID. SmieklÄ«ga lieta par sadalÄ«Å”anu: mÄs parasti sadalÄm saturu, lai dažÄdi lietotÄji dotos uz vienu un to paÅ”u failu caur vienu un to paÅ”u "sauli", lai viÅiem bÅ«tu kopÄ«ga keÅ”atmiÅa.
MÄs nesen uzsÄkÄm lietojumprogrammu āÄboliÅÅ”ā. Å Ä« ir tieÅ”saistes viktorÄ«na tieÅ”raidÄ, kurÄ vadÄ«tÄjs uzdod jautÄjumus un lietotÄji atbild reÄllaikÄ, izvÄloties iespÄjas. Lietojumprogrammai ir tÄrzÄÅ”ana, kurÄ lietotÄji var tÄrzÄt. Var vienlaikus izveidot savienojumu ar apraidi vairÄk nekÄ 100 tÅ«kstoÅ”i cilvÄku. ViÅi visi raksta ziÅojumus, kas tiek nosÅ«tÄ«ti visiem dalÄ«bniekiem, un kopÄ ar ziÅojumu nÄk iemiesojums. Ja pÄc viena iemiesojuma vienÄ āsaulÄ«tÄā nÄk 100 tÅ«kstoÅ”i cilvÄku, tad tas dažkÄrt var aizripot aiz mÄkoÅa.
Lai izturÄtu viena un tÄ paÅ”a faila pieprasÄ«jumu pÄrrÄvumus, noteikta veida saturam mÄs ieslÄdzam stulbu shÄmu, kas izplata failus pa visÄm pieejamajÄm āsaulÄ«tÄmā reÄ£ionÄ.
Saule no iekŔpuses
Reversais starpniekserveris nginx, keÅ”atmiÅa vai nu RAM, vai Ätrajos Optane/NVMe diskos. PiemÄrs: http://sun4-2.userapi.com/c100500/path ā saite uz āsauliā, kas atrodas ceturtajÄ reÄ£ionÄ, otrajÄ serveru grupÄ. Tas aizver ceļa failu, kas fiziski atrodas serverÄ« 100500.
KeÅ”atmiÅa
MÄs savai arhitektÅ«ras shÄmai pievienojam vÄl vienu mezglu - keÅ”atmiÅas vidi.
ZemÄk ir izkÄrtojuma diagramma reÄ£ionÄlÄs keÅ”atmiÅas, tÄdu ir apmÄram 20. TÄs ir vietas, kur atrodas keÅ”atmiÅas un āsaulesā, kas var keÅ”atmiÅÄ saglabÄt trafiku caur sevi.
TÄ ir multivides satura saglabÄÅ”ana keÅ”atmiÅÄ; Å”eit netiek glabÄti nekÄdi lietotÄja dati ā tikai mÅ«zika, video, fotoattÄli.
Lai noteiktu lietotÄja reÄ£ionu, mÄs mÄs apkopojam reÄ£ionos izziÅotos BGP tÄ«kla prefiksus. AtkÄpÅ”anÄs gadÄ«jumÄ mums ir arÄ« jÄparsÄ geoip datubÄze, ja mÄs nevaram atrast IP pÄc prefiksiem. MÄs nosakÄm reÄ£ionu pÄc lietotÄja IP. KodÄ varam aplÅ«kot vienu vai vairÄkus lietotÄja reÄ£ionus ā tos punktus, kuriem viÅÅ” Ä£eogrÄfiski atrodas vistuvÄk.
KÄ tas strÄdÄ?
MÄs uzskaitÄm failu popularitÄti pÄc reÄ£iona. Ir vairÄkas reÄ£ionÄlÄs keÅ”atmiÅas, kurÄ atrodas lietotÄjs, un faila identifikators ā mÄs Åemam Å”o pÄri un paaugstinÄm vÄrtÄjumu ar katru lejupielÄdi.
TajÄ paÅ”Ä laikÄ dÄmoni - pakalpojumi reÄ£ionos - laiku pa laikam ierodas API un saka: āEs esmu tÄda un tÄda keÅ”atmiÅa, iedodiet man sarakstu ar populÄrÄkajiem failiem manÄ reÄ£ionÄ, kas vÄl nav manÄ rÄ«cÄ«bÄ. ā API nodroÅ”ina virkni failu, kas sakÄrtoti pÄc vÄrtÄjuma, dÄmons tos lejupielÄdÄ, aizved uz reÄ£ioniem un piegÄdÄ failus no turienes. Å Ä« ir bÅ«tiskÄ atŔķirÄ«ba starp pu/pp un Sun no keÅ”atmiÅÄm: viÅi nekavÄjoties nodod failu caur sevi, pat ja Ŕī faila nav keÅ”atmiÅÄ, un keÅ”atmiÅa vispirms lejupielÄdÄ failu sev un pÄc tam sÄk to atdot.
Å ajÄ gadÄ«jumÄ mÄs saÅemam saturam tuvÄk lietotÄjiem un tÄ«kla slodzes izkliedÄÅ”ana. PiemÄram, tikai no Maskavas keÅ”atmiÅas mÄs pÄ«Ä·a stundÄs izplatÄm vairÄk nekÄ 1 Tbit/s.
Bet ir problÄmas - keÅ”atmiÅas serveri nav gumijas. ÄŖpaÅ”i populÄram saturam dažkÄrt nepietiek tÄ«kla atseviŔķam serverim. MÅ«su keÅ”atmiÅas serveri ir 40-50 Gbit/s, bet ir saturs, kas pilnÄ«bÄ aizsprosto Å”Ädu kanÄlu. MÄs virzÄmies uz vairÄk nekÄ vienas populÄru failu kopiju glabÄÅ”anas ievieÅ”anu reÄ£ionÄ. Ceru, ka lÄ«dz gada beigÄm to Ä«stenosim.
MÄs apskatÄ«jÄm vispÄrÄjo arhitektÅ«ru.
- PriekÅ”Äjie serveri, kas pieÅem pieprasÄ«jumus.
- AizmugursistÄmas, kas apstrÄdÄ pieprasÄ«jumus.
- KrÄtuves, kuras aizver divu veidu starpniekserveri.
- ReÄ£ionÄlÄs keÅ”atmiÅas.
Kas trÅ«kst Å”ajÄ diagrammÄ? Protams, datu bÄzes, kurÄs mÄs glabÄjam datus.
Datu bÄzes vai dzinÄji
MÄs tos saucam nevis par datubÄzÄm, bet gan par dzinÄjiem - DzinÄjiem, jo āāmums praktiski nav datubÄzu vispÄrpieÅemtÄ izpratnÄ.
Tas ir nepiecieÅ”ams pasÄkums. Tas notika tÄpÄc, ka 2008.ā2009. gadÄ, kad VK popularitÄte strauji pieauga, projekts pilnÄ«bÄ darbojÄs uz MySQL un Memcache, un radÄs problÄmas. MySQL patika avarÄt un bojÄt failus, pÄc tam tas vairs neatkopÄs, un Memcache veiktspÄja pakÄpeniski pasliktinÄjÄs, un tÄ bija jÄrestartÄ.
IzrÄdÄs, ka arvien populÄrÄkajam projektam bija pastÄvÄ«ga krÄtuve, kas sabojÄ datus, un keÅ”atmiÅa, kas palÄninÄs. Å Ädos apstÄkļos ir grÅ«ti izstrÄdÄt augoÅ”u projektu. Tika nolemts mÄÄ£inÄt pÄrrakstÄ«t kritiskÄs lietas, uz kurÄm projekts bija vÄrsts uz mÅ«su paÅ”u velosipÄdiem.
RisinÄjums bija veiksmÄ«gs. Bija iespÄja to izdarÄ«t, kÄ arÄ« ÄrkÄrtÄja nepiecieÅ”amÄ«ba, jo citi mÄrogoÅ”anas veidi tajÄ laikÄ nepastÄvÄja. Nebija daudz datu bÄzu, NoSQL vÄl neeksistÄja, bija tikai MySQL, Memcache, PostrgreSQL - un viss.
UniversÄla darbÄ«ba. IzstrÄdi vadÄ«ja mÅ«su C izstrÄdÄtÄju komanda, un viss tika darÄ«ts konsekventi. NeatkarÄ«gi no dzinÄja tiem visiem bija aptuveni vienÄds faila formÄts, kas tika ierakstÄ«ts diskÄ, vienÄdi palaiÅ”anas parametri, vienÄdi apstrÄdÄti signÄli un aptuveni vienÄdi izturÄjÄs malu situÄciju un problÄmu gadÄ«jumÄ. Pieaugot dzinÄjiem, administratoriem ir Ärti darboties ar sistÄmu - nav zoodÄrza, kas bÅ«tu jÄuztur, un viÅiem ir no jauna jÄmÄcÄs darboties ar katru jaunu treÅ”o personu datu bÄzi, kas ļÄva Ätri un Ärti palielinÄt to numurs.
DzinÄju veidi
Komanda uzrakstÄ«ja diezgan daudz dzinÄju. Å eit ir tikai daži no tiem: draugs, padomi, attÄls, ipdb, burti, saraksti, žurnÄli, atmiÅa, meowdb, ziÅas, nostradamus, fotoattÄls, atskaÅoÅ”anas saraksti, pmemcached, smilÅ”kaste, meklÄÅ”ana, krÄtuve, atzÄ«mes PatÄ«k, uzdevumi,ā¦
Katram uzdevumam, kam nepiecieÅ”ama noteikta datu struktÅ«ra vai kas apstrÄdÄ netipiskus pieprasÄ«jumus, C komanda raksta jaunu dzinÄju. KÄpÄc ne.
Mums ir atseviŔķs dzinÄjs memcached, kas ir lÄ«dzÄ«gs parastajam, bet ar gardumu gÅ«zmu un kas nemazina Ätrumu. Nav ClickHouse, bet tas arÄ« darbojas. Pieejams atseviŔķi pmemcached -Å o neatlaidÄ«gi iespiests atmiÅÄ, kas var arÄ« glabÄt datus diskÄ, turklÄt nekÄ iekļaujas RAM, lai restartÄjot nezaudÄtu datus. AtseviŔķu uzdevumu veikÅ”anai ir dažÄdi dzinÄji: rindas, saraksti, komplekti - viss, kas nepiecieÅ”ams mÅ«su projektam.
Kopas
No koda viedokļa nav vajadzÄ«bas uzskatÄ«t dzinÄjus vai datu bÄzes kÄ procesus, entÄ«tijas vai gadÄ«jumus. Kods darbojas Ä«paÅ”i ar klasteriem, ar dzinÄju grupÄm - viens tips katrÄ klasterÄ«. PieÅemsim, ka ir keÅ”atmiÅÄ saglabÄts klasteris ā tÄ ir tikai maŔīnu grupa.
Kodam vispÄr nav jÄzina serveru fiziskÄ atraÅ”anÄs vieta, izmÄrs vai skaits. ViÅÅ” dodas uz kopu, izmantojot noteiktu identifikatoru.
Lai tas darbotos, jums jÄpievieno vÄl viena entÄ«tija, kas atrodas starp kodu un dzinÄjiem - pilnvara.
RPC starpniekserveris
Starpniekserveris savienojoÅ”ais autobuss, kurÄ darbojas gandrÄ«z visa vietne. TajÄ paÅ”Ä laikÄ mums ir nav pakalpojuma atklÄÅ”anas ā tÄ vietÄ Å”im starpniekserveram ir konfigurÄcija, kas zina visu klasteru un visu Ŕī klastera fragmentu atraÅ”anÄs vietu. LÅ«k, ko dara administratori.
ProgrammÄtÄjiem ir pilnÄ«gi vienalga, cik, kur un ko tas maksÄ - viÅi vienkÄrÅ”i dodas uz kopu. Tas mums ļauj daudz. SaÅemot pieprasÄ«jumu, starpniekserveris pÄradresÄ pieprasÄ«jumu, zinot, kur - tas pats to nosaka.
Å ajÄ gadÄ«jumÄ starpniekserveris ir aizsardzÄ«bas punkts pret pakalpojuma kļūmi. Ja kÄds dzinÄjs palÄninÄs vai avarÄ, starpniekserveris to saprot un attiecÄ«gi reaÄ£Ä uz klienta pusi. Tas ļauj noÅemt taimautu - kods negaida dzinÄja reakciju, bet saprot, ka tas nedarbojas un ir jÄrÄ«kojas kaut kÄ savÄdÄk. Kods ir jÄsagatavo tam, ka datu bÄzes ne vienmÄr strÄdÄ.
KonkrÄtas ievieÅ”anas
Dažreiz mÄs joprojÄm ļoti vÄlamies, lai kÄ dzinÄjs bÅ«tu kÄds nestandarta risinÄjums. TajÄ paÅ”Ä laikÄ tika nolemts neizmantot mÅ«su gatavo rpc-proxy, kas tika izveidots Ä«paÅ”i mÅ«su dzinÄjiem, bet gan uzdevumam izveidot atseviŔķu starpniekserveri.
MySQL, kas mums joprojÄm ir Å”eit un tur, mÄs izmantojam db-proxy, un ClickHouse - KaÄ·Änu mÄja.
KopumÄ tas darbojas Å”Ädi. Ir noteikts serveris, tajÄ darbojas kPHP, Go, Python - vispÄr jebkurÅ” kods, kas var izmantot mÅ«su RPC protokolu. Kods darbojas lokÄli uz RPC starpniekservera ā katrs serveris, kurÄ atrodas kods, palaiž savu lokÄlo starpniekserveri. PÄc pieprasÄ«juma pilnvarnieks saprot, kur doties.
Ja viens dzinÄjs vÄlas pÄriet uz citu, pat ja tas ir kaimiÅÅ”, tas iet caur starpniekserveri, jo kaimiÅÅ” var bÅ«t citÄ datu centrÄ. DzinÄjam nevajadzÄtu paļauties uz to, ka zina nekam citam, izÅemot sevi ā tas ir mÅ«su standarta risinÄjums. Bet protams ir izÅÄmumi :)
TL shÄmas piemÄrs, saskaÅÄ ar kuru darbojas visi dzinÄji.
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 ir binÄrais protokols, kura tuvÄkais analogs ir protobuf. ShÄmÄ ir noteikti izvÄles lauki, sarežģīti veidi - iebÅ«vÄto skalÄru paplaÅ”inÄjumi un vaicÄjumi. Viss darbojas saskaÅÄ ar Å”o protokolu.
RPC, izmantojot TL, izmantojot TCP/UDPā¦ UDP?
Mums ir RPC protokols dzinÄju pieprasÄ«jumu izpildei, kas darbojas papildus TL shÄmai. Tas viss darbojas, izmantojot TCP/UDP savienojumu. TCP ir saprotams, bet kÄpÄc mums bieži ir vajadzÄ«gs UDP?
UDP palÄ«dz izvairieties no liela skaita savienojumu starp serveriem problÄmas. Ja katram serverim ir RPC starpniekserveris un kopumÄ tas var pÄriet uz jebkuru dzinÄju, tad vienam serverim ir desmitiem tÅ«kstoÅ”u TCP savienojumu. Slodze ir, bet nekam neder. UDP gadÄ«jumÄ Å”Ä« problÄma nepastÄv.
Nav lieka TCP rokasspiediena. TÄ ir tipiska problÄma: kad tiek palaists jauns dzinÄjs vai jauns serveris, vienlaikus tiek izveidoti daudzi TCP savienojumi. Nelieliem, viegliem pieprasÄ«jumiem, piemÄram, UDP kravnesÄ«ba, visa saziÅa starp kodu un dzinÄju tiek veikta divas UDP paketes: viens lido vienÄ virzienÄ, otrs otrÄ. Viens brauciens turp un atpakaļ - un kods saÅÄma atbildi no dzinÄja bez rokasspiediena.
JÄ, tas viss vienkÄrÅ”i darbojas ar ļoti nelielu pakeÅ”u zuduma procentu. Protokolam ir atbalsts atkÄrtotÄm pÄrraidÄm un taimautiem, bet, ja mÄs zaudÄsim daudz, mÄs iegÅ«sim gandrÄ«z TCP, kas nav izdevÄ«gi. MÄs nebraucam ar UDP pÄri okeÄniem.
Mums ir tÅ«kstoÅ”iem Å”Ädu serveru, un shÄma ir tÄda pati: katrÄ fiziskajÄ serverÄ« ir instalÄta dzinÄju pakotne. Tie lielÄkoties ir ar vienu pavedienu, lai tie darbotos pÄc iespÄjas ÄtrÄk bez bloÄ·ÄÅ”anas, un tie ir sadalÄ«ti kÄ viena vÄ«tnes risinÄjumi. TajÄ paÅ”Ä laikÄ mums nav nekÄ uzticamÄka par Å”iem dzinÄjiem, un liela uzmanÄ«ba tiek pievÄrsta pastÄvÄ«gai datu glabÄÅ”anai.
PastÄvÄ«ga datu glabÄÅ”ana
DzinÄji raksta binlogus. Binlog ir fails, kura beigÄs tiek pievienots notikums par stÄvokļa vai datu izmaiÅÄm. DažÄdos risinÄjumos to sauc atŔķirÄ«gi: binÄrs žurnÄls, , , bet princips ir tÄds pats.
Lai, restartÄjot, dzinÄjs daudzus gadus neizlasÄ«tu visu binlog, dzinÄji raksta momentuzÅÄmumi ā paÅ”reizÄjais stÄvoklis. Ja nepiecieÅ”ams, viÅi vispirms izlasa no tÄ un pÄc tam pabeidz lasÄ«t no binlog. Visi binÄrlogi tiek rakstÄ«ti vienÄ binÄrajÄ formÄtÄ ā pÄc TL shÄmas, lai administratori varÄtu tos administrÄt vienÄdi ar saviem rÄ«kiem. Nav tÄdas vajadzÄ«bas pÄc momentuzÅÄmumiem. Ir vispÄrÄ«ga galvene, kas norÄda, kura momentuzÅÄmums ir int, dzinÄja maÄ£ija un kurÅ” korpuss nevienam nav svarÄ«gs. TÄ ir problÄma ar dzinÄju, kas ierakstÄ«ja momentuzÅÄmumu.
Es Ätri aprakstÄ«Å”u darbÄ«bas principu. Ir serveris, uz kura darbojas dzinÄjs. ViÅÅ” atver jaunu tukÅ”u binlogu rakstÄ«Å”anai un ieraksta notikumu, lai to mainÄ«tu.
KÄdÄ brÄ«dÄ« viÅÅ” vai nu nolemj pats uzÅemt momentuzÅÄmumu, vai arÄ« saÅem signÄlu. Serveris izveido jaunu failu, ieraksta tajÄ visu tÄ stÄvokli, faila beigÄm pievieno paÅ”reizÄjo binlog lielumu - nobÄ«di - un turpina rakstÄ«t tÄlÄk. Jauns binlog netiek izveidots.
KÄdÄ brÄ«dÄ«, kad dzinÄjs tiks restartÄts, diskÄ bÅ«s gan binlog, gan momentuzÅÄmums. DzinÄjs nolasa visu momentuzÅÄmumu un noteiktÄ brÄ«dÄ« paaugstina tÄ stÄvokli.
Nolasa pozÄ«ciju, kas bija momentuzÅÄmuma izveides laikÄ, un binlog lielumu.
Nolasa binlog beigas, lai iegÅ«tu paÅ”reizÄjo stÄvokli, un turpina rakstÄ«t turpmÄkos notikumus. Å Ä« ir vienkÄrÅ”a shÄma; visi mÅ«su dzinÄji darbojas saskaÅÄ ar to.
Datu replikÄcija
TÄ rezultÄtÄ datu replikÄcija mÅ«su pamatojoties uz apgalvojumu ā binlogÄ rakstÄm nevis kÄdas lapas izmaiÅas, bet proti izmaiÅu pieprasÄ«jumi. Ä»oti lÄ«dzÄ«gs tam, kas tiek piegÄdÄts tÄ«klÄ, tikai nedaudz pÄrveidots.
To paÅ”u shÄmu izmanto ne tikai replikÄcijai, bet arÄ« lai izveidotu dublÄjumus. Mums ir dzinÄjs ā rakstÄ«Å”anas meistars, kas raksta uz binlog. JebkurÄ citÄ vietÄ, kur administratori to ir iestatÄ«juÅ”i, Å”is binlog tiek kopÄts, un viss ā mums ir rezerves kopija.
Ja nepiecieÅ”ams lasÄ«Å”anas replikaLai samazinÄtu CPU lasÄ«Å”anas slodzi, vienkÄrÅ”i tiek palaists lasÄ«Å”anas dzinÄjs, kas nolasa binlog beigas un izpilda Ŕīs komandas lokÄli.
AtpalicÄ«ba Å”eit ir ļoti maza, un ir iespÄjams noskaidrot, cik daudz replika atpaliek no meistara.
Datu sadalīŔana RPC starpniekserverī
KÄ darbojas sadalÄ«Å”ana? KÄ starpniekserveris saprot, uz kuru klastera fragmentu nosÅ«tÄ«t? KodÄ nav teikts: "SÅ«tiet par 15 lauskas!" - nÄ, to dara pilnvarnieks.
VienkÄrÅ”ÄkÄ shÄma ir firstint ā pieprasÄ«juma pirmais numurs.
get(photo100_500) => 100 % N.
Å is ir vienkÄrÅ”a memcached teksta protokola piemÄrs, taÄu, protams, vaicÄjumi var bÅ«t sarežģīti un strukturÄti. PiemÄrÄ tiek Åemts pirmais skaitlis vaicÄjumÄ un atlikuÅ”ais skaitlis, dalÄ«ts ar klastera lielumu.
Tas ir noderÄ«gi, ja vÄlamies iegÅ«t vienas entÄ«tijas datu atraÅ”anÄs vietu. PieÅemsim, ka 100 ir lietotÄja vai grupas ID, un mÄs vÄlamies, lai sarežģītiem vaicÄjumiem visi vienas entÄ«tijas dati bÅ«tu vienÄ fragmentÄ.
Ja mums ir vienalga, kÄ pieprasÄ«jumi tiek izplatÄ«ti klasterÄ«, ir vÄl viena iespÄja ā sajaucot visu shardu.
hash(photo100_500) => 3539886280 % N
MÄs arÄ« iegÅ«stam hash, dalÄ«juma atlikumu un shard numuru.
Abas Ŕīs iespÄjas darbojas tikai tad, ja esam gatavi tam, ka, palielinot klastera lielumu, mÄs to sadalÄ«sim vai palielinÄsim vairÄkas reizes. PiemÄram, mums bija 16 lauskas, mums nepietiek, mÄs vÄlamies vairÄk - mÄs varam droÅ”i iegÅ«t 32 bez dÄ«kstÄves. Ja gribam palielinÄt, nevis reizinÄt, bÅ«s dÄ«kstÄves, jo nevarÄsim visu precÄ«zi sadalÄ«t bez zaudÄjumiem. Å Ä«s iespÄjas ir noderÄ«gas, bet ne vienmÄr.
Ja mums ir jÄpievieno vai jÄnoÅem patvaļīgs skaits serveru, mÄs to izmantojam Konsekventa jaukÅ”ana uz gredzena a la Ketama. Bet tajÄ paÅ”Ä laikÄ mÄs pilnÄ«bÄ zaudÄjam datu atraÅ”anÄs vietu; mums ir jÄapvieno pieprasÄ«jums ar klasteru, lai katrs elements atgrieztu savu mazo atbildi, un pÄc tam jÄapvieno atbildes ar starpniekserveri.
Ir Ä«paÅ”i specifiski pieprasÄ«jumi. Tas izskatÄs Å”Ädi: RPC starpniekserveris saÅem pieprasÄ«jumu, nosaka, uz kuru klasteru doties, un nosaka fragmentu. PÄc tam ir vai nu rakstÄ«Å”anas meistari, vai arÄ«, ja klasterim ir reprodukcijas atbalsts, tas pÄc pieprasÄ«juma nosÅ«ta uz repliku. To visu dara starpniekserveris.
Baļķi
MÄs rakstÄm žurnÄlus vairÄkos veidos. VisredzamÄkais un vienkÄrÅ”Äkais ir rakstÄ«t žurnÄlus memcache.
ring-buffer: prefix.idx = line
Ir atslÄgas prefikss - žurnÄla nosaukums, lÄ«nija, un ir Ŕī žurnÄla izmÄrs - rindu skaits. MÄs Åemam nejauÅ”u skaitli no 0 lÄ«dz rindu skaitam mÄ«nus 1. Memcache atslÄga ir prefikss, kas savienots ar Å”o nejauÅ”o skaitli. MÄs saglabÄjam žurnÄla lÄ«niju un paÅ”reizÄjo laiku lÄ«dz vÄrtÄ«bai.
Kad nepiecieÅ”ams nolasÄ«t žurnÄlus, veicam Multi Get visas atslÄgas, sakÄrtotas pÄc laika, un tÄdÄjÄdi iegÅ«stiet ražoÅ”anas žurnÄlu reÄllaikÄ. ShÄma tiek izmantota, ja ir nepiecieÅ”ams kaut ko atkļūdot ražoÅ”anÄ reÄllaikÄ, neko nesalaužot, neapstÄjoties un neļaujot satiksmi uz citÄm maŔīnÄm, taÄu Å”is žurnÄls neturpinÄs ilgi.
DroÅ”ai baļķu uzglabÄÅ”anai mums ir dzinÄjs baļķu dzinÄjs. TieÅ”i tÄpÄc tas tika izveidots un tiek plaÅ”i izmantots daudzos klasteros. LielÄkajÄ man zinÄmajÄ klasterÄ« ir 600 TB iesaiÅotu baļķu.
DzinÄjs ļoti vecs, ir klasteri, kuriem jau ir 6-7 gadi. Ar to ir problÄmas, kuras mÄs cenÅ”amies atrisinÄt, piemÄram, mÄs sÄkÄm aktÄ«vi izmantot ClickHouse žurnÄlu glabÄÅ”anai.
ŽurnÄlu vÄkÅ”ana pakalpojumÄ ClickHouse
Å Ä« diagramma parÄda, kÄ mÄs ieejam mÅ«su dzinÄjos.
Ir kods, kas lokÄli, izmantojot RPC, tiek nosÅ«tÄ«ts uz RPC starpniekserveri, un tas saprot, kur doties uz dzinÄju. Ja mÄs vÄlamies rakstÄ«t žurnÄlus ClickHouse, mums Å”ajÄ shÄmÄ ir jÄmaina divas daļas:
- aizstÄt kÄdu dzinÄju ar ClickHouse;
- aizstÄt RPC starpniekserveri, kas nevar piekļūt ClickHouse, ar kÄdu risinÄjumu, kas var, un izmantojot RPC.
DzinÄjs ir vienkÄrÅ”s ā mÄs to aizstÄjam ar serveri vai serveru kopu ar ClickHouse.
Un, lai dotos uz ClickHouse, mÄs to darÄ«jÄm KaÄ·Änu mÄja. Ja mÄs pÄrejam tieÅ”i no KittenHouse uz ClickHouse, tas netiks galÄ. Pat bez pieprasÄ«jumiem tas veidojas no ļoti daudzu iekÄrtu HTTP savienojumiem. Lai shÄma darbotos, serverÄ« ar ClickHouse tiek paaugstinÄts vietÄjais apgrieztais starpniekserveris, kas ir uzrakstÄ«ts tÄ, lai tas varÄtu izturÄt nepiecieÅ”amos savienojumu apjomus. Tas var arÄ« samÄrÄ uzticami buferÄt datus sevÄ«.
Dažreiz mÄs nevÄlamies ieviest RPC shÄmu nestandarta risinÄjumos, piemÄram, nginx. TÄpÄc KittenHouse ir iespÄja saÅemt žurnÄlus, izmantojot UDP.
Ja žurnÄlu sÅ«tÄ«tÄjs un saÅÄmÄjs strÄdÄ vienÄ maŔīnÄ, UDP paketes pazaudÄÅ”anas iespÄjamÄ«ba vietÄjÄ resursdatorÄ ir diezgan zema. KÄ kompromisu starp nepiecieÅ”amÄ«bu ieviest RPC treÅ”Äs puses risinÄjumÄ un uzticamÄ«bu mÄs vienkÄrÅ”i izmantojam UDP sÅ«tÄ«Å”anu. MÄs atgriezÄ«simies pie Ŕīs shÄmas vÄlÄk.
Uzraudzība
Mums ir divu veidu žurnÄli: tie, ko administratori savÄkuÅ”i savos serveros, un tie, kurus izstrÄdÄtÄji rakstÄ«juÅ”i no koda. Tie atbilst divu veidu rÄdÄ«tÄjiem: sistÄma un produkts.
SistÄmas rÄdÄ«tÄji
Tas darbojas visos mÅ«su serveros , kas apkopo statistiku un nosÅ«ta to uz GrafÄ«ta ogleklis. TÄpÄc ClickHouse tiek izmantota kÄ uzglabÄÅ”anas sistÄma, nevis, piemÄram, Whisper. Ja nepiecieÅ”ams, varat lasÄ«t tieÅ”i no ClickHouse vai izmantot grafana metrikai, grafikiem un pÄrskatiem. KÄ izstrÄdÄtÄjiem mums ir pietiekami daudz piekļuves Netdata un Grafana.
Produktu rÄdÄ«tÄji
ÄrtÄ«bas labad mÄs esam uzrakstÄ«juÅ”i daudzas lietas. PiemÄram, ir parasto funkciju kopums, kas ļauj statistikÄ ierakstÄ«t Counts, UniqueCounts vÄrtÄ«bas, kuras tiek nosÅ«tÄ«tas kaut kur tÄlÄk.
statlogsCountEvent ( āstat_nameā, $key1, $key2, ā¦)
statlogsUniqueCount ( āstat_nameā, $uid, $key1, $key2, ā¦)
statlogsValuetEvent ( āstat_nameā, $value, $key1, $key2, ā¦)
$stats = statlogsStatData($params)
PÄc tam mÄs varam izmantot kÄrtoÅ”anas un grupÄÅ”anas filtrus un darÄ«t visu, ko vÄlamies no statistikas ā veidot grafikus, konfigurÄt Watchdogs.
MÄs rakstÄm ļoti daudzi rÄdÄ«tÄji notikumu skaits ir no 600 miljardiem lÄ«dz 1 triljonam dienÄ. TomÄr mÄs vÄlamies tos saglabÄt vismaz pÄris gaduslai izprastu metrikas tendences. To visu salikt kopÄ ir liela problÄma, kuru mÄs vÄl neesam atrisinÄjuÅ”i. Es jums pastÄstÄ«Å”u, kÄ tas ir strÄdÄjis pÄdÄjos gadus.
Mums ir funkcijas, kas raksta Å”os rÄdÄ«tÄjus uz vietÄjo atmiÅu keÅ”atmiÅulai samazinÄtu ierakstu skaitu. Reizi Ä«sÄ laika periodÄ palaists lokÄli statistikas dÄmons apkopo visus ierakstus. PÄc tam dÄmons apvieno metriku divos serveru slÄÅos baļķu savÄcÄji, kas apkopo statistiku no vairÄkÄm mÅ«su maŔīnÄm, lai slÄnis aiz tiem nenomirst.
Ja nepiecieÅ”ams, varam rakstÄ«t tieÅ”i baļķiem-kolekcionÄriem.
Bet rakstÄ«Å”ana no koda tieÅ”i uz kolekcionÄriem, apejot stas-daemom, ir slikti mÄrogojams risinÄjums, jo tas palielina kolektora slodzi. RisinÄjums ir piemÄrots tikai tad, ja kÄda iemesla dÄļ mÄs nevaram pacelt memcache stats-daemon uz maŔīnas, vai arÄ« tÄ avarÄja un mÄs devÄmies tieÅ”i.
PÄc tam žurnÄlu savÄcÄji apvieno statistiku meowDB - Ŕī ir mÅ«su datu bÄze, kurÄ var saglabÄt arÄ« metriku.
PÄc tam mÄs varam veikt binÄras āgandrÄ«z SQLā atlases no koda.
Eksperiments
2018. gada vasarÄ mums bija iekÅ”Äjs hakatons, un radÄs ideja mÄÄ£inÄt aizstÄt diagrammas sarkano daļu ar kaut ko tÄdu, kas varÄtu glabÄt rÄdÄ«tÄjus pakalpojumÄ ClickHouse. Mums ir žurnÄli vietnÄ ClickHouse ā kÄpÄc gan neizmÄÄ£inÄt?
Mums bija shÄma, kas ierakstÄ«ja žurnÄlus caur KittenHouse.
MÄs izlÄmÄm pievienojiet diagrammai vÄl vienu ā*MÄjaā., kas saÅems tieÅ”i metriku tÄdÄ formÄtÄ, kÄdÄ mÅ«su kods tos ieraksta, izmantojot UDP. Tad Ŕī *MÄja tos pÄrvÄrÅ” ieliktÅos, piemÄram, baļķos, kurus KittenHouse saprot. ViÅÅ” var lieliski piegÄdÄt Å”os žurnÄlus ClickHouse, kam vajadzÄtu bÅ«t iespÄjai tos nolasÄ«t.
ShÄma ar memcache, stats-daemon un logs-collectors datu bÄzi tiek aizstÄta ar Å”o.
ShÄma ar memcache, stats-daemon un logs-collectors datu bÄzi tiek aizstÄta ar Å”o.
- Å eit ir nosÅ«tÄ«Å”ana no koda, kas ir rakstÄ«ts lokÄli StatsHouse.
- StatsHouse ieraksta UDP metriku, kas jau ir pÄrveidota par SQL ieliktÅiem, KittenHouse partijÄs.
- KittenHouse tos nosūta ClickHouse.
- Ja mÄs vÄlamies tos lasÄ«t, mÄs tos lasÄm, apejot StatsHouse - tieÅ”i no ClickHouse, izmantojot parasto SQL.
Vai tas joprojÄm ir eksperiments, bet mums patÄ«k, kÄ tas izrÄdÄs. Ja mÄs novÄrsÄ«sim problÄmas ar shÄmu, tad, iespÄjams, pÄriesim uz to pilnÄ«bÄ. PersonÄ«gi es tÄ ceru.
ShÄma netaupa dzelzi. NepiecieÅ”ams mazÄk serveru, nav nepiecieÅ”ami lokÄlie statistikas dÄmoni un žurnÄlu savÄcÄji, bet ClickHouse nepiecieÅ”ams lielÄks serveris nekÄ paÅ”reizÄjÄ shÄmÄ. NepiecieÅ”ams mazÄk serveru, taÄu tiem jÄbÅ«t dÄrgÄkiem un jaudÄ«gÄkiem.
Izvietot
Vispirms apskatÄ«sim PHP izvietoÅ”anu. MÄs attÄ«stÄmies iekÅ”Ä iet: izmantot GitLab Šø TeamCity izvietoÅ”anai. IzstrÄdes filiÄles tiek apvienotas galvenajÄ filiÄlÄ, no galvenÄ testÄÅ”anai tÄs tiek apvienotas inscenÄÅ”anÄ, bet no inscenÄÅ”anas - ražoÅ”anÄ.
Pirms izvietoÅ”anas tiek Åemta paÅ”reizÄjÄ ražoÅ”anas filiÄle un iepriekÅ”ÄjÄ, un tajos tiek Åemti vÄrÄ diff faili - izmaiÅas: izveidotas, dzÄstas, mainÄ«tas. Å Ä«s izmaiÅas tiek ierakstÄ«tas Ä«paÅ”as kopÄÅ”anas Ätruma programmas binlogÄ, kas var Ätri atkÄrtot izmaiÅas visÄ mÅ«su serveru parkÄ. Å eit tiek izmantota nevis tieÅ”a kopÄÅ”ana, bet gan tenku replikÄcija, kad viens serveris nosÅ«ta izmaiÅas saviem tuvÄkajiem kaimiÅiem, tÄs saviem kaimiÅiem un tÄ tÄlÄk. Tas ļauj atjauninÄt kodu desmitos un sekunžu vienÄ«bÄs visÄ flotÄ. Kad izmaiÅas sasniedz vietÄjo kopiju, tÄs lieto Å”os ielÄpus tai vietÄjÄ failu sistÄma. AtcelÅ”ana tiek veikta arÄ« saskaÅÄ ar to paÅ”u shÄmu.
MÄs arÄ« daudz izvietojam kPHP, un tam ir arÄ« sava attÄ«stÄ«ba iet saskaÅÄ ar iepriekÅ” minÄto diagrammu. KopÅ” Ŕī HTTP servera binÄrs, tad mÄs nevaram radÄ«t diff - laidiena binÄrais sver simtiem MB. TÄpÄc Å”eit ir vÄl viena iespÄja - versija ir rakstÄ«ta binlog copyfast. Ar katru bÅ«vniecÄ«bu tas palielinÄs, un atcelÅ”anas laikÄ tas arÄ« palielinÄs. Versija replicÄts serveros. VietÄjie copyfasti redz, ka binlog ir ienÄkusi jauna versija, un ar to paÅ”u tenku replikÄciju viÅi paÅem sev jaunÄko binÄrÄ versija, nenogurdinot mÅ«su galveno serveri, bet rÅ«pÄ«gi sadalot slodzi tÄ«klÄ. Kas seko gracioza atsÄkÅ”ana jaunajai versijai.
MÅ«su dzinÄjiem, kas arÄ« bÅ«tÄ«bÄ ir binÄri, shÄma ir ļoti lÄ«dzÄ«ga:
- git master filiÄle;
- binÄrs iekÅ”Ä deb;
- versija ir ierakstīta binlog copyfast;
- replicÄts serveros;
- serveris izvelk jaunu .dep;
- dpkg -i;
- gracioza atsÄkÅ”ana uz jauno versiju.
AtŔķirÄ«ba ir tÄda, ka mÅ«su binÄrais fails ir iesaiÅots arhÄ«vos deb, un tos izsÅ«knÄjot dpkg -i tiek ievietoti sistÄmÄ. KÄpÄc kPHP tiek izvietots kÄ binÄrs, bet dzinÄji tiek izvietoti kÄ dpkg? Tas notika tÄ. Tas darbojas - nepieskarieties tam.
Noderīgas saites:
- Antona KirjuÅ”kina ziÅojums ar informÄciju par copyfast un tenkÄm.
- ZiÅo Jurijs Nasretdinovs .
- Mans ziÅojums , bet no attÄ«stÄ«bas viedokļa, nevis aparatÅ«ras.
Aleksejs AkuloviÄs ir viens no tiem, kas Programmas komitejas sastÄvÄ palÄ«dz 17. maijÄ kļūs par pÄdÄjÄ laika lielÄko notikumu PHP izstrÄdÄtÄjiem. Paskat, kÄds mums forÅ”s dators, kas (divi no tiem izstrÄdÄ PHP kodolu!) - Ŕķiet kaut kas tÄds, ko nevar palaist garÄm, ja raksti PHP.
Avots: www.habr.com