🥇FAQ ar bensaernïaeth a gwaith ar VKontakte

Mae hanes creu VKontakte ar Wicipedia; dywedwyd wrtho gan Pavel ei hun. Mae'n ymddangos bod pawb eisoes yn ei hadnabod. Ynglŷn â mewnol, pensaernïaeth a strwythur y safle ar HighLoad++ Pavel dweud wrthyf yn ôl yn 2010. Mae llawer o weinyddion wedi gollwng ers hynny, felly byddwn yn diweddaru'r wybodaeth: byddwn yn ei dyrannu, yn tynnu'r tu mewn, yn ei bwyso, ac yn edrych ar y ddyfais VK o safbwynt technegol.

Alexei Akulovich (AterCattus) datblygwr backend yn y tîm VKontakte. Mae trawsgrifiad yr adroddiad hwn yn ateb ar y cyd i gwestiynau cyffredin am weithrediad y platfform, seilwaith, gweinyddwyr a rhyngweithio rhyngddynt, ond nid am ddatblygiad, sef am haearn. Ar wahân, am gronfeydd data a'r hyn sydd gan VK yn lle hynny, am gasglu logiau a monitro'r prosiect cyfan yn ei gyfanrwydd. Manylion o dan y toriad.

Am fwy na phedair blynedd rwyf wedi bod yn delio â phob math o dasgau yn ymwneud â'r pen ôl.

Llwytho i fyny, storio, prosesu, dosbarthu cyfryngau: fideo, ffrydio byw, sain, lluniau, dogfennau.
Isadeiledd, llwyfan, monitro datblygwyr, logiau, caches rhanbarthol, CDN, protocol RPC perchnogol.
Integreiddio â gwasanaethau allanol: hysbysiadau gwthio, dosrannu cyswllt allanol, porthiant RSS.
Helpu cydweithwyr gyda chwestiynau amrywiol, ac mae'r atebion yn gofyn am blymio i god anhysbys.

Yn ystod y cyfnod hwn, cefais law mewn llawer o gydrannau'r wefan. Rwyf am rannu'r profiad hwn.

Pensaernïaeth gyffredinol

Mae popeth, yn ôl yr arfer, yn dechrau gyda gweinydd neu grŵp o weinyddion sy'n derbyn ceisiadau.

Gweinydd blaen

Mae'r gweinydd blaen yn derbyn ceisiadau trwy HTTPS, RTMP a WSS.

HTTPS - mae'r rhain yn geisiadau am brif fersiynau gwe a symudol y wefan: vk.com a m.vk.com, a chleientiaid swyddogol ac answyddogol eraill ein API: cleientiaid symudol, negeswyr. Mae gennym dderbyniad RTMP-traffig ar gyfer darllediadau Live gyda gweinyddion blaen ar wahân a WSS- cysylltiadau ar gyfer Ffrydio API.

Ar gyfer HTTPS a WSS ar weinyddion mae'n werth nginx. Ar gyfer darllediadau RTMP, fe wnaethom newid yn ddiweddar i'n datrysiad ein hunain kive, ond mae y tu hwnt i gwmpas yr adroddiad. Ar gyfer goddef diffygion, mae'r gweinyddwyr hyn yn hysbysebu cyfeiriadau IP cyffredin ac yn gweithredu mewn grwpiau fel na chaiff ceisiadau defnyddwyr eu colli os oes problem ar un o'r gweinyddwyr. Ar gyfer HTTPS a WSS, mae'r un gweinyddwyr hyn yn amgryptio traffig er mwyn cymryd rhan o'r llwyth CPU arnynt eu hunain.

Ni fyddwn yn siarad ymhellach am WSS a RTMP, ond dim ond am geisiadau safonol HTTPS, sydd fel arfer yn gysylltiedig â phrosiect gwe.

Backend

Y tu ôl i'r blaen mae gweinyddwyr backend fel arfer. Maent yn prosesu ceisiadau y mae'r gweinydd blaen yn eu derbyn gan gleientiaid.

Mae'n gweinyddwyr kPHP, y mae'r daemon HTTP yn rhedeg arno, oherwydd bod HTTPS eisoes wedi'i ddadgryptio. Mae kPHP yn weinydd sy'n rhedeg ymlaen modelau prefork: yn dechrau proses meistr, mae criw o brosesau plant, yn trosglwyddo socedi gwrando iddynt ac maent yn prosesu eu ceisiadau. Yn yr achos hwn, ni chaiff prosesau eu hailddechrau rhwng pob cais gan y defnyddiwr, ond yn hytrach ailosod eu cyflwr i'r cyflwr gwerth sero gwreiddiol - cais ar ôl cais, yn lle ailgychwyn.

Dosbarthiad llwyth

Nid yw ein hwynebau i gyd yn gronfa enfawr o beiriannau a all brosesu unrhyw gais. Ni nhw rhannu'n grwpiau ar wahân: cyffredinol, symudol, ap, fideo, llwyfannu... Ni fydd y broblem ar grŵp o beiriannau ar wahân yn effeithio ar bawb arall. Mewn achos o broblemau gyda fideo, ni fydd y defnyddiwr sy'n gwrando ar gerddoriaeth hyd yn oed yn gwybod am y problemau. Penderfynir ar ba gefnlen i anfon y cais ato gan nginx ar y blaen yn ôl y ffurfwedd.

Casglu metrig ac ail-gydbwyso

Er mwyn deall faint o geir sydd angen i ni eu cael ym mhob grŵp, rydyn ni peidiwch â dibynnu ar QPS. Mae'r backends yn wahanol, mae ganddyn nhw wahanol geisiadau, mae gan bob cais gymhlethdod gwahanol o gyfrifo QPS. Dyna pam yr ydym ni rydym yn gweithredu gyda'r cysyniad o lwyth ar y gweinydd yn ei gyfanrwydd - ar y CPU a'r perf.

Mae gennym filoedd o weinyddion o'r fath. Mae pob gweinydd ffisegol yn rhedeg grŵp kPHP i ailgylchu'r holl greiddiau (gan fod kPHP yn un edefyn).

Gweinydd Cynnwys

Storfa yw CS neu Content Server. Mae CS yn weinydd sy'n storio ffeiliau a hefyd yn prosesu ffeiliau wedi'u llwytho i fyny a phob math o dasgau cydamserol cefndirol y mae prif flaen y we yn eu neilltuo iddo.

Mae gennym ddegau o filoedd o weinyddion ffisegol sy'n storio ffeiliau. Mae defnyddwyr wrth ein bodd yn uwchlwytho ffeiliau, ac rydym wrth ein bodd yn eu storio a'u rhannu. Mae rhai o'r gweinyddwyr hyn yn cael eu cau gan weinyddion pu/pp arbennig.

pu/pp

Os gwnaethoch chi agor y tab rhwydwaith yn VK, fe welsoch pu/pp.

Beth yw pu/pp? Os byddwn yn cau un gweinydd ar ôl y llall, yna mae dau opsiwn ar gyfer uwchlwytho a lawrlwytho ffeil i'r gweinydd a gaewyd: yn uniongyrchol drwy http://cs100500.userapi.com/path neu trwy weinydd canolradd - http://pu.vk.com/c100500/path.

Pu yw'r enw hanesyddol ar gyfer uwchlwytho lluniau, ac mae pp yn ddirprwy llun. Hynny yw, mae un gweinydd ar gyfer uwchlwytho lluniau, ac mae un arall ar gyfer uwchlwytho. Nawr nid yn unig mae lluniau'n cael eu llwytho, ond mae'r enw wedi'i gadw.

Mae'r gweinyddwyr hyn terfynu sesiynau HTTPSi dynnu llwyth y prosesydd o'r storfa. Hefyd, gan fod ffeiliau defnyddwyr yn cael eu prosesu ar y gweinyddwyr hyn, gorau po leiaf o wybodaeth sensitif sy'n cael ei storio ar y peiriannau hyn. Er enghraifft, allweddi amgryptio HTTPS.

Gan fod y peiriannau'n cael eu cau gan ein peiriannau eraill, gallwn fforddio peidio â rhoi IPs allanol “gwyn” iddynt, a rhoi "llwyd". Fel hyn fe wnaethom arbed ar y pwll IP a gwarantu amddiffyn y peiriannau rhag mynediad allanol - yn syml, nid oes IP i fynd i mewn iddo.

Gwydnwch dros IPs a rennir. O ran goddefgarwch namau, mae'r cynllun yn gweithio yr un peth - mae gan sawl gweinydd corfforol IP corfforol cyffredin, ac mae'r caledwedd o'u blaenau yn dewis ble i anfon y cais. Byddaf yn siarad am opsiynau eraill yn nes ymlaen.

Y pwynt dadleuol yw bod yn yr achos hwn mae'r cleient yn cadw llai o gysylltiadau. Os oes yr un IP ar gyfer sawl peiriant - gyda'r un gwesteiwr: pu.vk.com neu pp.vk.com, mae gan borwr y cleient gyfyngiad ar nifer y ceisiadau cydamserol i un gwesteiwr. Ond yn amser HTTP/2 hollbresennol, credaf nad yw hyn mor berthnasol bellach.

Anfantais amlwg y cynllun yw bod yn rhaid iddo pwmpio'r holl draffig, sy'n mynd i'r storfa, trwy weinydd arall. Gan ein bod yn pwmpio traffig trwy beiriannau, ni allwn bwmpio traffig trwm eto, er enghraifft, fideo, gan ddefnyddio'r un cynllun. Rydym yn ei drosglwyddo'n uniongyrchol - cysylltiad uniongyrchol ar wahân ar gyfer storfeydd ar wahân yn benodol ar gyfer fideo. Rydym yn trosglwyddo cynnwys ysgafnach trwy ddirprwy.

Ddim yn bell yn ôl cawsom fersiwn well o ddirprwy. Nawr fe ddywedaf wrthych sut maen nhw'n wahanol i rai cyffredin a pham mae hyn yn angenrheidiol.

Dydd Sul

Ym mis Medi 2017, Oracle, a oedd wedi prynu Sun o'r blaen, tanio nifer enfawr o weithwyr Sun. Gallwn ddweud bod y cwmni wedi peidio â bodoli ar hyn o bryd. Wrth ddewis enw ar gyfer y system newydd, penderfynodd ein gweinyddwyr dalu teyrnged er cof am y cwmni hwn gan enwi'r system newydd Sun. Ymhlith ein hunain rydyn ni'n ei galw hi'n “haul”.

Roedd gan pp ychydig o broblemau. Un IP fesul grŵp - storfa aneffeithiol. Mae sawl gweinydd corfforol yn rhannu cyfeiriad IP cyffredin, ac nid oes unrhyw ffordd i reoli pa weinydd y bydd y cais yn mynd iddo. Felly, os daw gwahanol ddefnyddwyr am yr un ffeil, yna os oes storfa ar y gweinyddwyr hyn, mae'r ffeil yn dod i ben yn storfa pob gweinydd. Mae hwn yn gynllun aneffeithlon iawn, ond ni ellid gwneud dim.

O ganlyniad - ni allwn ddarnio cynnwys, oherwydd ni allwn ddewis gweinydd penodol ar gyfer y grŵp hwn - mae ganddynt IP cyffredin. Hefyd am rai rhesymau mewnol sydd gennym nid oedd yn bosibl gosod gweinyddion o'r fath mewn rhanbarthau. Dim ond yn St Petersburg y safasant.

Gyda'r haul, fe wnaethom newid y system ddethol. Nawr mae gennym ni llwybro anycast: llwybro deinamig, anycast, daemon self-check. Mae gan bob gweinydd ei IP unigol ei hun, ond is-rwydwaith cyffredin. Mae popeth wedi'i ffurfweddu yn y fath fodd fel os bydd un gweinydd yn methu, mae'r traffig yn cael ei ledaenu ar draws gweinyddwyr eraill yr un grŵp yn awtomatig. Nawr mae'n bosibl dewis gweinydd penodol, dim caching diangen, ac ni effeithiwyd ar ddibynadwyedd.

Cefnogaeth pwysau. Nawr gallwn fforddio gosod peiriannau o bŵer gwahanol yn ôl yr angen, a hefyd, rhag ofn y bydd problemau dros dro, newid pwysau'r "haul" sy'n gweithio i leihau'r llwyth arnynt, fel eu bod yn "gorffwys" ac yn dechrau gweithio eto.

Rhannu yn ôl ID cynnwys. Peth doniol am ddarnio: rydyn ni fel arfer yn torri cynnwys fel bod gwahanol ddefnyddwyr yn mynd i'r un ffeil trwy'r un “haul” fel bod ganddyn nhw storfa gyffredin.

Lansiwyd y rhaglen “Meillion” gennym yn ddiweddar. Cwis ar-lein yw hwn mewn darllediad byw, lle mae'r gwesteiwr yn gofyn cwestiynau a defnyddwyr yn ateb mewn amser real, gan ddewis opsiynau. Mae gan yr ap sgwrs lle gall defnyddwyr sgwrsio. Yn gallu cysylltu â'r darllediad ar yr un pryd mwy na 100 mil o bobl. Maent i gyd yn ysgrifennu negeseuon sy'n cael eu hanfon at yr holl gyfranogwyr, a daw avatar gyda'r neges. Os daw 100 mil o bobl am un avatar mewn un “haul”, yna weithiau gall rolio y tu ôl i gwmwl.

Er mwyn gwrthsefyll pyliau o geisiadau am yr un ffeil, ar gyfer math penodol o gynnwys rydyn ni'n troi cynllun gwirion ymlaen sy'n lledaenu ffeiliau ar draws yr holl “haul” sydd ar gael yn y rhanbarth.

Haul o'r tu mewn

Procsi gwrthdro ar nginx, storfa naill ai mewn RAM neu ar ddisgiau cyflym Optane / NVMe. Enghraifft: http://sun4-2.userapi.com/c100500/path - dolen i'r “haul”, sydd wedi'i leoli yn y pedwerydd rhanbarth, yr ail grŵp gweinyddwyr. Mae'n cau'r ffeil llwybr, sy'n gorwedd yn gorfforol ar weinydd 100500.

Cache

Rydym yn ychwanegu un nod arall at ein cynllun pensaernïol - yr amgylchedd caching.

Isod mae'r diagram gosodiad caches rhanbarthol, mae tua 20 ohonyn nhw. Dyma'r mannau lle mae caches a "haul" wedi'u lleoli, a all storio traffig trwyddynt eu hunain.

Mae hyn yn celcio cynnwys amlgyfrwng; nid oes unrhyw ddata defnyddiwr yn cael ei storio yma - dim ond cerddoriaeth, fideo, lluniau.

Er mwyn pennu rhanbarth y defnyddiwr, rydym ni rydym yn casglu rhagddodiaid rhwydwaith BGP a gyhoeddwyd yn y rhanbarthau. Yn achos wrth gefn, mae'n rhaid i ni hefyd ddosrannu'r gronfa ddata geoip os na allem ddod o hyd i'r IP trwy ragddodiaid. Rydym yn pennu'r rhanbarth yn ôl IP y defnyddiwr. Yn y cod, gallwn edrych ar un neu fwy o ranbarthau'r defnyddiwr - y pwyntiau hynny y mae ef agosaf atynt yn ddaearyddol.

Sut mae'n gweithio?

Rydym yn cyfrif poblogrwydd ffeiliau fesul rhanbarth. Mae yna nifer o'r storfa ranbarthol lle mae'r defnyddiwr wedi'i leoli, a dynodwr ffeil - rydyn ni'n cymryd y pâr hwn ac yn cynyddu'r sgôr gyda phob lawrlwythiad.

Ar yr un pryd, mae cythreuliaid - gwasanaethau mewn rhanbarthau - o bryd i'w gilydd yn dod i'r API ac yn dweud: “Rwy'n storfa o'r fath ac o'r fath, rhowch restr i mi o'r ffeiliau mwyaf poblogaidd yn fy rhanbarth nad ydynt eto arnaf. ” Mae'r API yn cyflwyno criw o ffeiliau wedi'u didoli yn ôl sgôr, mae'r daemon yn eu lawrlwytho, yn mynd â nhw i'r rhanbarthau ac yn danfon y ffeiliau oddi yno. Dyma'r gwahaniaeth sylfaenol rhwng pu/pp a Sun o caches: maen nhw'n rhoi'r ffeil trwyddynt eu hunain ar unwaith, hyd yn oed os nad yw'r ffeil hon yn y storfa, ac mae'r storfa'n lawrlwytho'r ffeil iddo'i hun yn gyntaf, ac yna'n dechrau ei rhoi yn ôl.

Yn yr achos hwn cawn cynnwys yn agosach at ddefnyddwyr a lledaenu llwyth y rhwydwaith. Er enghraifft, dim ond o storfa Moscow rydyn ni'n dosbarthu mwy nag 1 Tbit yr eiliad yn ystod oriau brig.

Ond mae yna broblemau - nid yw gweinyddion cache yn rwber. Ar gyfer cynnwys hynod boblogaidd, weithiau nid oes digon o rwydwaith ar gyfer gweinydd ar wahân. Mae ein gweinyddion storfa yn 40-50 Gbit yr eiliad, ond mae yna gynnwys sy'n clocsio sianel o'r fath yn llwyr. Rydym yn symud tuag at weithredu storio mwy nag un copi o ffeiliau poblogaidd yn y rhanbarth. Gobeithiaf y byddwn yn ei roi ar waith erbyn diwedd y flwyddyn.

Edrychon ni ar y bensaernïaeth gyffredinol.

Gweinyddion blaen sy'n derbyn ceisiadau.
Yn cefnogi'r ceisiadau prosesu hynny.
Storfeydd sy'n cael eu cau gan ddau fath o ddirprwy.
caches rhanbarthol.

Beth sydd ar goll o'r diagram hwn? Wrth gwrs, y cronfeydd data yr ydym yn storio data ynddynt.

Cronfeydd data neu beiriannau

Rydym yn eu galw nid cronfeydd data, ond peiriannau - Peiriannau, oherwydd ein bod yn ymarferol nid oes gennym gronfeydd data yn yr ystyr a dderbynnir yn gyffredinol.

Mae hwn yn fesur angenrheidiol. Digwyddodd hyn oherwydd yn 2008-2009, pan gafodd VK dwf ffrwydrol mewn poblogrwydd, roedd y prosiect yn gweithio'n gyfan gwbl ar MySQL a Memcache ac roedd problemau. Roedd MySQL wrth ei fodd yn chwalu a llygru ffeiliau, ac ar ôl hynny ni fyddai'n adfer, a diraddiodd Memcache yn raddol mewn perfformiad a bu'n rhaid ei ailgychwyn.

Mae'n ymddangos bod gan y prosiect cynyddol boblogaidd storfa barhaus, sy'n llygru data, a storfa, sy'n arafu. Mewn amodau o'r fath, mae'n anodd datblygu prosiect cynyddol. Penderfynwyd ceisio ailysgrifennu'r pethau hollbwysig yr oedd y prosiect yn canolbwyntio arnynt ar ein beiciau ein hunain.

Roedd yr ateb yn llwyddiannus. Roedd cyfle i wneud hyn, yn ogystal ag anghenraid eithafol, oherwydd nid oedd ffyrdd eraill o raddio yn bodoli bryd hynny. Nid oedd yna lawer o gronfeydd data, nid oedd NoSQL yn bodoli eto, dim ond MySQL, Memcache, PostrgreSQL - a dyna ni.

Gweithrediad cyffredinol. Arweiniwyd y datblygiad gan ein tîm o ddatblygwyr C a gwnaed popeth mewn modd cyson. Waeth beth fo'r injan, roedd gan bob un ohonynt tua'r un fformat ffeil wedi'i ysgrifennu ar ddisg, yr un paramedrau lansio, signalau wedi'u prosesu yn yr un modd, ac ymddwyn yn fras yr un fath rhag ofn y byddai sefyllfaoedd ymylol a phroblemau. Gyda thwf peiriannau, mae'n gyfleus i weinyddwyr weithredu'r system - nid oes sw y mae angen ei gynnal, ac mae'n rhaid iddynt ailddysgu sut i weithredu pob cronfa ddata trydydd parti newydd, a oedd yn ei gwneud hi'n bosibl cynyddu'n gyflym ac yn gyfleus. eu rhif.

Mathau o beiriannau

Ysgrifennodd y tîm dipyn o injans. Dyma rai ohonyn nhw: ffrind, awgrymiadau, delwedd, ipdb, llythyrau, rhestrau, logiau, memcached, meowdb, newyddion, nostradamus, llun, rhestri chwarae, pmemcached, blwch tywod, chwilio, storio, hoff bethau, tasgau,…

Ar gyfer pob tasg sy'n gofyn am strwythur data penodol neu brosesu ceisiadau annodweddiadol, mae tîm C yn ysgrifennu injan newydd. Pam ddim.

Mae gennym injan ar wahân memcached, sy'n debyg i un rheolaidd, ond gyda bagad o ddaioni, ac nad yw'n arafu. Nid ClickHouse, ond mae hefyd yn gweithio. Ar gael ar wahân pemcached - A yw memcached parhaus, sydd hefyd yn gallu storio data ar ddisg, ar ben hynny, nag sy'n cyd-fynd â RAM, er mwyn peidio â cholli data wrth ailgychwyn. Mae yna beiriannau amrywiol ar gyfer tasgau unigol: ciwiau, rhestrau, setiau - popeth sydd ei angen ar ein prosiect.

Clystyrau

O safbwynt cod, nid oes angen meddwl am beiriannau neu gronfeydd data fel prosesau, endidau neu achosion. Mae'r cod yn gweithio'n benodol gyda chlystyrau, gyda grwpiau o injans - un math fesul clwstwr. Gadewch i ni ddweud bod yna glwstwr memcached - dim ond grŵp o beiriannau ydyw.

Nid oes angen i'r cod wybod lleoliad ffisegol, maint na nifer y gweinyddwyr o gwbl. Mae'n mynd i'r clwstwr gan ddefnyddio dynodwr penodol.

Er mwyn i hyn weithio, mae angen i chi ychwanegu un endid arall sydd wedi'i leoli rhwng y cod a'r peiriannau - dirprwy.

RPC dirprwy

Dirprwy bws cysylltu, y mae bron y safle cyfan yn rhedeg arno. Ar yr un pryd mae gennym ni dim darganfyddiad gwasanaeth — yn lle hynny, mae ffurfwedd ar gyfer y dirprwy hwn, sy'n gwybod lleoliad pob clwstwr a holl ddarnau'r clwstwr hwn. Dyma beth mae gweinyddwyr yn ei wneud.

Nid yw rhaglenwyr yn poeni o gwbl faint, ble a beth mae'n ei gostio - maen nhw'n mynd i'r clwstwr. Mae hyn yn caniatáu llawer i ni. Wrth dderbyn cais, mae'r dirprwy yn ailgyfeirio'r cais, gan wybod ble - mae'n pennu hyn ei hun.

Yn yr achos hwn, mae dirprwy yn bwynt amddiffyn rhag methiant gwasanaeth. Os bydd rhywfaint o injan yn arafu neu'n damwain, yna mae'r dirprwy yn deall hyn ac yn ymateb yn unol â hynny i ochr y cleient. Mae hyn yn caniatáu ichi gael gwared ar y terfyn amser - nid yw'r cod yn aros i'r injan ymateb, ond mae'n deall nad yw'n gweithio a bod angen iddo ymddwyn yn wahanol rywsut. Rhaid paratoi'r cod am y ffaith nad yw'r cronfeydd data bob amser yn gweithio.

Gweithrediadau penodol

Weithiau rydym yn dal i fod eisiau cael rhyw fath o ddatrysiad ansafonol fel injan. Ar yr un pryd, penderfynwyd peidio â defnyddio ein rpc-proxy parod, a grëwyd yn benodol ar gyfer ein peiriannau, ond i wneud dirprwy ar wahân ar gyfer y dasg.

Ar gyfer MySQL, sydd gennym o hyd yma ac acw, rydym yn defnyddio db-proxy, ac ar gyfer ClickHouse - Cabindy.

Mae'n gweithio fel hyn yn gyffredinol. Mae yna weinydd penodol, mae'n rhedeg kPHP, Go, Python - yn gyffredinol, unrhyw god a all ddefnyddio ein protocol RPC. Mae'r cod yn rhedeg yn lleol ar ddirprwy RPC - mae pob gweinydd lle mae'r cod wedi'i leoli yn rhedeg ei ddirprwy lleol ei hun. Ar gais, mae'r dirprwy yn deall ble i fynd.

Os yw un injan eisiau mynd i un arall, hyd yn oed os yw'n gymydog, mae'n mynd trwy ddirprwy, oherwydd gall y cymydog fod mewn canolfan ddata arall. Ni ddylai'r injan ddibynnu ar wybod lleoliad unrhyw beth heblaw ei hun - dyma ein datrysiad safonol. Ond wrth gwrs mae yna eithriadau :)

Enghraifft o gynllun TL y mae pob injan yn gweithredu yn unol ag ef.

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;

Mae hwn yn brotocol deuaidd, a'r analog agosaf yw protobuf. Mae'r sgema yn rhag-ddisgrifio meysydd dewisol, mathau cymhleth - estyniadau o sgalarau adeiledig, ac ymholiadau. Mae popeth yn gweithio yn unol â'r protocol hwn.

RPC dros TL dros TCP/CDU… CDU?

Mae gennym brotocol RPC ar gyfer gweithredu ceisiadau injan sy'n rhedeg ar ben y cynllun TL. Mae hyn i gyd yn gweithio dros gysylltiad TCP/CDU. Mae TCP yn ddealladwy, ond pam mae angen CDU arnom yn aml?

Mae CDU yn helpu osgoi'r broblem o nifer enfawr o gysylltiadau rhwng gweinyddwyr. Os oes gan bob gweinydd ddirprwy RPC ac, yn gyffredinol, gall fynd i unrhyw injan, yna mae degau o filoedd o gysylltiadau TCP fesul gweinydd. Mae yna lwyth, ond mae'n ddiwerth. Yn achos CDU nid yw'r broblem hon yn bodoli.

Dim ysgwyd llaw TCP diangen. Mae hon yn broblem nodweddiadol: pan fydd injan newydd neu weinydd newydd yn cael ei lansio, sefydlir llawer o gysylltiadau TCP ar unwaith. Ar gyfer ceisiadau ysgafn bach, er enghraifft, llwyth tâl CDU, mae'r holl gyfathrebu rhwng y cod a'r injan yn dau becyn CDU: un yn hedfan i un cyfeiriad, yr ail i'r cyfeiriad arall. Un daith gron - a chafodd y cod ymateb gan yr injan heb ysgwyd llaw.

Ydy, mae'r cyfan yn gweithio gyda chanran fach iawn o golled pecyn. Mae gan y protocol gefnogaeth ar gyfer ail-drosglwyddiadau a seibiannau, ond os byddwn yn colli llawer, byddwn yn cael TCP bron, nad yw'n broffidiol. Nid ydym yn gyrru CDU ar draws cefnforoedd.

Mae gennym filoedd o weinyddion o'r fath, ac mae'r cynllun yr un peth: gosodir pecyn o beiriannau ar bob gweinydd ffisegol. Maent yn bennaf yn un edau i redeg cyn gynted â phosibl heb rwystro, ac yn cael eu rhwygo fel atebion un edau. Ar yr un pryd, nid oes gennym unrhyw beth mwy dibynadwy na'r peiriannau hyn, a rhoddir llawer o sylw i storio data parhaus.

Storio data yn barhaus

Peiriannau ysgrifennu binlogs. Mae binlog yn ffeil yr ychwanegir digwyddiad ar gyfer newid cyflwr neu ddata ar ei diwedd. Mewn gwahanol atebion fe'i gelwir yn wahanol: log deuaidd, WAL, AOF, ond yr un yw yr egwyddor.

Er mwyn atal yr injan rhag ailddarllen y binlog cyfan am flynyddoedd lawer wrth ailgychwyn, mae'r injans yn ysgrifennu cipluniau - cyflwr presennol. Os oes angen, maen nhw'n darllen ohono yn gyntaf, ac yna'n gorffen darllen o'r binlog. Ysgrifennir pob log bin yn yr un fformat deuaidd - yn ôl y cynllun TL, fel y gall gweinyddwyr eu gweinyddu'n gyfartal gan ddefnyddio eu hoffer. Nid oes angen cipluniau o'r fath. Mae yna bennawd cyffredinol sy'n nodi ciplun pwy sy'n int, hud yr injan, a pha gorff nad yw'n bwysig i unrhyw un. Mae hyn yn broblem gyda'r injan a gofnododd y ciplun.

Disgrifiaf yn gyflym yr egwyddor o weithredu. Mae gweinydd y mae'r injan yn rhedeg arno. Mae'n agor binlog gwag newydd ar gyfer ysgrifennu ac yn ysgrifennu digwyddiad ar gyfer newid iddo.

Ar ryw adeg, mae naill ai'n penderfynu cymryd ciplun ei hun, neu mae'n derbyn signal. Mae'r gweinydd yn creu ffeil newydd, yn ysgrifennu ei gyflwr cyfan i mewn iddi, yn atodi maint presennol y binlog - gwrthbwyso - i ddiwedd y ffeil, ac yn parhau i ysgrifennu ymhellach. Nid yw binlog newydd yn cael ei greu.

Ar ryw adeg, pan fydd yr injan yn ailgychwyn, bydd binlog a chipolwg ar y ddisg. Mae'r injan yn darllen y ciplun cyfan ac yn codi ei gyflwr ar bwynt penodol.

Yn darllen y safle a oedd ar yr adeg y crëwyd y ciplun a maint y binlog.

Yn darllen diwedd y log bin i gael y cyflwr presennol ac yn parhau i ysgrifennu digwyddiadau pellach. Mae hwn yn gynllun syml; mae ein holl beiriannau yn gweithio yn unol ag ef.

Dyblygiad data

O ganlyniad, atgynhyrchu data yn ein seiliedig ar ddatganiad — rydym yn ysgrifennu yn y binlog nid unrhyw newidiadau tudalen, ond sef ceisiadau newid. Yn debyg iawn i'r hyn a ddaw dros y rhwydwaith, dim ond wedi'i addasu ychydig.

Defnyddir yr un cynllun nid yn unig ar gyfer dyblygu, ond hefyd i greu copïau wrth gefn. Mae gennym ni injan - meistr ysgrifennu sy'n ysgrifennu i'r binlog. Mewn unrhyw le arall lle mae'r gweinyddwyr wedi'i sefydlu, mae'r binlog hwn yn cael ei gopïo, a dyna ni - mae gennym ni wrth gefn.

Os oes angen replica darllenEr mwyn lleihau'r llwyth darllen CPU, caiff yr injan ddarllen ei lansio'n syml, sy'n darllen diwedd y binlog ac yn gweithredu'r gorchmynion hyn yn lleol.

Mae'r oedi yma yn fach iawn, ac mae'n bosibl darganfod faint mae'r replica ar ei hôl hi o'r meistr.

Rhannu data mewn dirprwy RPC

Sut mae darnio yn gweithio? Sut mae'r dirprwy yn deall at ba clwstwr darn i'w anfon? Nid yw'r cod yn dweud: "Anfonwch am 15 darn!" — na, gwneir hyn gan y dirprwy.

Y cynllun symlaf yw firstint — y rhif cyntaf yn y cais.

get(photo100_500) => 100 % N.

Dyma enghraifft ar gyfer protocol testun memcached syml, ond, wrth gwrs, gall ymholiadau fod yn gymhleth ac yn strwythuredig. Mae'r enghraifft yn cymryd y rhif cyntaf yn yr ymholiad a'r gweddill o'i rannu â maint y clwstwr.

Mae hyn yn ddefnyddiol pan fyddwn am gael lleoliad data un endid. Gadewch i ni ddweud mai ID defnyddiwr neu grŵp yw 100, ac rydym am i holl ddata un endid fod ar un darn ar gyfer ymholiadau cymhleth.

Os nad oes ots gennym sut mae ceisiadau yn cael eu lledaenu ar draws y clwstwr, mae opsiwn arall - stwnsio'r darn cyfan.

hash(photo100_500) => 3539886280 % N

Rydym hefyd yn cael yr hash, gweddill y rhaniad a'r rhif shard.

Mae’r ddau opsiwn hyn yn gweithio dim ond os ydym yn barod am y ffaith, wrth gynyddu maint y clwstwr, y byddwn yn ei rannu neu’n ei gynyddu sawl gwaith. Er enghraifft, cawsom 16 darn, nid oes gennym ddigon, rydym eisiau mwy - gallwn gael 32 yn ddiogel heb amser segur. Os ydym am gynyddu nid lluosrifau, bydd amser segur, oherwydd ni fyddwn yn gallu rhannu popeth yn gywir heb golledion. Mae'r opsiynau hyn yn ddefnyddiol, ond nid bob amser.

Os oes angen i ni ychwanegu neu ddileu nifer mympwyol o weinyddion, rydym yn defnyddio Stwnsio cyson ar y cylch a la Ketama. Ond ar yr un pryd, rydym yn colli ardal y data yn llwyr; mae'n rhaid i ni uno'r cais i'r clwstwr fel bod pob darn yn dychwelyd ei ymateb bach ei hun, ac yna uno'r ymatebion i'r dirprwy.

Mae yna geisiadau uwch-benodol. Mae'n edrych fel hyn: mae dirprwy RPC yn derbyn y cais, yn penderfynu i ba glwstwr i fynd ac yn pennu'r darn. Yna mae yna naill ai meistri ysgrifennu, neu, os oes gan y clwstwr gefnogaeth replica, mae'n anfon at replica ar alw. Mae'r dirprwy yn gwneud hyn i gyd.

Logiau

Rydym yn ysgrifennu logiau mewn sawl ffordd. Yr un mwyaf amlwg a syml yw ysgrifennu logiau i memcache.

ring-buffer: prefix.idx = line

Mae rhagddodiad allweddol - enw'r log, llinell, ac mae maint y log hwn - nifer y llinellau. Rydyn ni'n cymryd rhif hap o 0 i nifer y llinellau llai 1. Mae'r allwedd mewn memcache yn rhagddodiad sydd wedi'i gydgategu â'r rhif hap hwn. Rydym yn arbed y llinell log a'r amser presennol i'r gwerth.

Pan fydd angen darllen logiau, rydym yn cynnal Aml Cael pob allwedd, wedi'u didoli yn ôl amser, ac felly yn cael log cynhyrchu mewn amser real. Defnyddir y cynllun pan fydd angen i chi ddadfygio rhywbeth wrth gynhyrchu mewn amser real, heb dorri unrhyw beth, heb atal neu ganiatáu traffig i beiriannau eraill, ond nid yw'r log hwn yn para'n hir.

Ar gyfer storio boncyffion yn ddibynadwy mae gennym injan boncyff-peiriant. Dyma'n union pam y cafodd ei greu ac fe'i defnyddir yn eang mewn nifer enfawr o glystyrau. Mae'r clwstwr mwyaf yr wyf yn gwybod amdano yn storio 600 TB o foncyffion llawn.

Mae'r injan yn hen iawn, mae yna glystyrau sydd eisoes yn 6-7 oed. Mae yna broblemau ag ef yr ydym yn ceisio eu datrys, er enghraifft, dechreuasom ddefnyddio ClickHouse i storio logiau.

Casglu logiau yn ClickHouse

Mae'r diagram hwn yn dangos sut rydyn ni'n cerdded i mewn i'n peiriannau.

Mae cod sy'n mynd yn lleol trwy RPC i'r dirprwy RPC, ac mae'n deall ble i fynd i'r injan. Os ydym am ysgrifennu logiau yn ClickHouse, mae angen i ni newid dwy ran yn y cynllun hwn:

disodli rhai injan gyda ClickHouse;
disodli'r dirprwy RPC, na all gael mynediad at ClickHouse, gyda rhywfaint o ateb a all, a thrwy RPC.

Mae'r injan yn syml - rydyn ni'n rhoi gweinydd neu glwstwr o weinyddion yn ei le gyda ClickHouse.

Ac i fynd i ClickHouse, fe wnaethon ni Ty Gathell. Os awn yn syth o KittenHouse i ClickHouse, ni fydd yn ymdopi. Hyd yn oed heb geisiadau, mae'n adio i fyny o gysylltiadau HTTP o nifer enfawr o beiriannau. Er mwyn i'r cynllun weithio, ar weinydd gyda ClickHouse codir procsi cefn lleol, sydd wedi'i ysgrifennu yn y fath fodd fel y gall wrthsefyll y cyfeintiau gofynnol o gysylltiadau. Gall hefyd glustogi data ynddo'i hun yn gymharol ddibynadwy.

Weithiau nid ydym am weithredu'r cynllun RPC mewn datrysiadau ansafonol, er enghraifft, yn nginx. Felly, mae gan KittenHouse y gallu i dderbyn logiau trwy'r CDU.

Os yw anfonwr a derbynnydd y logiau yn gweithio ar yr un peiriant, yna mae'r tebygolrwydd o golli pecyn CDU o fewn y gwesteiwr lleol yn eithaf isel. Fel cyfaddawd rhwng yr angen i weithredu RPC mewn datrysiad trydydd parti a dibynadwyedd, rydym yn syml yn defnyddio anfon CDU. Byddwn yn dychwelyd at y cynllun hwn yn ddiweddarach.

Monitro

Mae gennym ddau fath o logiau: y rhai a gesglir gan weinyddwyr ar eu gweinyddwyr a'r rhai a ysgrifennwyd gan ddatblygwyr o god. Maent yn cyfateb i ddau fath o fetrigau: system a chynnyrch.

Metrigau system

Mae'n gweithio ar ein holl weinyddion netdata, sy'n casglu ystadegau ac yn eu hanfon at Carbon Graffit. Felly, defnyddir ClickHouse fel system storio, ac nid Whisper, er enghraifft. Os oes angen, gallwch ddarllen yn uniongyrchol o ClickHouse, neu ddefnyddio Grafana ar gyfer metrigau, graffiau ac adroddiadau. Fel datblygwyr, mae gennym ddigon o fynediad i Netdata a Grafana.

Metrigau cynnyrch

Er hwylustod, rydym wedi ysgrifennu llawer o bethau. Er enghraifft, mae yna set o swyddogaethau cyffredin sy'n eich galluogi i ysgrifennu Counts, UniqueCounts gwerthoedd i mewn i ystadegau, sy'n cael eu hanfon i rywle pellach.

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

$stats = statlogsStatData($params)

Yn dilyn hynny, gallwn ddefnyddio hidlwyr didoli a grwpio a gwneud popeth yr ydym ei eisiau o ystadegau - adeiladu graffiau, ffurfweddu Corff Gwarchod.

Rydym yn ysgrifennu iawn llawer o fetrigau mae nifer y digwyddiadau o 600 biliwn i 1 triliwn y dydd. Fodd bynnag, rydym am eu cadw o leiaf cwpl o flynyddoeddi ddeall tueddiadau mewn metrigau. Mae rhoi’r cyfan at ei gilydd yn broblem fawr nad ydym wedi’i datrys eto. Fe ddywedaf wrthych sut mae wedi bod yn gweithio dros yr ychydig flynyddoedd diwethaf.

Mae gennym swyddogaethau sy'n ysgrifennu'r metrigau hyn i memcache lleoli leihau nifer y cofrestriadau. Unwaith mewn cyfnod byr yn cael ei lansio'n lleol stats-daemon yn casglu pob cofnod. Nesaf, mae'r cythraul yn uno'r metrigau yn ddwy haen o weinyddion logiau-gasglwyr, sy'n agregu ystadegau o griw o'n peiriannau fel nad yw'r haen y tu ôl iddynt yn marw.

Os oes angen, gallwn ysgrifennu'n uniongyrchol at gasglwyr logiau.

Ond mae ysgrifennu o god yn uniongyrchol at gasglwyr, gan osgoi sta-daemom, yn ddatrysiad graddadwy wael oherwydd ei fod yn cynyddu'r llwyth ar y casglwr. Mae'r ateb yn addas dim ond os am ryw reswm na allwn godi'r stats-daemon memcache ar y peiriant, neu iddo ddamwain ac aethom yn uniongyrchol.

Nesaf, mae casglwyr logiau yn cyfuno ystadegau i mewn meowDB - dyma ein cronfa ddata, sydd hefyd yn gallu storio metrigau.

Yna gallwn wneud dewisiadau "ger-SQL" deuaidd o'r cod.

Arbrawf

Yn ystod haf 2018, cawsom hacathon mewnol, a daeth y syniad i fyny i geisio disodli rhan goch y diagram gyda rhywbeth a allai storio metrigau yn ClickHouse. Mae gennym ni logiau ar ClickHouse - beth am roi cynnig arni?

Roedd gennym ni gynllun a oedd yn ysgrifennu logiau trwy KittenHouse.

Penderfynnom ychwanegwch “*Ty” arall at y diagram, a fydd yn derbyn yr union fetrigau yn y fformat wrth i'n cod eu hysgrifennu trwy'r CDU. Yna mae'r *Tŷ hwn yn eu troi'n fewnosodiadau, fel logiau, y mae KittenHouse yn eu deall. Gall gyflwyno'r logiau hyn yn berffaith i ClickHouse, a ddylai allu eu darllen.

Mae'r cynllun gyda memcache, stats-daemon a chronfa ddata logs-collectors yn cael ei ddisodli gan yr un hwn.

Mae anfon o god yma, sydd wedi'i ysgrifennu'n lleol yn StatsHouse.
Mae StatsHouse yn ysgrifennu metrigau CDU, sydd eisoes wedi'u trosi'n fewnosodiadau SQL, i KittenHouse mewn sypiau.
Mae KittenHouse yn eu hanfon i ClickHouse.
Os ydym am eu darllen, yna rydym yn eu darllen gan osgoi StatsHouse - yn uniongyrchol o ClickHouse gan ddefnyddio SQL rheolaidd.

A yw'n dal i fod arbrofi, ond rydyn ni'n hoffi sut mae'n troi allan. Os byddwn yn trwsio’r problemau gyda’r cynllun, yna efallai y byddwn yn newid iddo’n llwyr. Yn bersonol, gobeithio.

Cynllun nid yw'n arbed haearn. Mae angen llai o weinyddion, nid oes angen stats-daemons lleol a chasglwyr logiau, ond mae angen gweinydd mwy ar ClickHouse na'r rhai yn y cynllun presennol. Mae angen llai o weinyddion, ond rhaid iddynt fod yn ddrutach ac yn fwy pwerus.

Defnyddio

Yn gyntaf, gadewch i ni edrych ar y defnydd PHP. Rydym yn datblygu yn git: defnydd GitLab и TeamCity ar gyfer lleoli. Mae canghennau datblygu yn cael eu huno i'r brif gangen, o'r meistr ar gyfer profi maent yn cael eu huno i lwyfannu, ac o lwyfannu i gynhyrchu.

Cyn ei ddefnyddio, cymerir y gangen gynhyrchu gyfredol a'r un flaenorol, ac ystyrir ffeiliau diff ynddynt - newidiadau: creu, dileu, newid. Mae'r newid hwn yn cael ei gofnodi yn y binlog o injan copyfast arbennig, a all yn gyflym ailadrodd newidiadau i'n fflyd gweinyddwyr cyfan. Nid copïo'n uniongyrchol yw'r hyn a ddefnyddir yma, ond atgynhyrchu clecs, pan fydd un gweinydd yn anfon newidiadau i'w gymdogion agosaf, y rhai i'w cymdogion, ac yn y blaen. Mae hyn yn caniatáu ichi ddiweddaru'r cod mewn degau ac unedau o eiliadau ar draws y fflyd gyfan. Pan fydd y newid yn cyrraedd y replica lleol, mae'n cymhwyso'r clytiau hyn i'w system ffeiliau leol. Mae dychwelyd hefyd yn cael ei wneud yn unol â'r un cynllun.

Rydym hefyd yn defnyddio llawer o kPHP ac mae ganddo hefyd ei ddatblygiad ei hun git yn ôl y diagram uchod. Ers hyn Deuaidd gweinydd HTTP, yna ni allwn gynhyrchu diff - mae'r deuaidd rhyddhau yn pwyso cannoedd o MB. Felly, mae opsiwn arall yma - ysgrifennir at y fersiwn copi cyflym binlog. Gyda phob adeilad mae'n cynyddu, ac wrth ddychwelyd mae'n cynyddu hefyd. Fersiwn wedi'i ailadrodd i weinyddion. Mae copi cyflym lleol yn gweld bod fersiwn newydd wedi mynd i mewn i'r binlog, a thrwy'r un ailadrodd clecs maen nhw'n cymryd y fersiwn diweddaraf o'r deuaidd drostynt eu hunain, heb flino ein prif weinydd, ond yn lledaenu'r llwyth yn ofalus ar draws y rhwydwaith. Beth sy'n dilyn ail-lansio gosgeiddig ar gyfer y fersiwn newydd.

Ar gyfer ein peiriannau, sydd hefyd yn eu hanfod yn ddeuaidd, mae'r cynllun yn debyg iawn:

cangen meistr git;
deuaidd mewn .deb;
mae'r fersiwn wedi'i ysgrifennu i binlog copyfast;
wedi'i ailadrodd i weinyddion;
mae'r gweinydd yn tynnu allan .dep ffres;
dpkg -i;
ail-lansiad gosgeiddig i fersiwn newydd.

Y gwahaniaeth yw bod ein deuaidd wedi'i becynnu mewn archifau .deb, ac wrth bwmpio allan nhw dpkg -i yn cael eu gosod ar y system. Pam mae kPHP yn cael ei ddefnyddio fel deuaidd, ac injans yn cael eu defnyddio fel dpkg? Digwyddodd felly. Mae'n gweithio - peidiwch â chyffwrdd ag ef.

Dolenni defnyddiol:

Adroddiad gan Anton Kiryushkin “Gweinyddwr system vkontakte. Sut?" gyda manylion am gopi cyflym a chlecs.
Adroddiad gan Yuri Nasretdinov “Sut mae VK yn mewnosod data i CLickHouse o ddegau o filoedd o weinyddion”.
Fy adroddiad “Pensaernïaeth prosiect cynyddol gan ddefnyddio enghraifft VKontakte”, ond o safbwynt datblygu, nid caledwedd.

Mae Alexey Akulovich yn un o'r rhai sydd, fel rhan o Bwyllgor y Rhaglen, yn helpu PHP Rwsia ar Fai 17th fydd y digwyddiad mwyaf i ddatblygwyr PHP yn ddiweddar. Edrychwch pa gyfrifiadur personol cŵl sydd gennym, beth siaradwyr (dau ohonynt yn datblygu PHP craidd!) - yn ymddangos fel rhywbeth na allwch ei golli os ydych yn ysgrifennu PHP.

Ffynhonnell: hab.com

Cwestiynau Cyffredin ar bensaernïaeth a gwaith VKontakte