En dummys guide til distribuerede køer

Hvis du nogensinde har spekuleret på, hvad Kafka, Heron, streaming i realtid, SQS eller RabbitMQ handler om, så er denne artikel noget for dig. Jeg vil diskutere detaljeret, hvorfor vi har brug for en kø til nutidens moderne softwarearkitektur, hvad der bruges nogle almindelige teknologier, og hvordan køer ofte bruges i branchen. Hvis du kan lide denne artikel, har jeg et kursus om skalering af distribuerede systemer, hvor jeg diskuterer disse emner mere detaljeret.

OK, lad os komme ind i det!

Først og fremmest, hvorfor har du brug for en kø- / meddelelsesmægler?

Historien om, hvordan en kø reddede limonaden, står

Forestil dig, at du kører en limonade? stå, og du byggede en smidig lille webapp, der holder øje med, hvor ofte dine kunder vender tilbage til din limonadestand.

Din webapp har et slutpunkt, siger yourlemonade.com/traffic, og hver gang du klikker på en knap, stiger antallet af trafik med 1. Smukt.

Når trafikken til din limonadestand øges, klikker du mere og mere på knappen. Da du bor i et relativt lille kvarter, får du kun 10-20 mennesker om dagen. Dit salg fortsætter som normalt, webappen håndterer trafikken fint, og alt er fint og skidt. Perfekt.

Mareridtet med en blomstrende forretning

Nu hvor din limonadestand har gjort sig bemærket, strømmer folk fra hele byen ind for at få en smag af din berømte limonade. Og en smuk søndag morgen besluttede de lokale nyheder at promovere din stand, og trafikken EKSPLODERER .

Som du kan forestille dig, øges trafikken til din limonadestand fra 10-20 personer om dagen til 10.000 om dagen. Du trykker rasende på trafikknappen, hvilket igen udløser et opkald til yourlemonade.com/traffic, og din webapp fortsætter med at øge mængden af ​​trafik.

Desværre er din webapp hostet på en 8-bit, 128 MB RAM-server i din husgarage. Med den blomstrende forretning og øget trafik kan din webapp ikke håndtere trafikskalaen længere.

Til sidst dør din server. ☠️

Med det bringes hele din webapp ned. Du kan ikke holde styr på trafikken længere. Folk styrter ind, ordrer hoper sig op, alligevel er din web-app nede, og du kan ikke håndtere nogen transaktioner, før du kan begynde at logge trafikken igen.

Hvad laver du?

Kø til undsætning

Et øjeblik af glans rammer dig, hvad hvis jeg placerer en kasse foran disken, hvor hver klient bare kan droppe en note, der siger, at de var der?

Hver gang en klient går gennem døren og afgiver en ordre, beder du dem høfligt om at droppe deres ordreark i en lille kasse placeret foran betalingstælleren. Fremragende! Du har i det væsentlige indført en mekanisme til at holde styr på ankomster, mens du stadig tillader din virksomhed at fungere som normalt.

Dette er hvad vi kalder asynkron behandling og velkommen til køens verden . ?

Når du starter med at bygge software, ligesom den limonadestand, jeg nævnte ovenfor, er det almindeligt for en opgave at

  1. ring derefter til en tjeneste
  2. vent på, at tjenesten er færdig, og derefter
  3. gå videre til næste opgave.

Dette kaldes synkron behandling. Asynkron behandling tillader på den anden side en opgave at ringe til en tjeneste og gå videre til den næste opgave, mens tjenesten behandler anmodningen i sit eget tempo. Derfor er en kø en smuk, elegant måde at fjerne blokering af dine systemer på, fordi det lægger et lag foran dine tjenester og giver dem mulighed for at tackle opgaverne i deres eget tempo.

Hvis en kø er så stærk, hvorfor sætter vi den ikke foran alt?

Som enhver, der har beskæftiget sig med distribuerede systemer, kan bevidne, er skalering af et distribueret system ekstremt vanskeligt og kompliceret. Der er et par ting at vide om køer, der kan gøre en kø til et uinteressant forslag til dit system.

Nogle spørgsmål, jeg vil stille, før jeg beslutter mig for, om en kø er den rigtige løsning for dig:

  • Har din tjeneste problemer på grund af høj trafik? Hvis det ikke er det, skal du måske undersøge, hvad flaskehalsen er, før du hopper i køer. Som Donald Knuth berømt sagde, er for tidlig optimering roden til alt ondt.
  • Har du intern ekspertise i at styre en kø? Eller skal du potentielt ansætte et team til at gøre det for dig? Vedligeholdelsesomkostninger, som at skalere køen, kan skyde i luften, hvis du ikke er forsigtig. Der er tjenester som Amazon SQS (Simple Queuing Service), der tilbyder en administreret løsning (dvs. du behøver ikke at vedligeholde noget alene).
  • Er det muligt at have dobbelte poster i køen? Hvis ja, er det acceptabelt?
  • Har du brug for at registrere alle transaktioner, hvis en kø går ned?
  • I tilfælde af at en kø går ned, skal køen være i stand til at afspille alle poster igen? Hvad er dine backupmuligheder?

Der er mange flere bekymringer, der kan være specifikke for din brugssag, men forhåbentlig har jeg gjort opmærksom på, at det ikke er så let at tilføje en kø som at snappe fingrene.

Hvordan køer bruges i moderne arkitektur

Køer er allestedsnærværende i nutidens moderne distribuerede systemarkitektur - vedtaget på tværs af forskellige brancher til forskellige brugssager, og der er flere nye brugssager hver dag.

Her er nogle af de virkelige brugssager til køer:

Streaming i realtid

Da MapReduce kom rundt, var det et kæmpe fænomen i branchen, fordi det tillod blotte dødelige at behandle petabytes af data på en rimelig tid, hvor som helst fra dage til timer. Dette kan synes absurd i dag, når data er tilgængelige på næsten sekunder, men før MapReduce var det ikke let at udtrække brugbare data fra ekstremt store datasæt.

Appetitten til dataanalyse er vokset, og vi ser nu på at behandle data inden for få timer og nogle gange millisekunder .

For at opnå analyse med lav latenstid og ydeevne kontinuerligt blev konceptet med streaming i realtid udtænkt.

Et nyttigt eksempel her er at tænke på annoncer: Annoncer på Twitter vises for eksempel for millioner af mennesker om dagen. For at sikre, at brugerne ikke ser de samme annoncer flere gange inden for en bestemt tidsperiode, skal Twitter på en eller anden måde vide, sidste gang en bruger blev udsat for en bestemt annonce.

Hvis vi havde været afhængige af MapReduce for at udføre denne handling, ville det ikke engang blive betragtet som en løsning, fordi det vil tage op til timer at behandle alle disse data. I stedet giver streaming i realtid os mulighed for at behandle annonceeksponeringer, når de ankommer. Dette er alt mulig på grund af køer, der gør det muligt at streame og behandle data kontinuerligt i realtid.

Nogle teknologier, du ofte vil høre om i realtids-streaming-brugssager, er Kafka, Kafka-streams, Redis, Spark Streaming (som er forskellig fra Spark) og så videre.

Begivenhedsdrevet arkitektur

Køer bruges som en kritisk komponent i en begivenhedsdrevet arkitektur eller i det mindste kendt som Pub (lisher) - Sub (scriber). Begivenhedsdrevet arkitektur er ifølge Wikipedia:

Event-driven arkitektur (EDA) er et softwarearkitekturmønster, der fremmer produktion, detektion, forbrug af og reaktion på begivenheder.

Jeg vil gerne tænke på dette som at abonnere på et nyhedsbrev: Som producent af et nyhedsbrev ved du, hvem der er tilmeldt dit nyhedsbrev, og hvem der ikke er. Du skriver indholdet, og derefter sender du det til dine abonnenter.

På den anden side abonnerer du muligvis på flere nyhedsbreve, men du ved ikke, hvem de andre abonnenter er. Men du er ligeglad med det. Dette er en rigtig god funktion, fordi du nu kan skrive software, der lytter til en masse begivenheder og kun reagerer på dem, du er interesseret i.

RabbitMQ og Amazon SQS (Simple Queuing Service) er nogle af de teknologier, der ofte bruges til denne type brugssager.

Distribueret, fejltolerant, skalerbar infrastruktur

Distribuerede systemer er tilbøjelige til fejl, og en kø er en af ​​flere måder at øge fleksibiliteten i arkitekturen på. I en mikroservicearkitektur (eller serviceorienteret arkitektur) kommunikerer flere mikrotjenester med hinanden gennem køer som delte grænseflader.

Når en mikroservice fejler uventet, kan en kø stadig acceptere beskeder. Dette giver i det væsentlige en buffer, som vores mikroservice kan gendanne. Når mikroservicen kommer tilbage online, kan den hente meddelelserne fra køen og behandle dem igen.

Tænk på det som din postkasse. Mens du er på ferie på Hawaii, sender mailperson stadig din mail i postkassen. Når du kommer tilbage fra ferie, kan du hente posten og behandle dem på din fritid.

Tak fordi du læste! Jeg håber, du har lært en eller to ting om distribuerede køer fra min artikel. Hvis du nød at læse dette, bedes du give et klapp, og du er velkommen til at deltage i mit nyhedsbrev her, hvor jeg skriver om software og tekniske interviews!

Ressourcer, jeg anbefaler

For at fremme din forståelse af køer og forskellige emner, der er nævnt ovenfor, vil jeg varmt anbefale disse ressourcer nedenfor. Eller deltag i mit kursus om skalering af distribuerede systemer for at lære mere om køer :)

  • Design af dataintensive applikationer: En fantastisk bog til at lære om skalering af distribuerede systemer! Højt anbefalet.
  • Kafka guiden: Jeg brugte denne bog som referencevejledning og nød den til beskrivelsen på højt niveau.
  • Kafka Streams: Dette er en informativ artikel fra Confluent, der taler i detaljer på højt niveau om Kafka's implementering af stream-behandling.
  • Elementer i programmeringsinterviews: Fantastisk til løsning af kodningsproblemer.
  • Cracking The Coding Interview: Fantastisk til at dække grundlæggende CS-kodningsproblemer.
  • Daily Coding Problem.com: Dette er et gratis websted, der tilbyder gratis daglige kodningsproblemer. Du kan tilmelde dig interessante daglige kodningsudfordringer, og du kan betale for løsninger, hvis du vil. Hvis du bruger mit henvisningslink (dailycodingproblem.com/zhiachong), får du $ 10 i rabat!

(FYI, jeg deler flere ressourcer på min hjemmeside: zhiachong.com, hvor jeg personligt har prøvet og testet og anbefaler til softwareingeniører på alle niveauer.)

Skål!