Najboljših 6 sistemov čakalnih vrst za razvijalce za zaledje

Iščete sistem čakalnih vrst? Ali morda iščete boljšega? Tu so vse informacije, ki jih potrebujete!


Sistemi čakalnih vrst so najbolje varovana skrivnost zalednega razvoja.

Ne da bi poskušal napisati pesem v pohvalo čakalnim sistemom, bi rekel, da mlajši razvijalci zalednih ur postanejo srednjeročni razvijalci, ko se naučijo vključevati čakalne vrste v sistem. Čakalne vrste izboljšajo uporabniško izkušnjo (videli bomo, kako), zmanjšajo kompleksnost in izboljšajo zanesljivost sistema.

Seveda, za zelo preproste spletne aplikacije s skoraj nič prometa in spletnih mest z brošurami so čakalne vrste lahko splošno (ali celo nemogoče jih je namestiti, če ste v običajnem okolju skupnega gostovanja), toda nepridipravi bodo vse koristi od čakalnih vrst sistemov in velikih aplikacij je nemogoče brez vključevanja čakalnih vrst.

Preden začnemo, izjava o omejitvi odgovornosti: če ste že zadovoljni s sistemi čakalnih vrst in želite primerjati različne možnosti, bo naslednjih nekaj uvodnih oddelkov spodbudilo veliko spanja. �� Zato skočite takoj naprej. Uvodni razdelki so namenjeni tistim, ki imajo samo nejasno predstavo o čakalnih sistemih ali so ime samo slišali mimo.

Kaj je sistem čakanja?

Začnimo z razumevanjem, kaj je vrsta.

Čakalna vrsta je struktura podatkov v računalništvu, ki posnemajo resnične čakalne vrste, ki jih vidimo okoli nas. Na primer, če greste na števec vozovnic, boste opazili, da boste morali stati na koncu čakalne vrste, medtem ko bo oseba na začetku čakalne vrste najprej dobila vozovnico. Temu pravimo tudi pojav “prvi pride, prvi streže”. V računalništvu je mogoče v čakalni vrsti pisati programe, ki svoje naloge shranjujejo tako, da jih obdelujejo eno za drugim na isti osnovi, prvi-prvi-streženi.

Upoštevajte, da čakalna vrsta ne opravi nobene dejanske obdelave. To je samo začasno shranjevanje vrst, kjer naloge čakajo, dokler jih nekaj ne pobere. Če se vse to sliši preveč abstraktno, ne skrbite. Gre za abstraktni koncept, vendar bomo v naslednjem razdelku videli jasne primere. ��

Zakaj potrebujete sisteme iz čakalnih vrst?

Brez dolgotrajnega opisa bi rekel, da je glavna potreba po čakalnih sistemih zaradi obdelave ozadja, vzporedne izvedbe in obnovitve po napaki. Poglejmo si to s pomočjo primerov:

Obdelava ozadja

Predpostavimo, da vodite marketinško kampanjo za e-trgovino, kjer je čas bistvenega pomena, in če je vaša aplikacija zgrajena tako, da sproži potrditveno e-poštno sporočilo, preden stranka opravi plačilo in se prikaže stran »hvala«. Če poštni strežnik, s katerim se povezujete, ni, bo spletna stran preprosto umrla, kar bo pretrgalo uporabniško izkušnjo.

Predstavljajte si veliko število zahtev za podporo, ki bi jih dobili! V tem primeru je bolje, da to nalogo pošiljanja po e-pošti potisnete v čakalno vrsto opravil in kupcu pokažete stran za uspeh.

Vzporedna izvedba

Mnogi razvijalci, še posebej tisti, ki večinoma kodirajo enostavnejše aplikacije z nizkim prometom, uporabljajo navade cron za obdelavo v ozadju. To je v redu, dokler velikost vhoda ne postane tako velika, da ga ni mogoče izbrisati. Recimo, da imate nalogo cron, ki zbira analitična poročila in jih pošlje uporabnikom ter da lahko vaš sistem obdeluje 100 poročil na minuto.

Takoj, ko vaša aplikacija raste in začne v povprečju več kot 100 zahtevkov na minuto, začne zaostajati vedno več in nikoli več ne bo mogla dokončati vseh opravil.

V sistemu čakalnih vrst se lahko tej situaciji izognemo tako, da postavimo več delavcev, ki si lahko vsak izberejo službo (vsebuje 100 poročil, ki jih je treba opraviti vsako) in vzporedno delajo, da bi nalogo opravili veliko, veliko prej.

Okrevanje po neuspehu

Na splošno ne razmišljamo o neuspehu kot spletni razvijalci. Nekako jemljemo samoumevno, da bodo naši strežniki in API-ji, ki jih uporabljamo, vedno na spletu. Toda resničnost je drugačna – izpadi omrežja so vse preveč pogosti in odlični API-ji, na katere se zanašate, so morda manjši zaradi težav z infrastrukturo (preden rečete “ne jaz!”, Ne pozabite na ogromen izpad Amazon S3). Če se vrnemo na primer poročanja, če del vaše generacije poročil zahteva, da se povežete z API-jem za plačila in če je povezava prekinjena 2 minuti, kaj se zgodi z 200 poročili, ki niso bila uspešna?

Kljub temu sistemi čakalnih vrst vključujejo veliko režijske stroške. Krivulja učenja je precej strma, ko prehajate na povsem novo domeno, kompleksnosti aplikacije in uvajanja se povečujete in opravil iz čakalnih vrst ne morete vedno nadzorovati s 100% natančnostjo. Kljub temu obstajajo situacije, ko izdelava aplikacije brez čakalnih vrst preprosto ni mogoča.

S tem ne bo več, poglejmo si nekaj najpogostejših možnosti danes med čakalnimi vrstami / sistemi.

Redis

Redis je znana kot trgovina s ključnimi vrednostmi, ki samo shranjuje, posodablja in pridobiva nizov podatkov brez poznavanja strukture podatkov. Čeprav bi bilo to lahko res že prej, danes Redis ima učinkovite in zelo uporabne strukture podatkov, kot so seznami, razvrščeni nabori in celo sistem Pub-Sub, zaradi česar je zelo zaželen za izvajanje čakalnih vrst.

Prednosti Redisa so:

  • Popolnoma v bazi pomnilnika, kar povzroči hitrejše branje / pisanje.
  • Zelo učinkovito: Z lahkoto podpira več kot 100.000 operacij branja / pisanja na sekundo.
  • Zelo prilagodljiva shema obstoja. Lahko pa greste za največjo zmogljivost za ceno morebitne izgube podatkov v primeru okvar ali pa nastavite v popolnoma konzervativni način, da žrtvujete uspešnost za doslednost.
  • Grozdi so podprti izven škatle

Upoštevajte, da Redis nima nobenih abstrakcij za pošiljanje sporočil / čakalnih vrst / obnovitev, zato morate sami uporabiti paket ali zgraditi lahek sistem. Primer je, da je Redis privzeta nastavitev čakalne vrste za okvir PHP Laravel, kjer so načrtovalce uvedli avtorji okvirja.

Učenje Redisa je lahko.

ZajecMQ

Obstaja nekaj subtilnih razlik med Redisom in ZajecMQ, zato jih najprej najprej umaknite.

Najprej ima RabbitMQ bolj specializirano, natančno določeno vlogo, zato je zgrajena tako, da odraža to – sporočanje. Z drugimi besedami, njegova slaba točka je, da deluje kot posrednik med dvema sistemoma, kar ne velja za Redis, ki deluje kot baza podatkov. Kot rezultat, RabbitMQ ponuja še nekaj pripomočkov, ki v Redisu manjkajo: usmerjanje sporočil, ponovni poskusi, porazdelitev obremenitve itd..

Če razmislite o tem, lahko čakalne vrste opravil veljajo tudi za sistem sporočanja, kjer lahko razporejevalnik, delavci in pošiljatelji zaposlitve mislijo na subjekte, ki sodelujejo pri pošiljanju sporočil..

RabbitMQ ima naslednje prednosti:

  • Boljše abstrakcije za pošiljanje sporočil in zmanjšanje dela na ravni aplikacije, če je pošiljanje sporočil tisto, kar potrebujete.
  • Bolj odporen na izpade in izpade električne energije (kot Redis, vsaj privzeto).
  • Podpora za gručo in federacijo za porazdeljene uvajanja.
  • Koristna orodja za upravljanje in spremljanje uvajanja.
  • Podpora za praktično vse ne trivialne programske jezike.
  • Uvajanje z vašim orodjem po izbiri (Docker, kuhar, lutka itd.).

Kdaj uporabljati RabbitMQ? Rekel bi, da je odlična izbira, če veste, da morate uporabiti asinhrono pošiljanje sporočil, vendar se niste pripravljeni spoprijeti z zapleteno zapletenostjo nekaterih drugih čakalnih možnosti na tem seznamu (glejte spodaj).

ActiveMQ

Če ste v podjetniškem prostoru (ali ustvarjate zelo razširjeno in obsežno aplikacijo) in vam ni treba ves čas izumljati kolesa (in na poti delati napake), ActiveMQ je vreden ogleda.

Tukaj je ActiveMQ:

  • Izvaja se v Javi in ​​ima tako zelo lepo integracijo Java (sledi standardu JMS).
  • Podprto je več protokolov: AMQP, MQTT, STOMP, OpenWire itd.
  • Varnost, usmerjanje, prenehanje veljavnosti sporočil, analitika itd.
  • Podpora za priljubljene vzorce porazdeljenih sporočil, ki prihrani čas in drage napake.

To ne pomeni, da je ActiveMQ na voljo samo za Javo. Ima stranke za Python, C / C ++, Node, .Net in druge ekosisteme, zato v prihodnosti ne bi smeli biti pomisleki. Poleg tega je ActiveMQ zasnovan na popolnoma odprtih standardih, izdelava lastnih lahkih strank pa bi morala biti enostavna.

Upoštevajte, da je ActiveMQ samo posrednik in ne vključuje zaledja. Za shranjevanje sporočil boste še vedno morali uporabiti enega od podprtih zapor. Sem ga vključil, ker ni vezan na določen programski jezik (kot druge priljubljene rešitve, kot so Celery, Sidekiq itd.)

Amazon MQ

Amazon MQ si tu zasluži hitro, a pomembno omembo. Če menite, da je ActiveMQ idealna rešitev za vaše potrebe, vendar se ne želite ukvarjati z gradnjo in vzdrževanjem infrastrukture sami, Amazon MQ ponuja upravljano storitev, da to stori. Podpira vse protokole, ki jih ima ActiveMQ – razlike v značilnostih sploh ni – saj sam ActiveMQ uporablja pod površino.

Prednost je ta, da je to upravljana storitev, zato vam ni treba skrbeti za nič drugega kot za njeno uporabo. Še bolj smiselno je za tiste uvajanja, ki so na AWS, saj lahko druge storitve in ponudbe izkoristite neposredno znotraj svoje namestitve (na primer hitrejše prenose podatkov).

Amazon SQS

Ne moremo pričakovati, da bo Amazon mirno sedel, ko gre za kritične koščke infrastrukture, kajne? ��

In tako tudi imamo Amazon SQS, ki je popolnoma gosti, preprosta storitev čakalnih vrst (dobesedno) znanega velikana AWS. Še enkrat so pomembne nežne razlike, zato upoštevajte, da SQS nima koncepta pošiljanja sporočil. Tako kot Redis je tudi preprost zaledje za sprejemanje in distribucijo delovnih mest v čakalnih vrstah.

Torej, kdaj bi želeli uporabljati Amazon SQS? Tu je nekaj razlogov:

  • Ste oboževalec AWS in se ne dotaknete ničesar drugega (iskreno! Veliko ljudi je tam podobnih in mislim, da s tem ni nič narobe).
  • Potrebujete gostovano rešitev, zato zagotovite, da je stopnja odpovedi enaka nič in nobeno opravilo ni izgubljeno.
  • Ne želite oblikovati grozda in ga morate nadzorovati sami. Ali še huje, sestaviti morate orodja za spremljanje, ko bi lahko čas uporabljali za produktiven razvoj.
  • Že imate znatne naložbe v platformo AWS in ostati brez zaklenjene je poslovno smiselno.
  • Želite osredotočen in preprost sistem čakanja v čakalnem vrstnem redu, brez katerega koli od prahu, povezanega s pošiljanjem sporočil, protokoli in kaj podobnega.

Na splošno je Amazon SQS dobra izbira za vse, ki želijo v svoj sistem vključiti čakalne vrste delovnih mest in jim ni treba skrbeti za namestitev / spremljanje stvari sami.

Beanstalkd

Beanstalkd obstaja že dolgo in je hitro preizkušen, hiter in enostaven začasni program za čakalne vrste. Obstaja nekaj značilnosti Beanstalkd, zaradi katerih se znatno razlikuje od Redisa:

  • To je natančno sistem čakalnih vrst in nič drugega. Vanj potisnete delovna mesta, ki jih pozneje potegnejo delavci. Če ima vaša aplikacija še tako majhno potrebo po pošiljanju sporočil, se želite izogniti Beanstalkd-u.
  • Ni naprednih podatkovnih struktur, kot so nabori, prednostne čakalne vrste itd.
  • Beanstalkd se imenuje čakalna vrsta First In, First Out (FIFO). Ni možnosti, da bi si delovna mesta uredili prednostno.
  • Ni možnosti za združevanje v skupine.

Vse to je povedalo, da Beanstalkd ustvarja gladek in hiter sistem čakalnih vrst za preproste projekte, ki živijo na enem strežniku. Za mnoge je hitrejši in stabilnejši od Redisa. Torej, če imate vprašanja z Redisom, ki ga preprosto ne morete rešiti ne glede na vse, in vaše potrebe so preproste, Beanstalkd je vredno poskusiti.

Zaključek

Če ste prebrali do zdaj (ali ste dosegli tukaj berejo branje ��), obstaja zelo dobra možnost, da vas zanimajo sistemi čakalnih vrst ali jih potrebujete. V tem primeru vam bo seznam na tej strani dobro služil, razen če iščete sistem čakalnih vrst za jezik / okvir.

Želim vam povedati, da je čakalna vrsta preprosta in stoodstotno zanesljiva, vendar ni. Nered je in ker je vse v ozadju in se dogaja zelo hitro (napake lahko ostanejo neopažene in postanejo zelo drage). Kljub temu so čakalne vrste izredno potrebne, in ugotovili boste, da so močno orožje (morda celo najmočnejše) v vašem arzenalu. Vso srečo! ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map