Topp 6 køsystemer for backend-utviklere

Leter du etter et køsystem? Eller kanskje du leter etter en bedre? Her er all informasjonen du trenger!

Køsystemer er den best bevarte hemmeligheten til backend-utvikling.

Uten å prøve å skrive ut et dikt til ros for køsystemer, vil jeg si at en junior backend-utvikler blir en backend-utvikler på mellomnivå etter at han lærer å integrere køer i systemet. Køer forbedrer kundeopplevelsen (vi får se hvordan), reduserer kompleksiteten og forbedrer påliteligheten i et system.

Jada, for veldig enkle nettapper med nesten null trafikk og brosjyrenettsteder, kan køer være en total (eller til og med umulig å installere hvis du er på et typisk delt vertsmiljø), men ikke-trivielle apper vil alle tjene på å stå i kø systemer, og store apper er umulig uten å stå i kø.

Før vi begynner, en ansvarsfraskrivelse: Hvis du allerede er komfortabel med køsystemer og ønsker å sammenligne de ulike alternativene, vil de neste par innledende delene indusere stor søvn. 🙂 Så hopp gjerne rett foran. De innledende delene er ment for de som bare har en tåkete idé om køsystemer eller bare har hørt navnet i forbifarten.

Hva er et køsystem?

La oss begynne med å forstå hva en kø er.

En kø er en datastruktur innen informatikk som etterligner, vel, de virkelige køene vi ser rundt oss. Går du for eksempel til en billettskranke, vil du legge merke til at du må stå på slutten av køen, mens personen i starten av køen får billetten først. Dette er det vi også kaller «førstemann til mølla»-fenomenet. I informatikk er det mulig å skrive programmer som lagrer oppgavene deres slik i en kø, og behandler dem én etter én på samme førstemann-til-mølla-prinsippet.

Vær oppmerksom på at køen ikke utfører noen faktisk behandling i seg selv. Det er bare en slags midlertidig lagring der oppgaver venter til de blir plukket opp av noe. Hvis alt dette høres litt for abstrakt ut, ikke bekymre deg. Det er et abstrakt konsept, men vi vil se klare eksempler i neste avsnitt. 🙂

Hvorfor trenger du køsystemer?

Uten å komme inn på en veldig lang beskrivelse, vil jeg si at hovedbehovet for køsystemer er på grunn av bakgrunnsbehandling, parallell kjøring og gjenoppretting etter feil. La oss se på disse ved hjelp av eksempler:

Bakgrunnsbehandling

Anta at du kjører en markedsføringskampanje for e-handel der tiden er avgjørende, og at applikasjonen din er bygget slik at den avfyrer en bekreftelses-e-post rett før kunden fullfører betalingen og vises takkesiden. Hvis e-postserveren du kobler til er nede, vil nettsiden bare dø, noe som bryter brukeropplevelsen.

Tenk deg det høye antallet støtteforespørsler du vil få! I dette tilfellet er det bedre å skyve denne e-postsendingsoppgaven til en jobbkø og vise kunden suksesssiden.

Parallell utførelse

Mange utviklere, spesielt de som stort sett koder enklere apper med lite trafikk, har for vane å bruke cron-jobber for bakgrunnsbehandling. Dette er greit inntil størrelsen på inngangen blir så stor at den ikke kan fjernes. Anta for eksempel at du har en cron-jobb som kompilerer analyserapporter og sender dem på e-post til brukere, og at systemet ditt kan behandle 100 rapporter per minutt.

Så snart appen din vokser og begynner å få mer enn 100 forespørsler per minutt i gjennomsnitt, vil den begynne å falle mer og mer etter og vil aldri kunne fullføre alle jobbene.

I et køsystem kan denne situasjonen unngås ved å sette opp flere arbeidere, som hver kan velge en jobb (som inneholder 100 rapporter som skal utføres hver) og arbeide parallelt for å fullføre oppgaven mye, mye tidligere.

Gjenoppretting fra fiasko

Vi tenker vanligvis ikke på fiasko som webutviklere. Vi tar det for gitt at serverne våre og API-ene vi bruker alltid vil være online. Men realiteten er annerledes – nettverksavbrudd er altfor vanlige, og de utmerkede API-ene du stoler på kan være nede på grunn av infrastrukturproblemer (før du sier «ikke meg!», ikke glem massiv Amazon S3-feil). Så, for å gå tilbake til rapporteringseksemplet, hvis en del av rapportgenereringen krever at du kobler til betalings-API og den forbindelsen er nede i 2 minutter, hva skjer med de 200 rapportene som mislyktes?

Køsystemer innebærer imidlertid betydelig overhead. Læringskurven er ganske bratt når du går inn i et helt nytt domene, kompleksiteten til applikasjonen og distribusjonen øker og jobber i kø kan ikke alltid kontrolleres med 100 % presisjon. Når det er sagt, er det situasjoner når det ikke er mulig å bygge en applikasjon uten køer.

Med det ute av veien, la oss ta en titt på noen av de vanlige alternativene blant backends/systemer i kø i dag.

Redis

Redis er kjent som et nøkkelverdilager som bare lagrer, oppdaterer og henter datastrenger uten kunnskap om strukturen til data. Selv om det kan ha vært sant tidligere, har Redis i dag effektive og svært nyttige datastrukturer som lister, sorterte sett og til og med et Pub-Sub-system, noe som gjør det svært ønskelig for køimplementeringer.

Fordelene med Redis er:

• Helt i minnet database, noe som resulterer i raskere lesing/skriving.
• Svært effektiv: Kan enkelt støtte mer enn 100 000 lese-/skriveoperasjoner per sekund.
• Svært fleksibel utholdenhetsordning. Du kan enten gå for maksimal ytelse på bekostning av mulig datatap i tilfelle feil eller sette opp i fullstendig konservativ modus for å ofre ytelse for konsistens.
• Klynger støttet ut av esken

Vær oppmerksom på at Redis ikke har noen abstraksjoner for meldinger/køer/gjenoppretting, så du må enten bruke en pakke eller bygge et lettvektssystem selv. Et eksempel er at Redis er standard kø-backend for Laravel PHP-rammeverket, der en planlegger er implementert av rammeverkforfatterne.

Å lære Redis det er lett.

RabbitMQ

Det er noen få subtile forskjeller mellom Redis og RabbitMQså la oss få dem ut av veien først.

For det første har RabbitMQ en mer spesialisert, veldefinert rolle, og derfor bygget den for å reflektere det – meldingstjenester. Med andre ord, dens sweet spot er å fungere som en mellommann mellom to systemer, noe som ikke er tilfelle for Redis, som fungerer som en database. Som et resultat gir RabbitMQ noen flere fasiliteter som mangler i Redis: meldingsruting, gjenforsøk, lastdistribusjon, etc.

Hvis du tenker på det, kan oppgavekøer også betraktes som et meldingssystem, der planleggeren, arbeiderne og jobbens «innsendere» kan tenkes på enheter som deltar i meldingsoverføring.

RabbitMQ har følgende fordeler:

• Bedre abstraksjoner for overføring av meldinger, noe som reduserer arbeid på applikasjonsnivå hvis sending av meldinger er det du trenger.
• Mer motstandsdyktig mot strømbrudd og strømbrudd (enn Redis, i det minste som standard).
• Klynge- og forbundsstøtte for distribuerte distribusjoner.
• Nyttige verktøy for å administrere og overvåke distribusjonene dine.
• Støtte for praktisk talt alle ikke-trivielle programmeringsspråk der ute.
• Utrulling med verktøyet du velger (Docker, Chef, Puppet, etc.).

Når skal jeg bruke RabbitMQ? Jeg vil si det er et godt valg når du vet at du trenger å bruke asynkron meldingsoverføring, men ikke er klar til å takle den ruvende kompleksiteten til noen av de andre køalternativene på denne listen (se nedenfor).

ActiveMQ

Hvis du er interessert i bedriftsområdet (eller bygger en svært distribuert og storstilt app), og du ikke vil måtte finne opp hjulet på nytt hele tiden (og gjøre feil underveis), ActiveMQ er verdt en titt.

Her er hvor ActiveMQ utmerker seg:

• Den er implementert i Java og har også en veldig fin Java-integrasjon (følger JMS-standarden).
• Flere protokoller støttes: AMQP, MQTT, STOMP, OpenWire, etc.
• Håndterer sikkerhet, ruting, meldingsutløp, analyser osv., rett ut av esken.
• Innebygd støtte for populære distribuerte meldingsmønstre, sparer deg for tid og kostbare feil.

Det betyr ikke at ActiveMQ kun er tilgjengelig for Java. Den har klienter for Python, C/C++, Node, .Net og andre økosystemer, så det bør ikke være noen bekymring for en mulig kollaps i fremtiden. Dessuten er ActiveMQ bygget på helt åpne standarder, og det skal være enkelt å bygge dine egne lette kunder.

Alt som er sagt og gjort, vær oppmerksom på at ActiveMQ bare er en megler og ikke inkluderer en backend. Du må fortsatt bruke en av de støttede backends for å lagre meldingene. Jeg inkluderte det her fordi det ikke er knyttet til et bestemt programmeringsspråk (som andre populære løsninger som Selleri, Sidekiq, etc.)

Amazon MQ

Amazon MQ fortjener en rask, men viktig omtale her. Hvis du tror at ActiveMQ er den ideelle løsningen for dine behov, men ikke ønsker å håndtere bygging og vedlikeholde infrastrukturen selv, tilbyr Amazon MQ en administrert tjeneste for å gjøre det. Den støtter alle protokollene ActiveMQ gjør – det er ingen forskjell i funksjoner i det hele tatt – siden den bruker ActiveMQ selv under overflaten.

Fordelen er at det er en administrert tjeneste, så du trenger ikke å bekymre deg for noe annet enn å bruke den. Det gir enda mer mening for de distribusjonene som er på AWS, ettersom du kan utnytte andre tjenester og tilbud direkte fra distribusjonen din (raskere dataoverføringer, for eksempel).

Amazon SQS

Vi kan vel ikke forvente at Amazon skal sitte stille når det kommer til kritiske infrastrukturdeler? 🙂

Og det har vi også Amazon SQS, som er en fullstendig vertsbasert, enkel køtjeneste (bokstavelig talt) av den velkjente giganten AWS. Nok en gang er subtile forskjeller viktige, så vær oppmerksom på at SQS ikke har konseptet med å sende meldinger. I likhet med Redis er det en enkel backend for å akseptere og distribuere jobber i køer.

Så når vil du bruke Amazon SQS? Her er noen grunner:

• Du er en AWS-fan og vil ikke røre noe annet (ærlig talt, det er mange sånne folk der ute, og jeg tror det ikke er noe galt med det).
• Du trenger en vertsbasert løsning, så sørg for at feilprosenten er null og at ingen av jobbene går tapt.
• Du ønsker ikke å bygge ut en klynge og må overvåke den selv. Eller enda verre, må bygge overvåkingsverktøy når du kan bruke den tiden til å gjøre produktiv utvikling.
• Du har allerede betydelige investeringer i AWS-plattformen, og det er forretningsmessig fornuftig å holde deg innelåst.
• Du vil ha et fokusert, enkelt køsystem uten noe av loet forbundet med sending av meldinger, protokoller og annet.

Alt i alt er Amazon SQS et solid valg for alle som ønsker å inkludere jobbkøer i systemet sitt og ikke trenger å bekymre seg for å installere/overvåke ting selv.

Bønnestengeld

Bønnestengeld har eksistert lenge og er en kamptestet, rask, enkel backend for jobbkø. Det er noen få egenskaper ved Beanstalkd som gjør at den skiller seg betydelig fra Redis:

• Det er strengt tatt et jobbkøsystem og ingenting annet. Du skyver jobber til det, som blir trukket av jobbarbeidere senere. Så hvis søknaden din har et lite behov for å sende meldinger, vil du unngå Beanstalkd.
• Det er ingen avanserte datastrukturer som sett, prioriterte køer, etc.
• Beanstalkd er det som kalles en First In, First Out (FIFO)-kø. Det er ingen måte å ordne jobber etter prioritet.
• Det er ingen alternativer for gruppering.

Alt dette sier Beanstalkd gir et glatt og raskt køsystem for enkle prosjekter som lever på en enkelt server. For mange er det raskere og mer stabilt enn Redis. Så hvis du har problemer med Redis som du rett og slett ikke klarer å løse uansett, og dine behov er enkle, er Beanstalkd verdt et forsøk.

Konklusjon

Hvis du har lest så langt (eller nådd hit skumlesing 😉 ), er det en ganske god sjanse for at du er interessert i køsystemer eller trenger et. I så fall vil listen på denne siden tjene deg godt, med mindre du ser etter et språk-/rammespesifikt køsystem.

Jeg skulle ønske jeg kunne fortelle deg at kø er enkelt og 100 % pålitelig, men det er det ikke. Det er rotete, og siden det hele er i bakgrunnen og skjer veldig fort (feil kan gå ubemerket hen og bli svært kostbare). Likevel er køer veldig nødvendige utover et punkt, og du vil oppdage at de er et kraftig våpen (kanskje til og med det kraftigste) i arsenalet ditt. Lykke til! 🙂