Да ли тражите систем чекања? Или можда тражите бољи? Ево свих информација које су вам потребне!
Системи чекања су најбоље чувана тајна позадинског развоја.
Без покушаја да напишем песму у славу система чекања, рекао бих да млађи бацкенд програмер постаје позадински програмер средњег нивоа након што научи да интегрише редове у систем. Редови побољшавају корисничко искуство (видећемо како), смањују сложеност и побољшавају поузданост система.
Наравно, за веома једноставне веб апликације са скоро нултим саобраћајем и веб-сајтовима са брошурама, редови могу бити свеобухватни (или чак немогуће инсталирати ако сте у типичном окружењу за дељено хостовање), али све не-тривијалне апликације ће имати користи од чекања у реду. системи, а велике апликације су немогуће без чекања у реду.
Пре него што почнемо, одрицање од одговорности: ако сте већ задовољни системима чекања и желите да упоредите различите опције, следећих неколико уводних одељака ће изазвати велики сан. 🙂 Зато слободно скочите напред. Уводни делови су намењени онима који имају само нејасну идеју о системима чекања или су само у пролазу чули име.
Преглед садржаја
Шта је систем чекања?
Почнимо тако што ћемо разумети шта је ред.
Ред је структура података у рачунарској науци која имитира редове у стварном свету које видимо око нас. Ако одете на шалтер за карте, на пример, приметићете да ћете морати да стојите на крају реда, док ће особа на почетку реда прва добити карту. То је оно што такође називамо феноменом „први дође, први услужен“. У компјутерској науци, могуће је писати програме који своје задатке чувају као овај у реду, обрађујући их један по један на истој принципу „први дође-први услужен“.
Имајте на уму да ред не обавља никакву стварну обраду сам. То је само нека врста привременог складиштења где задаци чекају док их нешто не преузме. Ако све ово звучи превише апстрактно, не брините. То је апстрактан концепт, али ћемо видети јасне примере у следећем одељку. 🙂
Зашто су вам потребни системи чекања?
Не улазећи у веома дугачак опис, рекао бих да је главна потреба за системима чекања због позадинске обраде, паралелног извршавања и опоравка од отказа. Погледајмо ово уз помоћ примера:
Позадинска обрада
Претпоставимо да водите маркетиншку кампању за е-трговину у којој је време од суштинског значаја и да је ваша апликација направљена тако да покреће е-поруку са потврдом непосредно пре него што купац изврши уплату и прикаже јој се страница „хвала“. Ако сервер за пошту на који се повезујете не ради, веб страница ће једноставно умрети, нарушавајући корисничко искуство.
Замислите велики број захтева за подршку које бисте добили! У овом случају, боље је гурнути овај задатак слања е-поште у ред послова и показати клијенту страницу о успеху.
Паралелно извршење
Многи програмери, посебно они који углавном кодирају једноставније апликације са малим прометом, имају навику да користе црон послове за обраду у позадини. Ово је у реду док величина улаза не нарасте толико да се не може обрисати. На пример, претпоставимо да имате црон посао који саставља аналитичке извештаје и шаље их е-поштом корисницима и да ваш систем може да обради 100 извештаја у минути.
Чим ваша апликација порасте и почне да добија у просеку више од 100 захтева у минути, она ће почети све више да заостаје и никада неће моћи да заврши све послове.
У систему чекања, ова ситуација се може избећи постављањем више радника, од којих сваки може да изабере посао (који садржи по 100 извештаја који треба да се обави) и да раде паралелно да би завршили задатак много, много раније.
Опоравак од неуспеха
Ми генерално не размишљамо о неуспеху као веб програмери. Узимамо здраво за готово да ће наши сервери и АПИ-ји које користимо увек бити на мрежи. Али стварност је другачија — прекиди мреже су превише чести, а одлични АПИ-ји на које се ослањате могу бити неисправни због проблема са инфраструктуром (пре него што кажете „не ја!“, не заборавите масовни прекид рада Амазон С3). Дакле, да се вратимо на пример извештавања, ако део генерисања извештаја захтева да се повежете са АПИ-јем за плаћања и та веза је прекинута 2 минута, шта се дешава са 200 извештаја који нису успели?
Међутим, системи чекања укључују значајне трошкове. Крива учења је прилично стрма док улазите у потпуно нови домен, повећава се сложеност ваше апликације и примене, а послови у реду чекања не могу се увек контролисати са 100% прецизношћу. Ипак, постоје ситуације када прављење апликације без редова једноставно није могуће.
Склонивши то с пута, хајде да погледамо неке од уобичајених опција међу позадинским системима/системима у реду чекања данас.
Редис
Редис је познато као складиште кључ/вредност које само складишти, ажурира и преузима низове података без знања о структури података. Иако је то раније могло бити тачно, данас Редис има ефикасне и веома корисне структуре података као што су листе, сортирани скупови, па чак и Пуб-Суб систем, што га чини веома пожељним за имплементације редова.
Предности Редис-а су:
- Потпуно у меморији база података, што резултира бржим читањем/писањем.
- Високо ефикасан: може лако да подржи више од 100.000 операција читања/писања у секунди.
- Веома флексибилна шема постојаности. Можете или да постигнете максималне перформансе по цену могућег губитка података у случају кварова или да подесите у потпуно конзервативном режиму да бисте жртвовали перформансе ради доследности.
- Кластери подржани из кутије
Имајте на уму да Редис нема апстракције за размену порука/редове/опоравак, тако да морате или да користите пакет или сами да направите лагани систем. Пример је да је Редис подразумевани позадински део реда за Ларавел ПХП оквир, где су аутори оквира имплементирали планер.
Леарнинг Редис је лако.
РаббитМК
Постоји неколико суптилних разлика између Редис-а и РаббитМКпа хајде да их прво склонимо с пута.
Пре свега, РаббитМК има специјализованију, добро дефинисану улогу, па је направљен да одражава то – размену порука. Другим речима, његова слатка тачка је да делује као посредник између два система, што није случај за Редис, који делује као база података. Као резултат тога, РаббитМК пружа још неколико могућности које недостају у Редис-у: рутирање порука, поновни покушаји, дистрибуција оптерећења итд.
Ако размислите о томе, редови задатака се такође могу сматрати системом за размену порука, где се планер, радници и „подносиоци посла“ могу сматрати ентитетима који учествују у прослеђивању порука.
РаббитМК има следеће предности:
- Боље апстракције за прослеђивање порука, смањење рада на нивоу апликације ако је прослеђивање порука оно што вам је потребно.
- Отпорнији на нестанке струје и нестанке (од Редис-а, барем подразумевано).
- Подршка кластера и федерације за дистрибуиране примене.
- Корисне алатке за управљање и праћење ваших имплементација.
- Подршка за практично све нетривијалне програмске језике.
- Примена помоћу алата по вашем избору (Доцкер, Цхеф, Пуппет, итд.).
Када користити РаббитМК? Рекао бих да је то одличан избор када знате да треба да користите асинхроно прослеђивање порука, али нисте спремни да се ухватите у коштац са великом сложеношћу неких других опција чекања на овој листи (погледајте доле).
АцтивеМК
Ако сте у пословном простору (или правите високо дистрибуирану и велику апликацију), и не желите да стално измишљате точак (и правите грешке на том путу), АцтивеМК вреди погледати.
Ево где се АцтивеМК истиче:
- Имплементиран је у Јави и тако има заиста уредну Јава интеграцију (прати ЈМС стандард).
- Подржано више протокола: АМКП, МКТТ, СТОМП, ОпенВире, итд.
- Рукује безбедношћу, рутирањем, истеком поруке, аналитиком итд., ван кутије.
- Уграђена подршка за популарне дистрибуиране обрасце за размену порука, штеди вам време и скупе грешке.
То не значи да је АцтивеМК доступан само за Јаву. Има клијенте за Питхон, Ц/Ц++, Ноде, .Нет и друге екосистеме, тако да не би требало бити забринутости за могући колапс у будућности. Осим тога, АцтивеМК је изграђен на потпуно отвореним стандардима и прављење сопствених лаких клијената требало би да буде лако.
Све што је речено и урађено, имајте на уму да је АцтивеМК само брокер и не укључује бацкенд. И даље ћете морати да користите један од подржаних позадинских програма за чување порука. Укључио сам га овде јер није везан за одређени програмски језик (као друга популарна решења као што су Целери, Сидекик, итд.)
Амазон МК
Амазон МК заслужује брзо, али важно помињање. Ако мислите да је АцтивеМК идеално решење за ваше потребе, али не желите да се бавите изградњом и одржавањем инфраструктуре сами, Амазон МК нуди управљану услугу за то. Подржава све протоколе које АцтивеМК ради — нема никакве разлике у функцијама — пошто користи сам АцтивеМК испод површине.
Предност је у томе што је то услуга којом се управља, тако да не морате да бринете ни о чему другом осим о њеном коришћењу. Има још више смисла за оне примене које су на АВС-у, јер можете да искористите друге услуге и понуде директно из своје примене (на пример, бржи пренос података).
Амазон СКС
Не можемо очекивати да ће Амазон мирно седети када су у питању критични делови инфраструктуре, зар не? 🙂
И тако имамо Амазон СКС, што је потпуно хостована, једноставна услуга чекања (буквално) од стране добро познатог гиганта АВС-а. Још једном, суптилне разлике су важне, па имајте на уму да СКС нема концепт прослеђивања порука. Као и Редис, то је једноставан бацкенд за прихватање и дистрибуцију послова у редовима.
Дакле, када бисте желели да користите Амазон СКС? Ево неколико разлога:
- Ви сте обожаватељ АВС-а и ништа више нећете дирати (искрено, има много таквих људи, и мислим да у томе нема ништа лоше).
- Потребно вам је хостовано решење, па се уверите да је стопа неуспеха нула и да ниједан посао није изгубљен.
- Не желите да правите кластер и морате сами да га надгледате. Или још горе, морате да направите алате за праћење када бисте то време могли да користите за продуктиван развој.
- Већ имате значајна улагања у АВС платформу и да останете закључани има пословног смисла.
- Желите фокусиран, једноставан систем чекања без икаквих проблема везаних за прослеђивање порука, протоколе и остало.
Све у свему, Амазон СКС је солидан избор за све који желе да уграде редове послова у свој систем и не морају да брину о томе да сами инсталирају/надгледају ствари.
Беансталкд
Беансталкд постоји већ дуже време и представља борбено тестиран, брз и лак позадински део за чекање послова. Постоји неколико карактеристика Беансталкд-а по којима се значајно разликује од Редис-а:
- То је стриктно систем чекања послова и ништа друго. Ви гурате послове на то, које касније повлаче радници. Дакле, ако ваша апликација има чак и малу потребу за прослеђивањем порука, требало би да избегнете Беансталкд.
- Не постоје напредне структуре података као што су скупови, приоритетни редови итд.
- Беансталкд је оно што се назива ред први ушао, први изашао (ФИФО). Не постоји начин да се послови распореде по приоритету.
- Не постоје опције за груписање.
Све ово каже да Беансталкд чини гладак и брз систем редова за једноставне пројекте који живе на једном серверу. За многе је бржи и стабилнији од Редис-а. Дакле, ако имате питања са Редис-ом који једноставно не можете да решите без обзира на све, а ваше потребе су једноставне, Беансталкд вреди покушати.
Закључак
Ако сте читали довде (или сте дошли до овог читања 😉), постоји прилично добра шанса да сте заинтересовани за системе чекања или вам је потребан. Ако јесте, листа на овој страници ће вам добро послужити, осим ако не тражите систем редова редова специфичан за језик/оквир.
Волео бих да вам могу рећи да је чекање у реду једноставно и 100% поуздано, али није. Неуредно је, а пошто је све у позадини и дешава се веома брзо (грешке могу проћи непримећене и постати веома скупе). Ипак, редови су веома неопходни преко тачке, и видећете да су они моћно оружје (можда чак и најмоћније) у вашем арсеналу. Срећно! 🙂