Uvod u Sisteme Čekanja
Tražite li sistem za obradu zadataka u redu čekanja? Ili možda želite bolju alternativu? Na pravom ste mestu! U ovom članku pronaći ćete sve neophodne informacije.
Sistemi čekanja su među najvrednijim alatima u razvoju backend aplikacija, često nedovoljno isticani.
Bez namere da ulazimo u poetski opis, može se reći da razvojni inženjer postaje stručnjak srednjeg nivoa kada nauči kako da efikasno integriše redove u svoj sistem. Upotrebom redova značajno se unapređuje korisničko iskustvo (objasnićemo kako), smanjuje se složenost i povećava pouzdanost sistema.
Naravno, za jednostavne web aplikacije sa minimalnim prometom ili za sajtove sa osnovnim informacijama, redovi mogu biti suvišni. Može se čak desiti da ih je nemoguće implementirati u deljenom hosting okruženju. Međutim, za sve kompleksnije aplikacije, sistemi čekanja su od velike koristi, a za velike aplikacije oni su apsolutno neophodni.
Pre nego što nastavimo, napomena: ako ste već upoznati sa sistemima čekanja i želite da uporedite različite opcije, naredni uvodni delovi biće vam manje interesantni. Slobodno preskočite na konkretne primere. Uvodni delovi namenjeni su onima koji tek počinju da se upoznaju sa sistemima čekanja ili su o njima samo čuli.
Šta je Sistem Čekanja?
Počnimo od definisanja pojma reda.
Red je struktura podataka u računarstvu koja imitira redove kakve vidimo u svakodnevnom životu. Na primer, ako čekate na šalteru za karte, morate stati na kraj reda. Osoba na početku reda će prva dobiti kartu. Ovaj princip se naziva „prvi ušao, prvi izašao“ (FIFO). U računarstvu, programi mogu da čuvaju zadatke u redu, obrađujući ih jedan po jedan, po istom FIFO principu.
Važno je napomenuti da sam red ne vrši nikakvu obradu. On samo predstavlja privremeno skladište gde zadaci čekaju dok ih neko ne preuzme. Ako vam se ovo čini apstraktnim, bez brige. U narednim delovima ćemo dati jasne primere.
Zašto Su Vam Potrebni Sistemi Čekanja?
Bez previše detalja, glavna svrha sistema čekanja je podrška pozadinskoj obradi, paralelnom izvršavanju i oporavku od grešaka. Pogledajmo to kroz primere:
Pozadinska Obrada
Pretpostavimo da vodite marketinšku kampanju za e-trgovinu gde je brzina od ključne važnosti. Vaša aplikacija šalje potvrdni mejl odmah nakon što kupac izvrši uplatu i preusmerava ga na stranicu „hvala“. Ako server za mejlove ne funkcioniše, web stranica će se srušiti, što će negativno uticati na korisničko iskustvo.
Možete zamisliti broj zahteva za podršku koji biste dobili! U ovom slučaju, bolje je da zadatak slanja mejla prebacite u red zadataka, a kupcu odmah prikažete stranicu sa potvrdom uspešne kupovine.
Paralelno Izvršavanje
Mnogi programeri, posebno oni koji razvijaju jednostavnije aplikacije sa manjim prometom, koriste cron poslove za pozadinsku obradu. Ovo je prihvatljivo dok količina podataka ne postane prevelika. Na primer, pretpostavimo da imate cron posao koji generiše analitičke izveštaje i šalje ih korisnicima. Vaš sistem može da obradi 100 izveštaja u minutu.
Čim vaša aplikacija poraste i počne da dobija više od 100 zahteva u minutu, počeće da zaostaje i nikada neće moći da obradi sve zadatke.
U sistemu čekanja, ovaj problem se može izbeći postavljanjem više radnika. Svaki od njih može preuzeti zadatak (npr. 100 izveštaja) i raditi paralelno na njegovom izvršavanju, znatno brže.
Oporavak od Grešaka
Mi, kao web programeri, često ne razmišljamo o mogućim greškama. Uzimamo zdravo za gotovo da će naši serveri i API-ji koje koristimo uvek biti dostupni. Međutim, realnost je drugačija. Prekidi mreže su česti, a čak i pouzdani API-ji mogu imati problema sa infrastrukturom (setite se prekida rada AWS S3). Vraćajući se na primer izveštavanja, ako deo generisanja izveštaja zahteva povezivanje sa API-jem za plaćanje i ta veza pukne na 2 minuta, šta se dešava sa 200 neuspešnih izveštaja?
Sistemi čekanja nose određene troškove. Kriva učenja je strma, jer ulazite u potpuno novo područje. Povećava se složenost aplikacije i implementacije, a zadaci u redu ne mogu se uvek kontrolisati sa 100% preciznošću. Ipak, postoje situacije kada je razvoj aplikacije bez redova jednostavno nemoguć.
Nakon ovog uvoda, pogledajmo neke od popularnih sistema čekanja koji se koriste danas.
Redis
Redis je poznat kao skladište ključ/vrednost koje samo čuva, ažurira i preuzima podatke bez poznavanja njihove strukture. Iako je to nekada bilo tačno, danas Redis nudi efikasne strukture podataka kao što su liste, sortirani skupovi, pa čak i Pub/Sub sistem, što ga čini vrlo pogodnim za implementaciju redova.
Prednosti Redis-a:
- Baza podataka koja se u celosti čuva u memoriji, što omogućava brzo čitanje/pisanje.
- Visoka efikasnost: lako može podržati više od 100.000 operacija čitanja/pisanja u sekundi.
- Fleksibilna shema postojanosti. Možete postići maksimalne performanse po cenu mogućeg gubitka podataka u slučaju kvara, ili postaviti potpuno konzervativan režim žrtvujući performanse zarad doslednosti.
- Podrška za klastere.
Važno je napomenuti da Redis nema ugrađene apstrakcije za razmenu poruka/redove/oporavak. Potrebno je ili koristiti gotov paket ili sami kreirati jednostavan sistem. Na primer, Redis je podrazumevani backend za redove u Laravel PHP frameworku, gde su autori frameworka implementirali planer.
Učenje Redis-a je lako.
RabbitMQ
Postoji nekoliko suptilnih razlika između Redis-a i RabbitMQ, pa ih razmotrimo prvo.
RabbitMQ ima specijalizovaniju ulogu – razmenu poruka. On deluje kao posrednik između dva sistema, što nije slučaj sa Redis-om, koji se koristi kao baza podataka. Kao rezultat toga, RabbitMQ nudi dodatne funkcionalnosti koje Redis nema: rutiranje poruka, ponovne pokušaje, distribuciju opterećenja itd.
Ako razmislite o tome, redovi zadataka se mogu smatrati sistemom za razmenu poruka, gde se planer, radnici i „podnosioci poslova“ mogu smatrati entitetima koji učestvuju u razmeni poruka.
Prednosti RabbitMQ-a:
- Bolje apstrakcije za razmenu poruka, smanjujući posao na nivou aplikacije ako vam je to potrebno.
- Otporniji na prekide napajanja i kvarove (od Redis-a, barem podrazumevano).
- Podrška za klastere i federaciju za distribuirane implementacije.
- Korisni alati za upravljanje i praćenje vaših implementacija.
- Podrška za gotovo sve značajne programske jezike.
- Implementacija uz pomoć alata po vašem izboru (Docker, Chef, Puppet, itd.).
Kada koristiti RabbitMQ? Ovo je odličan izbor kada znate da vam je potrebna asinhrona razmena poruka, ali niste spremni da se upuštate u kompleksnost nekih drugih sistema čekanja sa ove liste.
ActiveMQ
Ako radite u poslovnom okruženju (ili kreirate visoko distribuiranu i veliku aplikaciju), i ne želite da konstantno izmišljate „toplu vodu“, ActiveMQ je vredan razmatranja.
Prednosti ActiveMQ-a:
- Implementiran je u Javi i ima dobru integraciju sa Java okruženjem (prati JMS standard).
- Podržava više protokola: AMQP, MQTT, STOMP, OpenWire, itd.
- Upravlja bezbednošću, rutiranjem, istekom poruke, analitikom, itd., odmah nakon instalacije.
- Ugrađena podrška za popularne obrasce za distribuiranu razmenu poruka, štedi vreme i skupe greške.
ActiveMQ nije dostupan samo za Javu. Postoje klijenti za Python, C/C++, Node, .Net i druge ekosisteme, tako da ne bi trebalo biti problema sa njegovom upotrebom u budućnosti. Osim toga, ActiveMQ je izgrađen na otvorenim standardima i kreiranje sopstvenih klijenata je relativno jednostavno.
Važno je napomenuti da je ActiveMQ samo posrednik (broker) i ne uključuje backend. I dalje ćete morati da koristite jedan od podržanih sistema za čuvanje poruka. Uključili smo ga ovde jer nije vezan za određeni programski jezik (za razliku od drugih popularnih rešenja kao što su Celery, Sidekiq, itd.).
Amazon MQ
Amazon MQ zaslužuje posebno spominjanje. Ako smatrate da je ActiveMQ idealno rešenje, ali ne želite da se bavite izgradnjom i održavanjem infrastrukture, Amazon MQ nudi uslugu upravljanja. Podržava sve protokole koje podržava i ActiveMQ – nema razlike u funkcijama – jer koristi ActiveMQ u pozadini.
Prednost je što je to upravljana usluga, tako da ne morate da brinete o bilo čemu osim o njenoj upotrebi. Ovo je posebno korisno za aplikacije koje se nalaze na AWS-u, jer možete da iskoristite druge usluge direktno iz svoje aplikacije (npr. brži prenos podataka).
Amazon SQS
Ne možemo očekivati da će Amazon mirno sedeti kada su u pitanju kritični delovi infrastrukture, zar ne? 🙂
Tako imamo Amazon SQS, potpuno hostovanu, jednostavnu uslugu čekanja od strane poznatog giganta AWS-a. Važno je napomenuti da SQS nema koncept prosleđivanja poruka. Slično Redis-u, to je jednostavan backend za prihvatanje i distribuciju zadataka u redovima.
Kada biste trebali koristiti Amazon SQS? Evo nekoliko razloga:
- Ako ste veliki ljubitelj AWS-a i ne želite da koristite ništa drugo.
- Ako vam je potrebno hostovano rešenje sa nultom stopom kvarova i bez gubitka zadataka.
- Ako ne želite da pravite klastere i sami ih nadgledate. Ili još gore, ako morate da pravite alate za praćenje umesto da se bavite razvojem aplikacije.
- Ako već imate značajna ulaganja u AWS platformu.
- Ako želite jednostavan sistem čekanja bez brige o prosleđivanju poruka i protokolima.
Sve u svemu, Amazon SQS je odličan izbor za svakoga ko želi da implementira redove zadataka u svoj sistem, bez potrebe da sam instalira i nadgleda sistem.
Beanstalkd
Beanstalkd je sistem koji se već dugo koristi, testiran je u praksi, i brz i lagan za obradu zadataka u redu čekanja. Postoji nekoliko karakteristika Beanstalkd-a koje ga razlikuju od Redis-a:
- To je isključivo sistem za redove zadataka. Vi ubacujete zadatke, koje kasnije preuzimaju radnici. Ako vaša aplikacija ima potrebu za prosleđivanjem poruka, trebalo bi da izbegnete Beanstalkd.
- Nema napredne strukture podataka, kao što su skupovi ili prioritetni redovi.
- Beanstalkd je „prvi ušao, prvi izašao“ (FIFO) sistem. Ne postoji način da se zadaci raspoređuju po prioritetu.
- Nema opcije za grupisanje zadataka.
Beanstalkd je dobar i brz sistem redova za jednostavne projekte koji se izvršavaju na jednom serveru. Za mnoge je brži i stabilniji od Redis-a. Ako imate problema sa Redis-om koje ne možete da rešite, a vaši zahtevi su jednostavni, Beanstalkd je vredan pokušaja.
Zaključak
Ako ste pročitali do ovde (ili ste samo preskočili na ovaj deo 😉), velika je verovatnoća da ste zainteresovani za sisteme čekanja. Ako jeste, lista u ovom članku će vam biti od koristi, osim ako ne tražite specifičan sistem redova za određeni jezik ili framework.
Voleli bismo da možemo reći da je korišćenje sistema čekanja jednostavno i 100% pouzdano, ali to nije tako. Može biti komplikovano, a s obzirom na to da se sve dešava u pozadini i veoma brzo, greške mogu proći nezapaženo i postati skupe. Ipak, redovi su neophodni i postaju moćno oružje u vašem arsenalu. Srećno!