Cele mai bune 6 sisteme de așteptare pentru dezvoltatorii Backend

Căutați un sistem în coadă? Sau poate căutați unul mai bun? Iată toate informațiile de care aveți nevoie!


Sistemele de coadă sunt secretul cel mai bine păstrat al dezvoltării backend.

Fără a încerca să scriu o poezie laudând sistemele de coadă, aș spune că un dezvoltator backend junior devine un dezvoltator backend de nivel mediu, după ce a învățat să integreze cozi în sistem. Cozele îmbunătățesc experiența clienților (vom vedea cum), reduc complexitatea și îmbunătățim fiabilitatea într-un sistem.

Sigur, pentru aplicații web foarte simple, cu trafic aproape de zero și site-uri web cu broșuri, cozile pot fi în general (sau chiar imposibil de instalat dacă sunteți într-un mediu tipic de găzduire partajată), dar aplicațiile non-banale vor câștiga toate din coada sistemele și aplicațiile mari sunt imposibile fără a fi implicate în coadă.

Înainte de a începe, o exonerare: dacă sunteți deja confortabil cu sistemele de coadă și doriți să comparați diversele opțiuni, următoarele secțiuni introductive vor induce un somn important. �� Așadar, nu ezitați să sari chiar înainte. Secțiunile introductive sunt destinate celor care au doar o idee nebună de sisteme de coadă sau doar au auzit numele în trecere.

Ce este un sistem de coadă?

Să începem prin a înțelege ce este o coadă.

O coadă este o structură de date în informatică care imită, bine, cozile din lumea reală pe care le vedem în jurul nostru. Dacă mergeți la un contor de bilete, de exemplu, veți observa că va trebui să stați la sfârșitul cozii, în timp ce persoana de la începutul cozii va primi biletul întâi. Este ceea ce numim și „primul venit, primul servit”. În domeniul informaticii, este posibil să scrie programe care își stochează sarcinile de acest fel într-o coadă, procesându-le una câte una pe aceeași bază pentru primul venit.

Rețineți că coada nu face în sine nici o prelucrare reală. Este doar stocarea temporară de felul în care sarcinile așteaptă până când sunt preluate de ceva. Dacă toate acestea sună un pic prea abstract, nu vă faceți griji. Este un concept abstract, dar vom vedea exemple clare în secțiunea următoare. ��

De ce ai nevoie de sisteme de coadă?

Fără a intra într-o descriere foarte lungă, aș spune că nevoia principală a sistemelor de așteptare este din cauza procesării în fundal, a execuției paralele și a recuperării din eșec. Să ne uităm la acestea cu ajutorul unor exemple:

Prelucrare de fundal

Să presupunem că derulați o campanie de marketing e-commerce unde timpul este esențial și că aplicația dvs. este construită astfel încât să declanșeze un e-mail de confirmare chiar înainte ca clientul să finalizeze plata și să i se afișeze pagina „mulțumesc”. În cazul în care serverul de poștă la care vă conectați este redus, pagina web va muri, provocând experiența utilizatorului.

Imaginează-ți numărul mare de solicitări de asistență pe care le vei primi! În acest caz, este mai bine să împingeți această sarcină de trimitere prin e-mail către o coadă de joburi și să arătați clientului pagina de succes.

Execuție paralelă

Mulți dezvoltatori, în special cei care utilizează în principal aplicații de cod mai simple, cu trafic redus, au obiceiul de a utiliza joburi cron pentru procesarea în fundal. Acest lucru este în regulă până când dimensiunea intrării crește atât de mare încât nu poate fi șters. De exemplu, să presupunem că aveți o lucrare cron care compila rapoarte analitice și le trimite prin e-mail către utilizatori și că sistemul dvs. poate procesa 100 de rapoarte pe minut.

De îndată ce aplicația dvs. crește și începe să primească mai mult de 100 de solicitări pe minut, aceasta va începe să rămână în urmă din ce în ce mai mult și nu va putea niciodată să finalizeze toate lucrările.

Într-un sistem în coadă, această situație poate fi evitată prin crearea mai multor lucrători, care pot alege fiecare un loc de muncă (care conține 100 de rapoarte care trebuie făcute fiecare) și să lucreze în paralel pentru a termina sarcina mult mai repede..

Recuperarea din eșec

În general, nu ne gândim la eșec ca dezvoltatori web. Am considerat că serverele și API-urile pe care le folosim vor fi întotdeauna online. Dar realitatea este diferită – întreruperile din rețea sunt prea frecvente, iar API-urile excelente pe care te bazezi s-ar putea reduce din cauza problemelor de infrastructură (înainte de a spune „nu eu!”, Nu uitați de întrerupere masivă Amazon S3). Așadar, revenind la exemplul de raportare, dacă o parte din generarea de rapoarte vă solicită să vă conectați la API-ul de plăți și că conexiunea este redusă timp de 2 minute, ce se întâmplă cu cele 200 de rapoarte care nu au reușit?

Totuși, sistemele de coadă implică cheltuieli generale considerabile. Curba de învățare este destul de abruptă pe măsură ce pășești într-un domeniu cu totul nou, complexitatea aplicației și a implementării tale crește, iar locurile de muncă în coadă nu pot fi întotdeauna controlate cu o precizie de 100%. Acestea fiind spuse, există situații când construirea unei aplicații fără cozi nu este posibilă.

Cu acest lucru, să aruncăm o privire la unele dintre opțiunile comune dintre backenduri / sisteme de astăzi.

Redis

Redis este cunoscut ca un magazin cu valoare cheie care doar stochează, actualizează și preia șiruri de date fără cunoștințe despre structura datelor. Deși acest lucru ar fi putut fi adevărat mai devreme, Redis are astăzi structuri de date eficiente și foarte utile, cum ar fi liste, seturi sortate și chiar un sistem Pub-Sub, ceea ce îl face extrem de dorit pentru implementările de coadă..

Avantajele Redis sunt:

  • Baza de date completă în memorie, ceea ce duce la citirea / scrierea mai rapidă.
  • Foarte eficient: poate suporta cu ușurință peste 100.000 de operațiuni de citire / scriere pe secundă.
  • Schema de persistență extrem de flexibilă. Puteți opta pentru performanțe maxime cu costul posibilelor pierderi de date în cazul eșecurilor sau configurați în mod complet conservator pentru a sacrifica performanța pentru consecvență.
  • Clusterele au fost sprijinite din cutie

Vă rugăm să rețineți că Redis nu are nicio abținere de mesaje / coadă / recuperare, deci trebuie să utilizați un pachet sau să creați singur un sistem ușor. Un exemplu este faptul că Redis este backendul cozii implicit pentru cadrul PHP Laravel, unde un planificator a fost implementat de către autorii cadrului.

Învățarea Redis este usor.

RabbitMQ

Există câteva diferențe subtile între Redis și RabbitMQ, deci să le scoatem din prima cale.

În primul rând, RabbitMQ are un rol mai specializat, bine definit, și astfel a fost creat pentru a reflecta asta – mesagerie. Cu alte cuvinte, punctul său dulce este să acționeze ca un intermediar între două sisteme, ceea ce nu este cazul pentru Redis, care acționează ca o bază de date. Drept urmare, RabbitMQ oferă încă câteva facilități care lipsesc din Redis: rutare de mesaje, încercări, distribuție de încărcare, etc..

Dacă vă gândiți la asta, cozile de sarcini pot fi gândite și ca un sistem de mesagerie, în care programatorul, lucrătorii și „expeditorii” postului pot fi gândiți la entitățile care participă la transmiterea mesajelor.

RabbitMQ are următoarele avantaje:

  • Abstracții mai bune pentru transmiterea mesajelor, reducerea activității la nivel de aplicație dacă trecerea mesajelor este ceea ce aveți nevoie.
  • Mai rezistent la întreruperile și întreruperile de energie (decât Redis, cel puțin implicit).
  • Sprijin pentru cluster și federație pentru implementări distribuite.
  • Instrumente utile pentru gestionarea și monitorizarea implementărilor.
  • Suport pentru practic toate limbajele de programare non-banale de acolo.
  • Desfășurarea cu instrumentul ales (Docker, Chef, marionetă etc.).

Când să folosiți RabbitMQ? Aș spune că este o alegere excelentă atunci când știi că trebuie să folosești trecerea asincronă a mesajelor, dar nu ești pregătit să abordezi complexitatea falnică a unora dintre celelalte opțiuni ale cozii din această listă (vezi mai jos).

ActiveMQ

Dacă vă aflați în spațiul întreprinderii (sau construiți o aplicație la scară largă distribuită și pe scară largă) și nu doriți să reinventați roata tot timpul (și să greșiți pe parcurs), ActiveMQ merită aruncată o privire.

Iată locul în care ActiveMQ excelează:

  • Este implementat în Java și, de asemenea, are o integrare Java corectă (respectă standardul JMS).
  • Mai multe protocoale acceptate: AMQP, MQTT, STOMP, OpenWire, etc.
  • Gestionează securitatea, rutarea, expirarea mesajelor, analitice etc., din cutie.
  • Asistență la cuptor pentru tiparele populare de mesagerie distribuite, economisind timp și greșeli costisitoare.

Asta nu înseamnă că ActiveMQ este disponibil doar pentru Java. Are clienți pentru ecosistemele Python, C / C ++, Node, .Net și alte sisteme, deci nu ar trebui să existe îngrijorări pentru o posibilă colaps în viitor. În plus, ActiveMQ este bazat pe standarde complet deschise, iar construirea propriilor clienți ușori ar trebui să fie ușoară.

Toate cele spuse și făcute, rețineți că ActiveMQ este doar un broker și nu include un backend. Încă trebuie să utilizați unul dintre backend-urile acceptate pentru a stoca mesajele. L-am inclus aici, deoarece nu este legat de un anumit limbaj de programare (cum ar fi alte soluții populare, cum ar fi Celery, Sidekiq etc.)

Amazon MQ

Amazon MQ merită o mențiune rapidă, dar importantă aici. Dacă credeți că ActiveMQ este soluția ideală pentru nevoile dvs., dar nu doriți să vă ocupați de construcție și să întrețineți singuri infrastructura, Amazon MQ oferă un serviciu gestionat pentru a face acest lucru. Acceptă toate protocoalele pe care ActiveMQ le face – nu există nicio diferență în ceea ce privește caracteristicile – deoarece folosește ActiveMQ însuși sub suprafață.

Avantajul este că este un serviciu gestionat, deci nu trebuie să vă faceți griji pentru altceva decât să îl utilizați. Are și mai mult sens pentru acele implementări care sunt pe AWS, deoarece puteți utiliza alte servicii și oferte direct din cadrul implementării dvs. (transferuri de date mai rapide, de exemplu).

Amazon SQS

Nu ne putem aștepta ca Amazon să stea în liniște atunci când vine vorba de piese de infrastructură critice, nu? ��

Și așa avem Amazon SQS, care este un serviciu complet de coadă simplu găzduit (destul de literal) de cunoscutul gigant AWS. Încă o dată, diferențele subtile sunt importante, așa că rețineți că SQS nu are conceptul de transmitere a mesajelor. Ca și Redis, este un simplu backend pentru acceptarea și distribuirea de locuri de muncă în cozi.

Deci, când doriți să folosiți Amazon SQS? Iată câteva motive:

  • Sunteți fan AWS și nu veți atinge nimic altceva (sincer, există mulți oameni acolo, și cred că nu este nimic în neregulă cu asta).
  • Aveți nevoie de o soluție găzduită, astfel încât să vă asigurați că rata de eșec este zero și niciunul dintre locurile de muncă nu se pierde.
  • Nu doriți să construiți un cluster și trebuie să îl monitorizați singur. Sau mai rău, trebuie să construiți instrumente de monitorizare atunci când ați putea folosi acel timp pentru a face dezvoltare productivă.
  • Aveți deja investiții substanțiale în platforma AWS și rămâneți blocat în sensul afacerilor.
  • Vrei un sistem concentrat, simplu de coadă, fără niciun fel de flocuri asociate cu transmiterea mesajelor, protocoale și ce nu.

În total, Amazon SQS este o alegere solidă pentru oricine dorește să încorporeze cozile de locuri de muncă în sistemul lor și să nu fie nevoit să vă faceți griji despre instalarea / monitorizarea lucrurilor.

Beanstalkd

Beanstalkd a fost în jur de mult timp și este un back-test rapid, ușor de testat pentru luptă. Există câteva caracteristici ale Beanstalkd care îl fac să difere considerabil de Redis:

  • Este strict un sistem de cozi de locuri de muncă și nimic altceva. Îi împingi locurile de muncă, care sunt atrase ulterior de lucrătorii. Așadar, dacă aplicația dvs. are chiar o mică nevoie de transmiterea mesajelor, nu doriți să o evitați pe Beanstalkd.
  • Nu există structuri de date avansate precum seturi, cozi de prioritate, etc.
  • Beanstalkd este ceea ce se numește coadă First In, First Out (FIFO). Nu există nicio modalitate de a aranja lucrările în funcție de prioritate.
  • Nu există opțiuni pentru clustering.

Toate acestea au spus că Beanstalkd creează un sistem de coadă ușor și rapid pentru proiecte simple care trăiesc pe un singur server. Pentru mulți, este mai rapid și mai stabil decât Redis. Deci, dacă aveți probleme Cu Redis, că doar nu poți părea că rezolvă indiferent de lucruri și nevoile tale sunt simple, Beanstalkd merită încercat.

Concluzie

Dacă ați citit atât de departe (sau ați ajuns aici la citirea dezgolită ��), există o șansă foarte bună să vă interesați sistemele de așteptare sau aveți nevoie de unul. Dacă da, lista de pe această pagină vă va servi bine, cu excepția cazului în care căutați un sistem de coadă specific limbii / cadrului.

Aș dori să vă pot spune că coada este simplă și 100% fiabilă, dar nu este. Este dezordonat și, din moment ce totul se află în fundal și se întâmplă foarte repede (greșelile pot trece neobservate și pot deveni foarte costisitoare). Totuși, cozile sunt foarte necesare dincolo de un punct și veți constata că acestea sunt o armă puternică (poate chiar cea mai puternică) din arsenalul dvs. Mult noroc! ��

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