Blociau adeiladu o geisiadau a ddosbarthwyd. Ail frasamcan

Cyhoeddiad

Cydweithwyr, ganol yr haf rwy'n bwriadu rhyddhau cyfres arall o erthyglau ar ddyluniad systemau ciwio: “Arbrawf VTrade” - ymgais i ysgrifennu fframwaith ar gyfer systemau masnachu. Bydd y gyfres yn archwilio theori ac ymarfer adeiladu cyfnewidfa, arwerthiant a storfa. Ar ddiwedd yr erthygl, rwy’n eich gwahodd i bleidleisio dros y pynciau sydd o ddiddordeb i chi fwyaf.

Dyma'r erthygl olaf yn y gyfres ar geisiadau adweithiol a ddosbarthwyd yn Erlang/Elixir. YN erthygl gyntaf gallwch ddod o hyd i sylfeini damcaniaethol pensaernïaeth adweithiol. Ail erthygl yn dangos y patrymau a'r mecanweithiau sylfaenol ar gyfer adeiladu systemau o'r fath.

Heddiw, byddwn yn codi materion o ddatblygiad y sylfaen cod a phrosiectau yn gyffredinol.

Trefniadaeth gwasanaethau

Mewn bywyd go iawn, wrth ddatblygu gwasanaeth, yn aml mae'n rhaid i chi gyfuno sawl patrwm rhyngweithio mewn un rheolydd. Er enghraifft, mae'n rhaid i'r gwasanaeth defnyddwyr, sy'n datrys y broblem o reoli proffiliau defnyddwyr prosiect, ymateb i geisiadau req-resp ac adrodd am ddiweddariadau proffil trwy pub-sub. Mae'r achos hwn yn eithaf syml: y tu ôl i negeseuon mae un rheolydd sy'n gweithredu rhesymeg y gwasanaeth ac yn cyhoeddi diweddariadau.

Mae'r sefyllfa'n mynd yn fwy cymhleth pan fydd angen i ni weithredu gwasanaeth dosbarthu sy'n goddef diffygion. Gadewch i ni ddychmygu bod y gofynion ar gyfer defnyddwyr wedi newid:

1. nawr dylai'r gwasanaeth brosesu ceisiadau ar 5 nod clwstwr,
2. gallu cyflawni tasgau prosesu cefndir,
3. a hefyd yn gallu rheoli rhestrau tanysgrifio ar gyfer diweddariadau proffil yn ddeinamig.

Sylw: Nid ydym yn ystyried mater storio cyson ac atgynhyrchu data. Gadewch i ni dybio bod y materion hyn wedi'u datrys yn gynharach a bod gan y system haen storio ddibynadwy a graddadwy eisoes, ac mae gan drinwyr fecanweithiau i ryngweithio ag ef.

Mae'r disgrifiad ffurfiol o'r gwasanaeth defnyddwyr wedi dod yn fwy cymhleth. O safbwynt rhaglennydd, mae newidiadau'n fach iawn oherwydd y defnydd o negeseuon. Er mwyn bodloni'r gofyniad cyntaf, mae angen i ni ffurfweddu cydbwyso yn y pwynt cyfnewid req-resp.

Mae'r gofyniad i brosesu tasgau cefndir yn digwydd yn aml. Mewn defnyddwyr, gallai hyn olygu gwirio dogfennau defnyddwyr, prosesu amlgyfrwng wedi'i lawrlwytho, neu gysoni data â chyfryngau cymdeithasol. rhwydweithiau. Mae angen dosbarthu'r tasgau hyn rywsut o fewn y clwstwr a monitro cynnydd y cyflawni. Felly, mae gennym ddau opsiwn datrysiad: naill ai defnyddiwch y templed dosbarthu tasgau o'r erthygl flaenorol, neu, os nad yw'n addas, ysgrifennwch amserlenwr tasgau arferol a fydd yn rheoli'r gronfa o broseswyr yn y ffordd sydd ei hangen arnom.

Mae pwynt 3 yn gofyn am yr estyniad templed tafarn-is. Ac ar gyfer gweithredu, ar ôl creu pwynt cyfnewid tafarn-is, mae angen inni hefyd lansio rheolwr y pwynt hwn o fewn ein gwasanaeth. Felly, mae fel pe baem yn symud y rhesymeg ar gyfer prosesu tanysgrifiadau a dad-danysgrifiadau o'r haen negeseuon i weithrediad defnyddwyr.

O ganlyniad, dangosodd dadelfeniad y broblem, er mwyn bodloni'r gofynion, fod angen i ni lansio 5 achos o'r gwasanaeth ar wahanol nodau a chreu endid ychwanegol - is-reolwr tafarn, sy'n gyfrifol am y tanysgrifiad.
I redeg 5 triniwr, nid oes angen i chi newid y cod gwasanaeth. Yr unig gam gweithredu ychwanegol yw sefydlu rheolau cydbwyso yn y man cyfnewid, y byddwn yn siarad amdano ychydig yn ddiweddarach.
Mae cymhlethdod ychwanegol hefyd: rhaid i'r is-reolwr tafarn a'r trefnydd tasgau arferol weithio mewn un copi. Unwaith eto, mae'n rhaid i'r gwasanaeth negeseuon, fel un sylfaenol, ddarparu mecanwaith ar gyfer dewis arweinydd.

Dewis arweinydd

Mewn systemau gwasgaredig, etholiad arweinydd yw'r weithdrefn ar gyfer penodi un broses sy'n gyfrifol am amserlennu prosesu gwasgaredig rhywfaint o lwyth.

Mewn systemau nad ydynt yn dueddol o ganoli, defnyddir algorithmau cyffredinol sy'n seiliedig ar gonsensws, megis paxos neu rafft.
Gan fod negeseuon yn frocer ac yn elfen ganolog, mae'n gwybod am yr holl reolwyr gwasanaeth - arweinwyr ymgeiswyr. Gall negeseuon benodi arweinydd heb bleidleisio.

Ar ôl cychwyn a chysylltu â'r pwynt cyfnewid, mae pob gwasanaeth yn derbyn neges system #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Os LeaderPid yn cyd-daro â pid broses bresennol, fe'i penodir yn arweinydd, a'r rhestr Servers yn cynnwys yr holl nodau a'u paramedrau.
Ar hyn o bryd mae nod clwstwr newydd yn ymddangos ac mae nod clwstwr gweithredol wedi'i ddatgysylltu, mae pob rheolwr gwasanaeth yn ei dderbyn #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} yn y drefn honno.

Fel hyn, mae'r holl gydrannau'n ymwybodol o'r holl newidiadau, ac mae'r clwstwr yn sicr o gael un arweinydd ar unrhyw adeg benodol.

Cyfryngwyr

Er mwyn gweithredu prosesau prosesu gwasgaredig cymhleth, yn ogystal â phroblemau optimeiddio pensaernïaeth bresennol, mae'n gyfleus defnyddio cyfryngwyr.
Er mwyn peidio â newid y cod gwasanaeth a datrys, er enghraifft, problemau prosesu ychwanegol, llwybro neu logio negeseuon, gallwch chi alluogi triniwr dirprwy cyn y gwasanaeth, a fydd yn cyflawni'r holl waith ychwanegol.

Enghraifft glasurol o optimeiddio tafarn-is yw cymhwysiad dosbarthedig gyda chraidd busnes sy'n cynhyrchu digwyddiadau diweddaru, megis newidiadau pris yn y farchnad, a haen mynediad - gweinyddwyr N sy'n darparu API websocket ar gyfer cleientiaid gwe.
Os penderfynwch yn uniongyrchol, yna mae gwasanaeth cwsmeriaid yn edrych fel hyn:

• mae'r cleient yn sefydlu cysylltiadau â'r platfform. Ar ochr y gweinydd sy'n terfynu'r traffig, mae proses yn cael ei lansio i wasanaethu'r cysylltiad hwn.
• Yng nghyd-destun y broses gwasanaeth, mae awdurdodiad a thanysgrifiad i ddiweddariadau yn digwydd. Mae'r broses yn galw'r dull tanysgrifio ar gyfer pynciau.
• Unwaith y bydd digwyddiad yn cael ei gynhyrchu yn y cnewyllyn, caiff ei gyflwyno i'r prosesau sy'n gwasanaethu'r cysylltiadau.

Gadewch i ni ddychmygu bod gennym ni 50000 o danysgrifwyr i'r pwnc “newyddion”. Mae tanysgrifwyr yn cael eu dosbarthu'n gyfartal ar draws 5 gweinydd. O ganlyniad, bydd pob diweddariad, sy'n cyrraedd y pwynt cyfnewid, yn cael ei ailadrodd 50000 o weithiau: 10000 o weithiau ar bob gweinydd, yn ôl nifer y tanysgrifwyr arno. Ddim yn gynllun effeithiol iawn, iawn?
Er mwyn gwella'r sefyllfa, gadewch i ni gyflwyno dirprwy sydd â'r un enw â'r pwynt cyfnewid. Rhaid i'r cofrestrydd enwau byd-eang allu dychwelyd y broses agosaf yn ôl enw, mae hyn yn bwysig.

Gadewch i ni lansio'r dirprwy hwn ar y gweinyddwyr haen mynediad, a bydd ein holl brosesau sy'n gwasanaethu'r ap websocket yn tanysgrifio iddo, ac nid i'r pwynt cyfnewid tafarn-is-gwreiddiol yn y cnewyllyn. Dim ond yn achos tanysgrifiad unigryw y mae dirprwy yn tanysgrifio i'r craidd ac yn ailadrodd y neges sy'n dod i mewn i'w holl danysgrifwyr.
O ganlyniad, bydd 5 neges yn cael eu hanfon rhwng y gweinyddwyr cnewyllyn a mynediad, yn lle 50000.

Llwybro a chydbwyso

Req-Resp

Yn y gweithredu negeseuon presennol, mae 7 strategaeth dosbarthu ceisiadau:

• default. Anfonir y cais at bob rheolwr.
• round-robin. Mae ceisiadau'n cael eu rhifo a'u dosbarthu'n gylchol rhwng rheolwyr.
• consensus. Mae'r rheolwyr sy'n gwasanaethu'r gwasanaeth wedi'u rhannu'n arweinwyr a chaethweision. Anfonir ceisiadau at yr arweinydd yn unig.
• consensus & round-robin. Mae gan y grŵp arweinydd, ond dosberthir ceisiadau ymhlith yr holl aelodau.
• sticky. Mae'r swyddogaeth hash yn cael ei gyfrifo a'i neilltuo i driniwr penodol. Mae ceisiadau dilynol gyda'r llofnod hwn yn mynd i'r un triniwr.
• sticky-fun. Wrth gychwyn y pwynt cyfnewid, mae'r swyddogaeth gyfrifo hash ar gyfer sticky cydbwyso.
• fun. Yn debyg i hwyl gludiog, dim ond chi all hefyd ei ailgyfeirio, ei wrthod neu ei rag-brosesu.

Gosodir y strategaeth ddosbarthu pan ddechreuir y pwynt cyfnewid.

Yn ogystal â chydbwyso, mae negeseuon yn caniatáu ichi dagio endidau. Edrychwn ar y mathau o dagiau yn y system:

• Tag cysylltiad. Yn eich galluogi i ddeall trwy ba gysylltiad y daeth y digwyddiadau. Defnyddir pan fydd proses rheolydd yn cysylltu â'r un pwynt cyfnewid, ond gyda gwahanol allweddi llwybro.
• Tag gwasanaeth. Yn eich galluogi i gyfuno trinwyr yn grwpiau ar gyfer un gwasanaeth ac ehangu galluoedd llwybro a chydbwyso. Ar gyfer y patrwm req-resp, mae'r llwybro yn llinol. Rydym yn anfon cais i'r pwynt cyfnewid, yna mae'n ei drosglwyddo i'r gwasanaeth. Ond os oes angen i ni rannu'r trinwyr yn grwpiau rhesymegol, yna mae'r hollti'n cael ei wneud gan ddefnyddio tagiau. Wrth nodi tag, bydd y cais yn cael ei anfon at grŵp penodol o reolwyr.
• Tag cais. Yn eich galluogi i wahaniaethu rhwng atebion. Gan fod ein system yn anghydamserol, i brosesu ymatebion gwasanaeth mae angen i ni allu nodi RequestTag wrth anfon cais. Oddiyno byddwn yn gallu deall yr ateb i ba gais y daeth i ni.

Tafarn-is

Ar gyfer tafarn-is mae popeth ychydig yn symlach. Mae gennym bwynt cyfnewid y cyhoeddir negeseuon iddo. Mae'r pwynt cyfnewid yn dosbarthu negeseuon ymhlith tanysgrifwyr sydd wedi tanysgrifio i'r allweddi llwybro sydd eu hangen arnynt (gallwn ddweud bod hyn yn cyfateb i bynciau).

Scalability a goddefgarwch fai

Mae graddadwyedd y system gyfan yn dibynnu ar faint o scalability haenau a chydrannau'r system:

• Caiff gwasanaethau eu graddio drwy ychwanegu nodau ychwanegol at y clwstwr gyda thrinwyr ar gyfer y gwasanaeth hwn. Yn ystod gweithrediad y treial, gallwch ddewis y polisi cydbwyso gorau posibl.
• Mae'r gwasanaeth negeseuon ei hun o fewn clwstwr ar wahân yn cael ei raddio'n gyffredinol naill ai trwy symud pwyntiau cyfnewid sydd wedi'u llwytho'n arbennig i nodau clwstwr ar wahân, neu drwy ychwanegu prosesau dirprwy at ardaloedd o'r clwstwr sydd wedi'u llwytho'n arbennig.
• Mae graddadwyedd y system gyfan fel nodwedd yn dibynnu ar hyblygrwydd y bensaernïaeth a'r gallu i gyfuno clystyrau unigol yn endid rhesymegol cyffredin.

Mae llwyddiant prosiect yn aml yn dibynnu ar symlrwydd a chyflymder graddio. Mae negeseuon yn ei fersiwn gyfredol yn tyfu ynghyd â'r cais. Hyd yn oed os nad oes gennym glwstwr o 50-60 o beiriannau, gallwn droi at ffedereiddio. Yn anffodus, mae pwnc ffedereiddio y tu hwnt i gwmpas yr erthygl hon.

Archebu

Wrth ddadansoddi cydbwyso llwyth, buom eisoes yn trafod dileu swyddi rheolwyr gwasanaeth. Fodd bynnag, rhaid cadw negeseuon hefyd. Mewn achos o ddamwain nod neu beiriant, dylai negeseuon adfer yn awtomatig, ac yn yr amser byrraf posibl.

Yn fy mhrosiectau rwy'n defnyddio nodau ychwanegol sy'n codi'r llwyth rhag ofn y bydd cwymp. Mae gan Erlang weithrediad modd dosbarthedig safonol ar gyfer cymwysiadau OTP. Mae modd dosbarthu yn perfformio adferiad rhag ofn y bydd methiant trwy lansio'r cais a fethwyd ar nod arall a lansiwyd yn flaenorol. Mae'r broses yn dryloyw; ar ôl methiant, mae'r cais yn symud yn awtomatig i'r nod methu. Gallwch ddarllen mwy am y swyddogaeth hon yma.

Cynhyrchiant

Gadewch i ni geisio o leiaf yn fras gymharu perfformiad rabbitmq a'n negeseuon arferol.
Fe wnes i ddod o hyd canlyniadau swyddogol profion rabbitmq gan y tîm Openstack.

Ym mharagraff 6.14.1.2.1.2.2. Mae’r ddogfen wreiddiol yn dangos canlyniad CAST RPC:

Ni fyddwn yn gwneud unrhyw osodiadau ychwanegol i'r cnewyllyn OS neu erlang VM ymlaen llaw. Amodau ar gyfer profi:

• mae erl yn dewis: +A1 +sbtu.
• Mae'r prawf o fewn un nod erlang yn cael ei redeg ar liniadur gyda hen i7 mewn fersiwn symudol.
• Mae profion clwstwr yn cael eu cynnal ar weinyddion sydd â rhwydwaith 10G.
• Mae'r cod yn rhedeg mewn cynwysyddion docwyr. Rhwydwaith yn y modd NAT.

Cod prawf:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

Senario 1: Mae'r prawf yn cael ei redeg ar liniadur gyda hen fersiwn symudol i7. Mae'r prawf, y negeseuon a'r gwasanaeth yn cael eu gweithredu ar un nod mewn un cynhwysydd Docker:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

Senario 2: 3 nod yn rhedeg ar wahanol beiriannau o dan dociwr (NAT).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

Ym mhob achos, nid oedd defnydd CPU yn fwy na 250%

Canlyniadau

Rwy'n gobeithio nad yw'r cylch hwn yn edrych fel dymp meddwl ac y bydd fy mhrofiad o fudd gwirioneddol i ymchwilwyr systemau gwasgaredig ac ymarferwyr sydd ar gychwyn cyntaf adeiladu pensaernïaeth ddosbarthedig ar gyfer eu systemau busnes ac sy'n edrych ar Erlang/Elixir gyda diddordeb. , ond mae gennych amheuon a yw'n werth ...

Shoot Photo @chuttersnap

Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. Mewngofnodios gwelwch yn dda.

Pa bynciau ddylwn i ymdrin â nhw'n fanylach fel rhan o gyfres Arbrawf VTrade?

• Theori: Marchnadoedd, archebion a'u hamseriad: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• Llyfr archebion. Theori ac ymarfer gweithredu llyfr gyda grwpiau

• Delweddu masnachu: Ticiau, bariau, penderfyniadau. Sut i storio a sut i gludo

• Swyddfa gefn. Cynllunio a datblygu. Monitro gweithwyr ac ymchwilio i ddigwyddiadau

• API. Gadewch i ni ddarganfod pa ryngwynebau sydd eu hangen a sut i'w gweithredu

• Storio gwybodaeth: PostgreSQL, Amserlen, Tarantool mewn systemau masnachu

• Adweithedd mewn systemau masnachu

• Arall. Ysgrifennaf yn y sylwadau

Pleidleisiodd 6 o ddefnyddwyr. Ymataliodd 4 o ddefnyddwyr.

Ffynhonnell: hab.com