Is u op soek na 'n toustelsel? Of soek u miskien 'n beter een? Hier is al die inligting wat u benodig!
Wagstelsels is die besbewaarde geheim van backend-ontwikkeling.
Sonder om 'n gedig te probeer skryf met lof vir die toustelsels, sou ek sê dat 'n junior ontwikkelaar van die backend 'n ontwikkelaar op die middelvlak word nadat hy geleer het om toue in die stelsel te integreer. Toue verbeter klante-ervaring (ons sal dit sien), verminder die kompleksiteit en verbeter betroubaarheid in 'n stelsel.
Natuurlik, vir baie eenvoudige webapps met verkeer- en brosjure-webwerwe wat nagenoeg nul is, kan toue 'n algehele (of selfs onmoontlike installasie as u in 'n tipiese omgewing met gedeelde gasheer is) wees, maar nie-triviale programme sal almal baat vind by die tou stelsels, en groot programme is onmoontlik sonder om tou te staan.
Voordat ons begin, 'n vrywaring: as u reeds gemaklik is met toustelsels en die verskillende opsies wil vergelyk, sal die volgende paar inleidende gedeeltes groot slaap veroorsaak. �� Voel dus vry om vorentoe te spring. Die inleidende gedeeltes is bedoel vir diegene wat net 'n waaghalsige idee het van toustelsels of net die naam hoor verbygaan.
0.1 Wat is 'n toustelsel?
0.2 Waarom het u toustelsels nodig?
0.2.1 Agtergrond verwerking
0.2.2 Parallelle uitvoering
0.2.3 Herstel van mislukking
Wat is 'n toustelsel?
Laat ons begin met die begrip van 'n tou.
'N Tou is 'n datastruktuur in rekenaarwetenskap wat die regte wêreldtoue wat ons rondom ons sien, naboots. As u byvoorbeeld na 'n kaartjietoonbank gaan, sal u agterkom dat u aan die einde van die tou moet staan, terwyl die persoon aan die begin van die tou eers die kaartjie kry. Dit is wat ons ook die "first come, first serve" verskynsel noem. In rekenaarwetenskap is dit moontlik om programme wat hul take soos hierdie in 'n tou stoor te skryf, een vir een op dieselfde basis aan die begin te verwerk.
Let daarop dat die tou self geen werklike verwerking doen nie. Dit is net 'n tydelike opberging van soorte waar take wag totdat hulle deur iets opgetel word. Moenie bekommerd wees as dit alles te abstrak klink nie. Dit is 'n abstrakte konsep, maar ons sien duidelike voorbeelde in die volgende afdeling. ��
Waarom het u toustelsels nodig?
Sonder om 'n baie uitgebreide beskrywing te gee, sou ek sê die belangrikste behoefte aan toustelsels is as gevolg van agtergrondverwerking, parallelle uitvoering en herstel van mislukking. Kom ons kyk hierna aan die hand van voorbeelde:
Gestel jy voer 'n e-handelsbemarkingsveldtog waar tyd van die kern is, en dat jou aansoek so gebou is dat dit 'n e-pos met bevestiging afskiet voordat die klant die betaling voltooi en die bladsy 'dankie' vertoon word. As die e-posbediener waarmee u verbind, af is, sal die webblad net sterf en die gebruikerservaring breek.
Stel jou voor dat die groot aantal ondersteuningsversoeke wat jy sou kry! In hierdie geval is dit beter om hierdie e-posstuuropdrag na 'n werkwette te stoot en die suksesbladsy aan die kliënt te wys.
Baie ontwikkelaars, veral diegene wat meestal eenvoudiger programme met lae verkeer kodeer, gebruik die gewoonte om cron-bane vir agtergrondverwerking te gebruik. Dit is goed totdat die grootte van die invoer so groot word dat dit nie verwyder kan word nie. Gestel byvoorbeeld dat u 'n cron-taak het wat ontledingsverslae opstel en dit per e-pos aan gebruikers stuur en dat u stelsel 100 verslae per minuut kan verwerk.
Sodra u app gemiddeld meer as 100 versoeke per minuut groei en meer en meer agter raak, sal dit nooit al die take kan voltooi nie..
In 'n toustelsel kan hierdie situasie vermy word deur meerdere werkers in te stel, wat elkeen 'n werk kan kies (wat 100 verslae bevat wat elk gedoen moet word) en parallel kan werk om die taak baie vinniger af te handel..
Herstel van mislukking
Ons dink meestal nie aan mislukking as webontwikkelaars nie. Ons neem dit natuurlik as vanselfsprekend dat ons bedieners en die API's wat ons gebruik altyd aanlyn sal wees. Maar die werklikheid is anders: netwerkonderbrekings kom al te gereeld voor, en die uitstekende API's waarop u staatmaak, is moontlik weens infrastruktuurprobleme (voordat u sê: "nie ek nie!" massiewe Amazon S3-onderbreking). Dus, as u teruggaan na die verslagdoeningsvoorbeeld, as u deel van u verslaggenerasie vereis dat u aan die betalings-API koppel en die verbinding vir 2 minute is, wat gebeur dan met die 200 verslae wat misluk het??
Toestelsels behels egter aansienlike bokoste. Die leerkurwe is redelik steil, aangesien u 'n heel nuwe domein betree, die kompleksiteit van u toepassing en ontplooiing verhoog en werkgeleenthede in die tou nie altyd met 100% akkuraatheid beheer kan word nie. Dit gesê, daar is situasies wanneer dit eenvoudig nie moontlik is om 'n toepassing sonder toue te bou nie.
As ons dit uit die weg geruim het, laat ons kyk na 'n paar van die algemene opsies wat vandag in die tou staan ​​en agterbly.
Redis staan ​​bekend as 'n sleutelwaarde-stoor wat net stringe data stoor, opdateer en herwin sonder dat hulle kennis van die struktuur van data het. Hoewel dit vroeër kon gewees het, het Redis vandag doeltreffende en baie nuttige datastrukture soos lyste, gesorteerde stelle en selfs 'n Pub-Sub-stelsel, wat dit uiters wenslik maak vir implementering van toue.
Die voordele van Redis is:
'N Volledige databasis in die geheue, wat lei tot vinniger lees / skryf.
Hoogs doeltreffend: kan maklik meer as 100,000 lees / skryfbewerkings per sekonde ondersteun.
Hoogs buigsame volhardingskema. U kan óf gaan vir maksimum prestasie ten koste van moontlike verlies van data in geval van mislukkings, óf dit in 'n konserwatiewe modus opgestel word om prestasies vir konsekwentheid op te offer.
Clusters word buite die kassie ondersteun
Let daarop dat Redis geen abstrak van boodskappe / tou / herstel het nie, dus u moet 'n pakket gebruik of 'n liggewigstelsel self bou. 'N Voorbeeld is dat Redis die standaard-back-back-backend is vir die Laravel PHP-raamwerk, waar 'n skeduleerder deur die raamwerk outeurs geïmplementeer is..
Leer Redis Is maklik.
Daar is 'n paar subtiele verskil tussen Redis en RabbitMQ, laat ons hulle eers uit die weg ruim.
In die eerste plek het RabbitMQ 'n meer gespesialiseerde, goed gedefinieerde rol, en daarom is dit gebou om dit te weerspieël – boodskappe. Met ander woorde, die lieflike plek daarvan is om as tussenganger tussen twee stelsels op te tree, wat nie die geval is by Redis wat as 'n databasis optree nie. As gevolg hiervan, bied RabbitMQ nog 'n paar fasiliteite wat in Redis ontbreek: boodskaproetering, herproewe, vragverspreiding, ens..
As u daaraan nadink, kan taakwette ook as 'n boodskapstelsel beskou word, waar die beplanner, die werkers en die werkopdragers kan dink aan entiteite wat aan boodskappe gaan deelneem..
RabbitMQ het die volgende voordele:
Beter abstraksies vir die oordrag van boodskappe, die vermindering van werk op die toepassingsvlak as die stuur van boodskappe is wat u benodig.
Meer veerkragtig teen kragonderbrekings en -onderbrekings (as Redis, ten minste by verstek).
Kluster- en federasie-ondersteuning vir verspreide ontplooiings.
Nuttige instrumente om u ontplooiings te bestuur en te monitor.
Ondersteuning vir bykans al die nie-triviale programmeertale daar buite.
Implementering met u gekose instrument (Docker, sjef, marionet, ens.).
Wanneer moet u RabbitMQ gebruik? Ek sou sê dat dit 'n uitstekende keuse is as u weet dat u asinkroniese boodskappe moet gebruik, maar nie gereed is om die toenemende kompleksiteit van sommige van die ander touopsies op hierdie lys aan te pak nie (sien hieronder).
As u die ondernemingsruimte betree (of 'n groot verspreide en grootskaalse app bou), en u nie die wiel heeltyd hoef uit te vind nie (en foute maak onderweg), ActiveMQ is die moeite werd om te kyk.
Hier is ActiveMQ uitblink:
Dit word in Java geïmplementeer en het dus netjiese Java-integrasie (volg die JMS-standaard).
Veelvuldige protokolle ondersteun: AMQP, MQTT, STOMP, OpenWire, ens.
Hanteer sekuriteit, routing, verstryking van boodskappe, analise, ens.
Ondersteunde ondersteuning vir gewilde verspreide boodskappatrone, wat u tyd en duur foute spaar.
Dit wil nie sê dat ActiveMQ slegs vir Java beskikbaar is nie. Dit het kliënte vir Python, C / C ++, Node,. Net en ander ekosisteme, so daar moet geen kommer wees oor 'n moontlike ineenstorting in die toekoms nie. Boonop is ActiveMQ gebou op heeltemal oop standaarde en dit behoort maklik te wees om u eie liggewigkliënte te bou.
Al wat gesê en gedoen is, moet u daarop let dat ActiveMQ slegs 'n makelaar is en nie 'n backend bevat nie. U moet nog steeds een van die ondersteunde agterdele gebruik om die boodskappe te stoor. Ek het dit hier ingesluit omdat dit nie gekoppel is aan 'n spesifieke programmeertaal nie (soos ander gewilde oplossings soos Seldery, Sidekiq, ens.)
Amazon MQ verdien hier 'n vinnige maar belangrike vermelding. As u dink dat ActiveMQ die ideale oplossing vir u behoeftes is, maar nie self wil bou en die infrastruktuur wil onderhou nie, bied Amazon MQ 'n bestuurde diens om dit te doen. Dit ondersteun al die protokolle wat ActiveMQ doen – daar is hoegenaamd geen verskil in funksies nie – aangesien dit ActiveMQ self onder die oppervlak gebruik.
Die voordeel is dat dit 'n bestuurde diens is, en dat u nie hoef te bekommer oor iets anders as om dit te gebruik nie. Dit maak selfs meer sin vir die ontplooiings wat op AWS is, aangesien u ander dienste en aanbiedings direk vanaf u ontplooiing kan gebruik (byvoorbeeld vinniger data-oordragte).
Ons kan nie verwag dat Amazon stil sal sit as dit kom by kritieke infrastruktuurstukke nie, kan ons? ��
En so het ons Amazon SQS, wat 'n volledige gasdiens is (redelik letterlik) deur die bekende reuse AWS. Weereens is subtiele verskille belangrik, daarom moet u daarop let dat SQS nie die konsep van boodskap oordra nie. Soos Redis, is dit 'n eenvoudige agtergrond om werk in toue te aanvaar en te versprei.
Dus, wanneer sou u Amazon SQS wil gebruik? Hier is 'n paar redes:
Jy is 'n AWS-aanhanger en sal niks anders aanraak nie (eerlikwaar, daar is baie mense daar buite, en ek dink daar is niks verkeerd daarmee nie).
U het 'n oplossing nodig wat aangebied word, dus maak seker dat die mislukkingsyfer nul is en dat geen van die werkgeleenthede verlore gaan nie.
U wil nie 'n groep opbou en dit self moet monitor nie. Of, nog erger, moet u moniteringsinstrumente bou wanneer u daardie tyd sou kon gebruik om produktiewe ontwikkeling te doen.
U het reeds aansienlike beleggings in die AWS-platform en dit is sake-sin dat u ingeslote bly.
U wil 'n gefokusde, eenvoudige toustelsel hê sonder enige pluis wat geassosieer word met boodskappe, protokolle en wat nie.
Al met al is Amazon SQS 'n goeie keuse vir almal wat werkskoue in hul stelsel wil opneem en nie hoef te bekommer oor die installering / monitering van dinge alleen nie.
Beanstalkd bestaan ​​al 'n geruime tyd en is 'n gevegsgetoetsde, vinnige, maklike agterkop vir werkwagting. Daar is 'n paar kenmerke van Beanstalkd wat dit aansienlik van Redis laat verskil:
Dit is streng 'n werkstelsel vir toue en niks anders nie. U stoot bane daarheen, wat later deur werkers getrek word. As u selfs 'n klein behoefte het aan boodskappe deurgaan, wil u Beanstalkd vermy.
Daar is geen gevorderde datastrukture soos stelle, prioriteitskrywe, ens.
Beanstalkd word 'n eerste in, eerste uit (EIEU) tou genoem. Daar is geen manier om poste volgens prioriteit te reël nie.
Daar is geen opsies vir groepering nie.
Dit alles sê Beanstalkd vir 'n gladde en vinnige toustelsel vir eenvoudige projekte wat op 'n enkele bediener leef. Vir baie is dit vinniger en stabieler as Redis. So as jy dit het kwessies met Redis dat jy net nie kan lyk of dit oplos nie, en jou behoeftes eenvoudig is, is Beanstalkd die moeite werd om te probeer.
As u tot dusver gelees het (of hier deur aflees �� bereik is), is die kans goed dat u belangstel in toustelsels of dit nodig het. As dit die geval is, sal die lys op hierdie bladsy u goed dien, tensy u op soek is na 'n taal- / raamwerk-spesifieke toustelsel.
Ek wens ek kon jou vertel dat tou eenvoudig is en 100% betroubaar is, maar dit is nie. Dit is slordig, en omdat dit alles op die agtergrond plaasvind en baie vinnig gebeur (foute kan ongemerk raak en baie duur word). Tog is toue baie nodig buite 'n sekere punt, en jy sal vind dat dit 'n kragtige wapen (miskien selfs die magtigste) in jou arsenaal is. Sterkte! ��