Cauți un sistem de așteptare? Sau poate ești în căutarea unuia mai bun? Iată toate informațiile de care aveți nevoie!
Sistemele de așteptare sunt cel mai bine păstrat secret al dezvoltării backend.
Fără a încerca să scriu o poezie de laudă a sistemelor de așteptare, aș spune că un dezvoltator de backend junior devine un dezvoltator de backend de nivel mediu după ce învață să integreze cozile în sistem. Cozile îmbunătățesc experiența clienților (vom vedea cum), reduc complexitatea și îmbunătățesc fiabilitatea unui sistem.
Sigur, pentru aplicații web foarte simple, cu trafic aproape de zero și site-uri web cu broșuri, cozile pot fi generale (sau chiar imposibil de instalat dacă sunteți într-un mediu tipic de găzduire partajată), dar toate aplicațiile netriviale vor câștiga din coadă. sistemele și aplicațiile mari sunt imposibile fără să fie implicată coadă.
Înainte de a începe, o declinare a răspunderii: dacă vă simțiți deja confortabil cu sistemele de așteptare și doriți să comparați diferitele opțiuni, următoarele câteva secțiuni introductive vă vor induce un somn major. 🙂 Așa că nu ezitați să sari chiar înainte. Secțiunile introductive sunt destinate celor care au doar o idee vagă despre sistemele de așteptare sau care au auzit numele în treacăt.
Cuprins
Ce este un sistem de așteptare?
Să începem prin a înțelege ce este o coadă.
O coadă este o structură de date în informatică care imită, ei bine, cozile din lumea reală pe care le vedem în jurul nostru. Dacă te duci la un ghișeu de bilete, de exemplu, vei observa că va trebui să stai la sfârșitul cozii, în timp ce persoana de la începutul cozii va primi primul bilet. Acesta este ceea ce numim și fenomenul „primul venit, primul servit”. În informatică, este posibil să scrieți programe care își stochează sarcinile astfel într-o coadă, procesându-le unul câte unul pe aceeași bază, primul venit, primul servit.
Rețineți că coada nu face nicio procesare efectivă în sine. Este doar un fel de stocare temporară în care sarcinile așteaptă până când sunt preluate de ceva. Dacă toate acestea sună puțin prea abstract, nu vă faceți griji. Este un concept abstract, dar vom vedea exemple clare în secțiunea următoare. 🙂
De ce aveți nevoie de sisteme de așteptare?
Fără a intra într-o descriere foarte lungă, aș spune că principala nevoie pentru sistemele de așteptare este din cauza procesării în fundal, a execuției paralele și a recuperării de la eșec. Să ne uităm la acestea cu ajutorul exemplelor:
Procesare de fundal
Să presupunem că derulați o campanie de marketing de comerț electronic în care timpul este esențial și că aplicația dvs. este construită astfel încât să lanseze un e-mail de confirmare chiar înainte ca clientul să finalizeze plata și să i se afișeze pagina „mulțumesc”. Dacă serverul de e-mail la care vă conectați nu este, pagina web va muri, rupând experiența utilizatorului.
Imaginează-ți numărul mare de solicitări de asistență pe care le-ai primi! În acest caz, este mai bine să împingeți această sarcină de trimitere de e-mail la o coadă de locuri de muncă și să arătați clientului pagina de succes.
Execuție paralelă
Mulți dezvoltatori, în special cei care codifică în cea mai mare parte aplicații mai simple, cu trafic redus, au obiceiul de a folosi 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 un job cron care compilează rapoarte de analiză și le trimite prin e-mail utilizatorilor și că sistemul dumneavoastră poate procesa 100 de rapoarte pe minut.
De îndată ce aplicația dvs. crește și începe să primească în medie peste 100 de solicitări pe minut, va începe să rămână din ce în ce mai mult în urmă și nu va putea niciodată să finalizeze toate lucrările.
Într-un sistem de așteptare, această situație poate fi evitată prin configurarea mai multor lucrători, care pot alege fiecare o lucrare (conținând 100 de rapoarte de făcut fiecare) și să lucreze în paralel pentru a finaliza sarcina mult, mult mai devreme.
Recuperare după eșec
În general, nu ne gândim la eșec ca dezvoltatori web. Luăm de la sine înțeles că serverele noastre și API-urile pe care le folosim vor fi întotdeauna online. Dar realitatea este alta – întreruperile rețelei sunt prea frecvente, iar API-urile excelente pe care te bazezi pot fi oprite din cauza problemelor de infrastructură (înainte de a spune „nu eu!”, nu uitați de întrerupere masivă a Amazon S3). Așadar, revenind la exemplul de raportare, dacă o parte din generarea raportului vă solicită să vă conectați la API-ul de plăți și acea conexiune este întreruptă timp de 2 minute, ce se întâmplă cu cele 200 de rapoarte care au eșuat?
Sistemele de așteptare implică totuși o suprasolicitare considerabilă. Curba de învățare este destul de abruptă pe măsură ce pășiți într-un domeniu complet nou, complexitatea aplicației și implementării dvs. crește, iar joburile aflate în coadă nu pot fi întotdeauna controlate cu o precizie de 100%. Acestea fiind spuse, există situații în care construirea unei aplicații fără cozi nu este posibilă.
Cu asta în afara drumului, să aruncăm o privire la unele dintre opțiunile comune dintre backend-urile/sistemele de așteptare de astăzi.
Redis
Redis este cunoscut ca un magazin cheie-valoare 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, astăzi Redis are structuri de date eficiente și extrem de utile, cum ar fi liste, seturi sortate și chiar un sistem Pub-Sub, ceea ce îl face extrem de dorit pentru implementările de cozi de așteptare.
Avantajele Redis sunt:
- Baza de date complet în memorie, rezultând citiri/scriere mai rapide.
- Foarte eficient: poate suporta cu ușurință mai mult de 100.000 de operații de citire/scriere pe secundă.
- Schemă de persistență foarte flexibilă. Puteți fie să optați pentru performanță maximă cu prețul unei posibile pierderi de date în cazul eșecurilor, fie să configurați un mod complet conservator pentru a sacrifica performanța pentru consecvență.
- Clustere acceptate din cutie
Vă rugăm să rețineți că Redis nu are abstracții de mesagerie/cozi de așteptare/recuperare, așa că fie trebuie să utilizați un pachet, fie să construiți singur un sistem ușor. Un exemplu este că Redis este backend-ul implicit de coadă pentru cadrul Laravel PHP, 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 RabbitMQașa că mai întâi să-i scoatem din drum.
În primul rând, RabbitMQ are un rol mai specializat, bine definit și astfel a fost construit pentru a reflecta asta – mesageria. Cu alte cuvinte, punctul său favorabil este să acționeze ca intermediar între două sisteme, ceea ce nu este cazul Redis, care acționează ca o bază de date. Drept urmare, RabbitMQ oferă câteva facilități suplimentare care lipsesc în Redis: rutarea mesajelor, reîncercări, distribuția încărcării etc.
Dacă vă gândiți bine, cozile de sarcini pot fi, de asemenea, gândite ca un sistem de mesagerie, în care planificatorul, lucrătorii și cei care „depun” joburile pot fi gândite la entitățile care participă la transmiterea mesajelor.
RabbitMQ are următoarele avantaje:
- Abstracții mai bune pentru transmiterea mesajelor, reducând munca la nivel de aplicație dacă transmiterea mesajelor este ceea ce aveți nevoie.
- Mai rezistent la întreruperi de curent și întreruperi (decât Redis, cel puțin în mod implicit).
- Suport pentru clustere și federații pentru implementări distribuite.
- Instrumente utile pentru gestionarea și monitorizarea implementărilor dvs.
- Suport pentru practic toate limbajele de programare non-triviale de acolo.
- Implementare cu instrumentul la alegere (Docker, Chef, Puppet etc.).
Când să utilizați RabbitMQ? Aș spune că este o alegere excelentă atunci când știți că trebuie să utilizați transmiterea asincronă a mesajelor, dar nu sunteți pregătit să abordați complexitatea uriașă a unora dintre celelalte opțiuni de așteptare din această listă (vezi mai jos).
ActiveMQ
Dacă vă interesează spațiul întreprinderii (sau construiți o aplicație foarte distribuită și la scară largă) și nu doriți să fiți nevoit să reinventați roata tot timpul (și să faceți greșeli pe parcurs), ActiveMQ merita aruncat o privire.
Iată unde ActiveMQ excelează:
- Este implementat în Java și, prin urmare, are o integrare Java foarte bună (urmează standardul JMS).
- Mai multe protocoale acceptate: AMQP, MQTT, STOMP, OpenWire etc.
- Se ocupă de securitate, de rutare, de expirare a mesajelor, de analiză, etc., imediat.
- Suport integrat pentru modelele populare de mesaje distribuite, economisind timp și greșeli costisitoare.
Asta nu înseamnă că ActiveMQ este disponibil numai pentru Java. Are clienți pentru Python, C/C++, Node, .Net și alte ecosisteme, așa că nu ar trebui să existe îngrijorări pentru un posibil colaps în viitor. În plus, ActiveMQ este construit pe standarde complet deschise și construirea propriilor clienți ușoare ar trebui să fie ușoară.
Toate acestea spuse și făcute, vă rugăm să fiți conștienți de faptul că ActiveMQ este doar un broker și nu include un backend. În continuare va trebui să utilizați unul dintre backend-urile acceptate pentru a stoca mesajele. L-am inclus aici pentru că nu este legat de un anumit limbaj de programare (ca și alte soluții populare precum Țelina, 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 construirea și întreținerea infrastructurii, Amazon MQ oferă un serviciu gestionat pentru a face asta. Acceptă toate protocoalele pe care ActiveMQ le face – nu există nicio diferență în ceea ce privește caracteristicile – deoarece folosește ActiveMQ în sine sub suprafață.
Avantajul este că este un serviciu administrat, așa că nu trebuie să vă faceți griji pentru nimic 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 liniștit când vine vorba de piese critice de infrastructură, nu-i așa? 🙂
Și așa avem Amazon SQS, care este un serviciu de coadă simplu găzduit complet (la propriu) de către binecunoscutul gigant AWS. Încă o dată, diferențele subtile sunt importante, așa că vă rugăm să rețineți că SQS nu are conceptul de transmitere a mesajelor. La fel ca Redis, este un backend simplu pentru acceptarea și distribuirea joburilor în cozi.
Deci, când ați dori să utilizați Amazon SQS? Iată câteva motive:
- Ești un fan AWS și nu te vei atinge de nimic altceva (sincer, sunt mulți oameni așa, și cred că nu este nimic în neregulă cu asta).
- Aveți nevoie de o soluție găzduită, așa că asigurați-vă că rata de eșec este zero și că niciunul dintre joburi nu este pierdut.
- 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 să rămâneți blocat are sens în afaceri.
- Doriți un sistem de așteptare concentrat, simplu, fără niciun fel de dificultăți asociate cu transmiterea mesajelor, protocoale și altele.
Una peste alta, Amazon SQS este o alegere solidă pentru oricine dorește să încorporeze cozile de locuri de muncă în sistemul lor și nu trebuie să-și facă griji cu privire la instalarea/monitorizarea lucrurilor de la sine.
Beanstalkd
Beanstalkd există de mult timp și este un backend testat în luptă, rapid și ușor pentru așteptarea de locuri de muncă. Există câteva caracteristici ale lui Beanstalkd care îl fac să difere considerabil de Redis:
- Este strict un sistem de așteptare a locurilor de muncă și nimic altceva. Împingeți locurile de muncă, care sunt atrase mai târziu de lucrătorii. Deci, dacă aplicația dvs. are chiar și o mică nevoie de transmitere a mesajelor, ați dori să evitați Beanstalkd.
- Nu există structuri de date avansate, cum ar fi 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 locurile de muncă în funcție de prioritate.
- Nu există opțiuni pentru grupare.
Toate acestea spuse, Beanstalkd reprezintă un sistem de coadă elegant ș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ă ai probleme cu Redis pe care parcă nu-l poți rezolva indiferent de ce, iar nevoile tale sunt simple, Beanstalkd merită încercat.
Concluzie
Dacă ați citit până aici (sau ați ajuns aici 😉 ), există șanse destul de mari să fiți interesat de sistemele de așteptare sau să aveți nevoie de unul. Dacă da, lista de pe această pagină vă va fi de folos, cu excepția cazului în care căutați un sistem de cozi specific limbii/cadru.
Mi-aș dori să vă pot spune că coada este simplă și 100% fiabilă, dar nu este. Este dezordonat și, din moment ce totul este î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 vei descoperi că sunt o armă puternică (poate chiar cea mai puternică) din arsenalul tău. Mult noroc! 🙂