Top 6 køsystemer til backend-udviklere

Leder du efter et køsystem? Eller måske leder du efter en bedre? Her er al den information, du har brug for!

Køsystemer er den bedst bevarede hemmelighed bag udvikling af backend.

Uden at forsøge at skrive et digt til ære for køsystemer, vil jeg sige, at en junior backend-udvikler bliver en backend-udvikler på mellemniveau, efter at han har lært at integrere køer i systemet. Køer forbedrer kundeoplevelsen (vi skal se hvordan), reducerer kompleksiteten og forbedrer pålideligheden i et system.

Sikker på, at for meget simple webapps med næsten nul trafik og brochurewebsteder kan køer være overordnet (eller endda umulige at installere, hvis du er på et typisk shared-hosting-miljø), men ikke-trivielle apps vil alle vinde ved at stå i kø systemer, og store apps er umulige uden at stå i kø.

Før vi begynder, en ansvarsfraskrivelse: Hvis du allerede er fortrolig med køsystemer og ønsker at sammenligne de forskellige muligheder, vil de næste par indledende sektioner fremkalde større søvn. 🙂 Så hop gerne med det samme. De indledende afsnit er beregnet til dem, der kun har en tåget ide om køsystemer eller bare har hørt navnet i forbifarten.

Hvad er et køsystem?

Lad os begynde med at forstå, hvad en kø er.

En kø er en datastruktur inden for datalogi, der efterligner, ja, de køer i den virkelige verden, vi ser omkring os. Går du for eksempel til en billetskranke, vil du bemærke, at du bliver nødt til at stå for enden af ​​køen, mens personen i starten af ​​køen får billetten først. Det er det, vi også kalder “først til mølle”-fænomenet. Inden for datalogi er det muligt at skrive programmer, der gemmer deres opgaver på denne måde i en kø, og behandler dem én efter én på det samme først-til-mølle-princip.

Bemærk, at køen ikke selv udfører nogen egentlig behandling. Det er bare en slags midlertidig opbevaring, hvor opgaver venter, indtil de bliver samlet op af noget. Hvis det hele lyder lidt for abstrakt, så fortvivl ikke. Det er et abstrakt koncept, men vi vil se klare eksempler i næste afsnit. 🙂

Hvorfor har du brug for køsystemer?

Uden at komme ind på en meget lang beskrivelse, vil jeg sige, at det primære behov for køsystemer er på grund af baggrundsbehandling, parallel eksekvering og gendannelse fra fejl. Lad os se på disse ved hjælp af eksempler:

Baggrundsbehandling

Antag, at du kører en e-handelsmarketingkampagne, hvor tiden er afgørende, og at din applikation er bygget, så den affyrer en bekræftelses-e-mail lige før kunden gennemfører betalingen og får vist “tak”-siden. Hvis mailserveren, du opretter forbindelse til, er nede, vil websiden bare dø, hvilket ødelægger brugeroplevelsen.

Forestil dig det høje antal supportanmodninger, du ville få! I dette tilfælde er det bedre at skubbe denne e-mail-afsendelsesopgave til en jobkø og vise kunden successiden.

Parallel udførelse

Mange udviklere, især dem, der for det meste koder simplere apps med lav trafik, har for vane at bruge cron-job til baggrundsbehandling. Dette er fint, indtil størrelsen af ​​input bliver så stor, at den ikke kan slettes. Antag for eksempel, at du har et cron-job, der kompilerer analyserapporter og e-mailer dem til brugere, og at dit system kan behandle 100 rapporter i minuttet.

Så snart din app vokser og begynder at få mere end 100 anmodninger i minuttet i gennemsnit, vil den begynde at sakke mere og mere bagud og vil aldrig være i stand til at fuldføre alle opgaverne.

I et køsystem kan denne situation undgås ved at opsætte flere arbejdere, som hver kan vælge et job (som indeholder 100 rapporter, der skal udføres hver) og arbejde parallelt med at afslutte opgaven meget, meget hurtigere.

Genopretning fra fiasko

Vi tænker generelt ikke på fiasko som webudviklere. Vi tager det lidt for givet, at vores servere og de API’er, vi bruger, altid vil være online. Men virkeligheden er anderledes – netværksudfald er alt for almindelige, og de fremragende API’er, du stoler på, kan være nede på grund af infrastrukturproblemer (før du siger “ikke mig!”, glem ikke massiv Amazon S3-udfald). Så hvis vi går tilbage til rapporteringseksemplet, hvis en del af din rapportgenerering kræver, at du opretter forbindelse til betalings-API’en, og forbindelsen er nede i 2 minutter, hvad sker der så med de 200 rapporter, der mislykkedes?

Køsystemer involverer dog betydelige omkostninger. Læringskurven er ret stejl, når du træder ind i et helt nyt domæne, kompleksiteten af ​​din applikation og implementering øges, og job i kø kan ikke altid kontrolleres med 100 % præcision. Når det er sagt, er der situationer, hvor det bare ikke er muligt at bygge en applikation uden køer.

Med det af vejen, lad os tage et kig på nogle af de almindelige muligheder blandt backends/systemer i kø i dag.

Redis

Redis er kendt som et nøgleværdilager, der bare gemmer, opdaterer og henter datastrenge uden kendskab til datastrukturen. Selvom det kunne have været sandt tidligere, har Redis i dag effektive og yderst nyttige datastrukturer som lister, sorterede sæt og endda et Pub-Sub-system, hvilket gør det yderst ønskeligt til køimplementeringer.

Fordelene ved Redis er:

• Fuldstændig in-memory database, hvilket resulterer i hurtigere læsning/skrivning.
• Meget effektiv: Kan nemt understøtte mere end 100.000 læse-/skriveoperationer i sekundet.
• Meget fleksibel vedholdenhedsordning. Du kan enten gå efter maksimal ydeevne på bekostning af muligt datatab i tilfælde af fejl eller konfigurere i fuldt konservativ tilstand for at ofre ydeevne for konsistens.
• Klynger understøttet ud af kassen

Bemærk venligst, at Redis ikke har nogen meddelelses-/kø-/gendannelsesabstraktioner, så du skal enten bruge en pakke eller selv bygge et letvægtssystem. Et eksempel er, at Redis er standardkø-backend for Laravel PHP-frameworket, hvor en planlægger er blevet implementeret af framework-forfatterne.

At lære Redis det er nemt.

RabbitMQ

Der er nogle få subtile forskelle mellem Redis og RabbitMQså lad os få dem af vejen først.

Først og fremmest har RabbitMQ en mere specialiseret, veldefineret rolle, og derfor er den bygget til at afspejle det – beskeder. Med andre ord er dets søde punkt at fungere som en formidler mellem to systemer, hvilket ikke er tilfældet for Redis, der fungerer som en database. Som et resultat giver RabbitMQ et par flere faciliteter, der mangler i Redis: beskedruting, genforsøg, indlæsningsfordeling osv.

Hvis du tænker over det, kan opgavekøer også opfattes som et meddelelsessystem, hvor planlæggeren, arbejderne og job-“afsendere” kan opfattes som enheder, der deltager i meddelelsesoverførsel.

RabbitMQ har følgende fordele:

• Bedre abstraktioner til videregivelse af meddelelser, hvilket reducerer arbejde på applikationsniveau, hvis meddelelser er det, du har brug for.
• Mere modstandsdygtig over for strømsvigt og udfald (end Redis, i hvert fald som standard).
• Klynge- og forbundsstøtte til distribuerede implementeringer.
• Nyttige værktøjer til at administrere og overvåge dine implementeringer.
• Understøttelse af praktisk talt alle de ikke-trivielle programmeringssprog derude.
• Implementering med dit valgte værktøj (Docker, Chef, Puppet osv.).

Hvornår skal man bruge RabbitMQ? Jeg vil sige, at det er et godt valg, når du ved, at du skal bruge asynkron meddelelsesoverførsel, men ikke er klar til at tackle den tårnhøje kompleksitet af nogle af de andre kømuligheder på denne liste (se nedenfor).

ActiveMQ

Hvis du er til virksomhedsområdet (eller bygger en meget distribueret og storstilet app), og du ikke ønsker at skulle genopfinde hjulet hele tiden (og lave fejl undervejs), ActiveMQ er et kig værd.

Her er hvor ActiveMQ udmærker sig:

• Det er implementeret i Java og har også en virkelig pæn Java-integration (følger JMS-standarden).
• Flere protokoller understøttet: AMQP, MQTT, STOMP, OpenWire osv.
• Håndterer sikkerhed, routing, meddelelsesudløb, analyser osv. ud af boksen.
• Indbygget understøttelse af populære distribuerede meddelelsesmønstre, hvilket sparer dig tid og dyre fejl.

Det betyder ikke, at ActiveMQ kun er tilgængelig for Java. Det har klienter til Python, C/C++, Node, .Net og andre økosystemer, så der burde ikke være nogen bekymring for et muligt kollaps i fremtiden. Derudover er ActiveMQ bygget på helt åbne standarder, og det skal være nemt at bygge dine egne lette kunder.

Alt det sagt og gjort, vær opmærksom på, at ActiveMQ kun er en mægler og ikke inkluderer en backend. Du skal stadig bruge en af ​​de understøttede backends til at gemme beskederne. Jeg inkluderede det her, fordi det ikke er bundet til et bestemt programmeringssprog (som andre populære løsninger som Selleri, Sidekiq osv.)

Amazon MQ

Amazon MQ fortjener en hurtig, men vigtig omtale her. Hvis du mener, at ActiveMQ er den ideelle løsning til dine behov, men ikke ønsker at beskæftige dig med at bygge og vedligeholde infrastrukturen selv, tilbyder Amazon MQ en administreret service til at gøre det. Den understøtter alle de protokoller ActiveMQ gør – der er ingen forskel i funktioner overhovedet – da den bruger ActiveMQ selv under overfladen.

Fordelen er, at det er en administreret tjeneste, så du behøver ikke bekymre dig om andet end at bruge den. Det giver endnu mere mening for de implementeringer, der er på AWS, da du kan udnytte andre tjenester og tilbud direkte fra din implementering (hurtigere dataoverførsler, for eksempel).

Amazon SQS

Vi kan vel ikke forvente, at Amazon sidder stille, når det kommer til kritiske infrastrukturdele? 🙂

Og det har vi altså Amazon SQS, som er en fuldt hostet, simpel køtjeneste (bogstaveligt talt) af den velkendte gigant AWS. Endnu en gang er subtile forskelle vigtige, så bemærk venligst, at SQS ikke har konceptet med at sende beskeder. Ligesom Redis er det en simpel backend til at acceptere og distribuere job i køer.

Så hvornår vil du bruge Amazon SQS? Her er nogle grunde:

• Du er en AWS-fan og vil ikke røre noget andet (helt ærligt, der er mange mennesker derude som sådan, og jeg tror, ​​der ikke er noget galt med det).
• Du har brug for en hostet løsning, så sørg for, at fejlprocenten er nul, og ingen af ​​jobs går tabt.
• Du ønsker ikke at bygge en klynge ud og skal selv overvåge den. Eller endnu værre, skal du bygge overvågningsværktøjer, når du kunne bruge den tid til at lave produktiv udvikling.
• Du har allerede betydelige investeringer i AWS-platformen, og det giver forretningsmæssig mening at forblive låst.
• Du vil have et fokuseret, enkelt køsystem uden noget af det fnug, der er forbundet med meddelelser, protokoller og andet.

Alt i alt er Amazon SQS et solidt valg for alle, der ønsker at inkorporere jobkøer i deres system og ikke behøver at bekymre sig om at installere/overvåge ting selv.

Bønnestilkd

Bønnestilkd har eksisteret i lang tid og er en kamptestet, hurtig, nem backend til jobkø. Der er nogle få karakteristika ved Beanstalkd, der gør, at den adskiller sig betydeligt fra Redis:

• Det er strengt taget et jobkøsystem og intet andet. Du skubber job til det, som senere bliver trukket af jobarbejdere. Så hvis din ansøgning har et lille behov for at sende beskeder, vil du gerne undgå Beanstalkd.
• Der er ingen avancerede datastrukturer som sæt, prioritetskøer osv.
• Beanstalkd er det, der kaldes en First In, First Out (FIFO) kø. Der er ingen måde at arrangere job efter prioritet.
• Der er ingen muligheder for klyngedannelse.

Alt dette nævnte Beanstalkd giver et smart og hurtigt køsystem til simple projekter, der lever på en enkelt server. For mange er det hurtigere og mere stabilt end Redis. Så hvis du har problemer med Redis, som du bare ikke kan løse uanset hvad, og dine behov er enkle, er Beanstalkd et forsøg værd.

Konklusion

Hvis du har læst så langt (eller nået hertil skumlelæsning 😉 ), er der en ret god chance for, at du er interesseret i køsystemer eller har brug for et. Hvis det er tilfældet, vil listen på denne side tjene dig godt, medmindre du leder efter et sprog-/rammespecifikt køsystem.

Jeg ville ønske, at jeg kunne fortælle dig, at kødannelse er enkel og 100 % pålidelig, men det er det ikke. Det er rodet, og da det hele er i baggrunden og sker meget hurtigt (fejl kan gå ubemærket hen og blive meget dyre). Alligevel er køer meget nødvendige ud over et punkt, og du vil opdage, at de er et kraftfuldt våben (måske endda det mest kraftfulde) i dit arsenal. Held og lykke! 🙂