🥇 Avakirina blokên serîlêdanên belavkirî. Nêzîkbûna duyemîn

Daxûyanî

Hevalno, di nîvê havînê de ez plan dikim ku rêzek gotarên din li ser sêwirana pergalên rêzê derxim: "Ezmûna VTrade" - hewldanek ji bo nivîsandina çarçoveyek ji bo pergalên bazirganiyê. Rêze dê teorî û pratîka avakirina danûstendin, mezad û firotgehekê vekolîne. Di dawiya gotarê de, ez we vedixwînim ku hûn ji bo mijarên ku herî zêde we eleqedar dikin deng bidin.

Ev gotara dawîn a rêzenivîsê ye li ser sepanên reaktîf ên belavbûyî yên li Erlang/Elixir. LI gotara yekem hûn dikarin bingehên teorîk ên mîmariya reaktîf bibînin. Gotara duyemîn qalibên bingehîn û mekanîzmayên avakirina sîstemên weha nîşan dide.

Îro em ê mijarên pêşveçûna bingeha kodê û projeyan bi gelemperî ragihînin.

Rêxistina xizmetên

Di jiyana rast de, dema ku karûbarek pêşdixe, hûn pir caran neçar in ku çend şêwazên danûstendinê di yek kontrolker de bihev bikin. Mînakî, karûbarê bikarhêneran, ku pirsgirêka birêvebirina profîlên bikarhêner ên projeyê çareser dike, divê bersivê bide daxwazên req-resp û nûvekirinên profîlê bi pub-sub rapor bike. Ev doz pir hêsan e: li pişta şandinê yek kontrolkerek heye ku mantiqa karûbarê bicîh tîne û nûvekirinan diweşîne.

Dema ku pêdivî ye ku em karûbarek belavkirî ya berbelav-tehmûl bicîh bînin rewş aloztir dibe. Ka em bifikirin ku pêdiviyên ji bo bikarhêneran hatine guhertin:

naha divê karûbar daxwazên li ser 5 girêkên komê bişopîne,
karibe karên hilberandina paşerojê bike,
û di heman demê de ji bo nûvekirina profîlan lîsteyên abonetiyê bi dînamîk birêve bibin.

Agahkişîn: Em pirsgirêka hilanînê û dubarekirina daneya hevgirtî nahesibînin. Ka em bihesibînin ku ev pirsgirêk berê hatine çareser kirin û pergalê jixwe xwedan qatek hilanînê ya pêbawer û berbelav e, û rêvebiran mekanîzmayên ku pê re têkilî daynin hene.

Danasîna fermî ya karûbarê bikarhêneran tevlihevtir bûye. Ji nêrîna bernamenûsek, ji ber karanîna mesajê guheztin hindik in. Ji bo têrkirina hewcedariya yekem, pêdivî ye ku em hevsengiyê li xala danûstendina req-resp mîheng bikin.

Pêwîstiya pêvajoyên karên paşerojê pir caran pêk tê. Di bikarhêneran de, ev dibe ku kontrolkirina belgeyên bikarhêner, hilberandina multimedia ya dakêşandî, an hevrêzkirina daneyan bi medyaya civakî re. torên. Pêdivî ye ku ev peywir bi rengekî di nav komê de werin dabeş kirin û pêşkeftina darvekirinê were şopandin. Ji ber vê yekê, me du vebijarkên çareseriyê hene: an şablona belavkirina peywirê ya ji gotara berê bikar bînin, an jî, heke ew negunca be, nexşeyek peywirek xwerû binivîsin ku dê hewza pêvajoyan bi awayê ku em hewce bike bi rêve bibe.

Xala 3 pêvekirina şablonê pub-sub hewce dike. Û ji bo bicîhkirinê, piştî afirandina nuqteyek danûstendinê ya pub-sub, pêdivî ye ku em di hundurê karûbarê xwe de kontrolkerê vê xalê jî bidin destpêkirin. Bi vî rengî, wusa dixuye ku em mantiqa hilberandina aboneyan û betalkirina ji qata mesajê ber bi pêkanîna bikarhêneran ve digerînin.

Wekî encamek, hilweşandina pirsgirêkê destnîşan kir ku ji bo ku em hewcedariyên bicîh bînin, pêdivî ye ku em 5 nimûneyên karûbarê li ser girêkên cihêreng bidin destpêkirin û saziyek din biafirînin - kontrolkerek pub-sub, berpirsiyarê aboneyê.
Ji bo ku hûn 5 hilberan bimeşînin, hûn ne hewce ne ku koda karûbarê biguhezînin. Yekane çalakiya pêvek sazkirina qaîdeyên hevsengiyê li xala danûstendinê ye, ku em ê hinekî paşê li ser biaxivin.
Di heman demê de tevliheviyek din jî heye: kontrolkerê pub-sub û nexşerêya peywira xwerû divê di kopiyek yekane de bixebitin. Dîsa, karûbarê peyamberdanê, wekî bingehek bingehîn, divê mekanîzmayek ji bo hilbijartina serokek peyda bike.

Hilbijartina Rêberê

Di pergalên belavbûyî de, hilbijartina serok prosedurek e ji bo tayînkirina pêvajoyek yekane ku berpirsiyar e ji bo plansazkirina pêvajoyek belavkirî ya hin baran.

Di pergalên ku mêldarê navendîbûnê ne, algorîtmayên gerdûnî û lihevhatî, wekî paxos an raft, têne bikar anîn.
Ji ber ku mesajkirin broker û hêmanek navendî ye, ew bi hemî kontrolkerên karûbarê - serokên berendam dizane. Mesaj dikare bêyî dengdanê serokek destnîşan bike.

Piştî destpêkirin û girêdana bi xala danûstendinê, hemî karûbar peyamek pergalê digirin #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Ger LeaderPid lihevhatî ye pid pêvajoya niha, ew wek serkirde, û lîsteya Servers hemî girêk û pîvanên wan dihewîne.
Di vê gavê de yek nû xuya dibe û girêkek komê ya xebatê qut dibe, hemî kontrolkerên karûbarê werdigirin #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} bi awayekî

Bi vî rengî, hemî pêkhate ji hemî guhertinan haydar in, û komxebat garantî ye ku di her demê de yek serokek hebe.

Navbeynkar

Ji bo pêkanîna pêvajoyên pêvajoyên belavkirî yên tevlihev, û her weha di pirsgirêkên xweşbînkirina mîmariya heyî de, karanîna navbeynkaran hêsan e.
Ji bo ku hûn koda karûbarê neguhezînin û, mînakî, pirsgirêkên pêvajoyek zêde, rêkirin an têketinê peyaman çareser nekin, hûn dikarin berî karûbarê kargêrek proxy çalak bikin, ku dê hemî karên zêde pêk bîne.

Mînaka klasîk a xweşbînkirina pub-sub serîlêdanek belavkirî ye ku bi bingehek karsaziyê ve bûyerên nûvekirinê çêdike, wek guheztinên bihayê li sûkê, û qatek gihîştinê - N server ku ji bo xerîdarên malperê API-ya websocket peyda dike.
Ger hûn bi serê xwe biryar bidin, wê hingê karûbarê xerîdar bi vî rengî xuya dike:

xerîdar pêwendiyan bi platformê re saz dike. Li aliyê servera ku seyrûseferê diqede, pêvajoyek ji bo karûbarê vê girêdanê tê destpêkirin.
Di çarçoveya pêvajoya karûbarê de, destûr û abonetiya nûvekirinê pêk tê. Pêvajo ji bo mijaran rêbaza abonetiyê vedibêje.
Dema ku bûyerek di kernelê de çêbibe, ew ji pêvajoyên ku girêdan re xizmet dikin tê radest kirin.

Em bifikirin ku 50000 aboneyên me yên mijara "nûçe" hene. Abonet li ser 5 serveran bi rengek wekhev têne belav kirin. Wekî encamek, her nûvekirin, ku digihîje xala danûstendinê, dê 50000 carî were dubare kirin: 10000 carî li ser her serverê, li gorî hejmara aboneyên li ser wê. Ne planek pir bi bandor, rast?
Ji bo baştirkirina rewşê, werin em proxyek ku heman navî wekî xala danûstendinê heye destnîşan bikin. Pêdivî ye ku qeydkarê navên gerdûnî bikaribe bi navê pêvajoya herî nêzîk vegerîne, ev girîng e.

Werin em vê proxy-ê li ser pêşkêşkerên qata gihîştinê bidin destpêkirin, û hemî pêvajoyên me yên ku ji api-ya websocket re xizmet dikin dê bibin abone, û ne li xala pevguhertina pub-sub ya orîjînal a di kernelê de. Proxy tenê di doza abonetiyek bêhempa de di bingehê de tê abon kirin û peyama hatî ji hemî aboneyên xwe re dubare dike.
Di encamê de, li şûna 5 dê 50000 peyam di navbera kernel û pêşkêşkerên gihîştinê de werin şandin.

Routing û hevseng

Req-Resp

Di pêkanîna mesajên heyî de, 7 stratejiyên belavkirina daxwaznameyê hene:

default. Daxwaz ji hemû kontrolkeran re tê şandin.
round-robin. Daxwaz têne jimartin û bi çerxa di navbera kontrolkeran de têne belav kirin.
consensus. Kontrolkerên ku xizmetê dikin di nav serok û koleyan de têne dabeş kirin. Daxwaz tenê ji rêber re têne şandin.
consensus & round-robin. Serkirdeyekî komê heye, lê daxwaz li hemû endaman tên belavkirin.
sticky. Fonksîyona hash tê hesibandin û ji hilberek taybetî re tête destnîşan kirin. Daxwazên paşerojê yên bi vê îmzeyê diçin heman destekar.
sticky-fun. Dema destpêkirina xala danûstendinê, fonksiyona hesabkirina hash ji bo sticky hevsengkirin.
fun. Bişibi-kêfxweş, tenê hûn dikarin wê ji nû ve verast bikin, red bikin an pêş-pêvajoyê bikin.

Dema ku xala danûstendinê dest pê dike stratejiya belavkirinê tête danîn.

Digel hevsengkirinê, şandina peyaman dihêle hûn saziyan etîket bikin. Ka em li cûreyên tagên pergalê binêrin:

Etîketa girêdanê. Destûrê dide we ku hûn fêm bikin ka bûyer bi kîjan pêwendiyê hatine. Dema ku pêvajoyek kontrolker bi heman xala danûstendinê ve, lê bi bişkojkên rêvekirinê yên cihêreng ve tê bikar anîn.
Tag xizmetê. Destûrê dide we ku ji bo yek karûbarek destanan di nav koman de berhev bikin û kapasîteyên rêveçûn û hevsengiyê berfireh bikin. Ji bo şêwaza req-resp, rêkirin rêzek e. Em daxwazek ji xala danûstendinê re dişînin, dûv re ew ji karûbarê re derbas dike. Lê heke hewce bike ku em hilberan li komên mentiqî veqetînin, wê hingê veqetandin bi karanîna nîşanan pêk tê. Dema ku tagek diyar dike, daxwaz dê ji komek taybetî ya kontrolkeran re were şandin.
Daxwaza tagê. Destûrê dide we ku hûn bersivan ji hev cuda bikin. Ji ber ku pergala me asînkron e, ji bo ku em bersivên karûbarê bişopînin hewce ne ku dema ku daxwazek dişînin em karibin RequestTag diyar bikin. Ji wê em ê karibin bersiva kîjan daxwazê ji me re hatiye fêm bikin.

Pub-sub

Ji bo pub-sub her tişt hinekî hêsan e. Me xalek danûstendinê heye ku peyam têne weşandin. Xala danûstendinê mesajên di nav aboneyên ku bûne abone li mifteyên rêwîtiyê yên ku ji wan re hewce ne belav dike (em dikarin bibêjin ku ev bi mijaran re wekhev e).

Scalability û tolerasyona xeletiyê

Mezinbûna pergalê bi tevahî bi astê pîvandina qat û pêkhateyên pergalê ve girêdayî ye:

Karûbar ji bo vê karûbarê bi lêzêdekirina girêkên pêvek li komê bi hilkeran ve têne pîvandin. Di dema xebata ceribandinê de, hûn dikarin polîtîkaya hevsengiya çêtirîn hilbijêrin.
Karûbarê şandina peyaman bixwe di nav komek cûda de bi gelemperî an bi veguheztina xalên danûstendinê yên bi taybetî barkirî berbi girêkên komê veqetandî, an jî bi lê zêdekirina pêvajoyên proxy li deverên bi taybetî yên barkirî yên komê tê pîvandin.
Mezinbûna tevahiya pergalê wekî taybetmendiyek bi nermbûna mîmariyê û jêhatîbûna berhevkirina komikên kesane di nav hebûnek mentiqî ya hevpar ve girêdayî ye.

Serkeftina projeyek pir caran bi sadebûn û leza pîvandinê ve girêdayî ye. Mesajkirin di guhertoya xweya heyî de bi serîlêdanê re mezin dibe. Ger 50-60 makîneyên me kêm bin jî em dikarin federasyonê bikin. Mixabin mijara federasyonê li derveyî çarçoveya vê gotarê ye.

Alîdanînî

Dema ku hevsengiya barkirinê analîz dikin, me berê li ser zêdebûna kontrolkerên karûbarê nîqaş kir. Lêbelê, pêdivî ye ku peyam jî were veqetandin. Di bûyera qezayek girêk an makîneyê de, divê peyam bixweber vegere, û di demek herî kin de.

Di projeyên xwe de ez girêkên pêvek bikar tînim ku di rewşek hilweşînê de bargiraniyê hildigirin. Erlang ji bo serîlêdanên OTP-ê pêkanîna moda belavkirî ya standard heye. Moda belavkirî di rewşek têkçûnê de bi destpêkirina serîlêdana têkçûyî li ser girêkek din a ku berê hatî destpêkirin başbûnê pêk tîne. Pêvajo şefaf e; piştî têkçûnekê, serîlêdan bixweber diçe girêka têkçûyî. Hûn dikarin li ser vê fonksiyonê bêtir bixwînin vir.

Berhemdariyê

Ka em hewl bidin ku bi kêmanî performansa rabbitmq û mesajên xweya xwerû bi qasî hev bidin ber hev.
min dît encamên fermî ceribandina rabbitmq ji tîmê openstack.

Di paragrafa 6.14.1.2.1.2.2 de. Belgeya orîjînal encama RPC CAST nîşan dide:

Em ê ji berê de mîhengên zêde li ser kernel OS-ê an erlang VM nekin. Mercên ji bo ceribandinê:

erl tercîh dike: +A1 +sbtu.
Testa di nav yek girêka erlang de li ser laptopek bi i7-ya kevn di guhertoya mobîl de tê meşandin.
Testên komê li ser serverên bi torgilokek 10G têne kirin.
Kod di konteynerên docker de dimeşe. Tora di moda NAT de.

Koda testê:

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.

Senaryo 1: Test li ser laptopek bi guhertoyek kevn a mobîl i7 tê meşandin. Test, şandin û karûbar li ser yek girêkek di yek konteynirek Docker de têne darve kirin:

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)

Senaryo 2: 3 nod li ser makîneyên cihêreng ên di bin docker (NAT) de dixebitin.

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)

Di hemî rewşan de, karanîna CPU ji% 250 derbas nebû

Encam

Hêvîdarim ku ev çerx ne mîna çolê hiş û serpêhatiya min be, hem ji lêkolînerên pergalên belavbûyî û hem jî ji pisporên ku di destpêka avakirina mîmariyên belavbûyî de ji bo pergalên karsaziya xwe ne û bi balkêşî li Erlang/Elixir dinêrin, sûdmendiyek rast be. , lê guman heye gelo ew hêja ye ...

photo @chuttersnap

Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. Têketinji kerema xwe.

Divê ez kîjan mijaran wekî beşek ji rêzikên Ezmûna VTrade bi hûrgulî vegirim?

Teorî: Bazar, ferman û dema wan: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
Pirtûka fermanan. Teorî û pratîka pêkanîna pirtûkek bi koman
Visualîzasyona bazirganiyê: Tik, bars, biryar. Meriv çawa hilanîn û meriv çawa zeliqand
Backoffice. Plankirin û pêşveçûn. Şopandina karmend û lêkolîna bûyerê
API. Ka em fêhm bikin ka kîjan navgîn hewce ne û meriv wan çawa bicîh tîne
Hilberîna agahdariyê: PostgreSQL, Timescale, Tarantool di pergalên bazirganiyê de
Reaktîvîteya di pergalên bazirganiyê de
Yên din. Ez ê di şîroveyan de binivîsim

6 bikarhêneran deng dan. 4 bikarhêner betal bûn.

Source: www.habr.com

Avakirina blokên serîlêdanên belavkirî. Nêzikbûna duyemîn