Луткасти водич за расподељене редове

Ако сте се икада запитали шта су Кафка, Херон, стреаминг у реалном времену, СКС или РаббитМК , онда је овај чланак за вас. Детаљно ћу разговарати о томе зашто нам је потребан ред за данашњу модерну софтверску архитектуру, које су неке уобичајене технологије и како се редови обично користе у индустрији. Ако уживате у овом чланку, имам курс о скалирању дистрибуираних система где детаљније дискутујем о овим темама.

ОК, кренимо у то!

Прво и најважније, зашто вам треба посредник у редовима / порукама?

Прича о томе како је ред спасио лимунаду стоји

Замислите да користите лимунаду? штанда, а ви сте направили сјајну малу веб-апликацију која прати колико се често ваши клијенти враћају на ваш штанд са лимунадом.

Ваша веб-апликација има крајњу тачку, рецимо иоурлемонаде.цом/траффиц, и сваки пут када кликнете на дугме, број промета се повећа за 1. Лепо.

Како се повећава промет на вашем штанду за лимунаду, све више притискате дугме. Па, с обзиром да живите у релативно малом кварту, дневно имате само 10–20 људи. Продаја се одвија као и обично, веб-апликација одлично управља прометом и све је у реду. Савршен.

Ноћна мора цветајућег посла

Сада када се ваш штанд за лимунаду прославио, људи из целог града хрле да пробају вашу познату лимунаду. А у прелепо недељно јутро, локалне вести одлучиле су да промовишу ваш штанд, а саобраћај ЕКСПЛОДИРА .

Као што можете да замислите, промет до вашег штанда са лимунадом повећава се са 10–20 људи дневно на 10 000 дневно. Бесно тапкате на дугме за саобраћај, што заузврат покреће позив на иоурлемонаде.цом/траффиц, а ваша веб апликација наставља да повећава количину саобраћаја.

Нажалост, ваша веб апликација је смештена на 8-битном 128-МБ РАМ серверу у вашој кућној гаражи. Са процватом пословања и повећаним прометом, ваша веб апликација више не може да се носи са размерама промета.

На крају, ваш сервер умре. ☠

Тиме је срушена цела ваша веб апликација. Не можете више да пратите саобраћај. Људи журе, поруџбине се гомилају, а ваша веб апликација је у паду и не можете да се носите ни са једном трансакцијом док поново не почнете да евидентирате промет.

Шта радиш?

Ред у помоћ

Тренутак сјаја вас задеси, шта ако поставим кутију испред шалтера где сваки клијент може само да остави поруку да је био тамо?

Сваки пут кад клијент уђе кроз врата и изда налог, љубазно га замолите да спусти листове налога у малу кутију постављену испред шалтера. Изванредан! У основи сте увели механизам за праћење долазака, а истовремено омогућавате пословању да функционише као и обично.

То је оно што називамо асинхроном обрадом и добродошло у свет редова . ?

Када започнете изградњу софтвера, слично као штанд за лимунаду који сам горе поменуо, уобичајено је да задатак то уради

  1. онда позовите службу
  2. сачекајте да се услуга заврши, а затим
  3. пређите на следећи задатак.

То се назива синхроном обрадом. Асинхрона обрада , с друге стране, омогућава задатку да позове услугу и пређе на следећи задатак док услуга обрађује захтев својим темпом. Зато је ред леп, елегантан начин за деблокирање система, јер поставља слој испред ваших услуга и омогућава им да се решавају задатака у свом ритму.

Ако је ред тако моћан, зашто га једноставно не бисмо ставили испред свега?

Као што може потврдити свако ко се бавио дистрибуираним системима, скалирање дистрибуираног система изузетно је запетљано и сложено. Постоји неколико ствари које треба знати о редовима због којих би ред могао бити непривлачан за ваш систем.

Неколико питања бих поставио пре него што одлучим да ли је ред право решење за вас:

  • Да ли ваша услуга има проблема због великог промета? Ако није, можда би требало да погледате шта је уско грло пре него што ускочите у редове. Као што је Доналд Кнутх славно рекао, преурањена оптимизација је корен свега зла.
  • Да ли имате интерну стручност у управљању редом? Или треба да потенцијално ангажујете тим који ће то учинити уместо вас? Трошкови одржавања, попут скалирања реда, могу да скоче увис ако нисте пажљиви. Постоје услуге попут Амазон СКС (Једноставна услуга чекања) које нуде управљано решење (тј. Не морате ништа самостално да одржавате).
  • Да ли је могуће имати дупликате уноса у реду? Ако јесте, да ли је то прихватљиво?
  • Да ли треба да водите евиденцију свих трансакција, у случају да ред падне?
  • У случају да се ред сруши, да ли ред треба бити у могућности да репродукује све уносе? Које су ваше резервне опције?

Постоји још много забринутости које би могле бити специфичне за ваш случај употребе, али надам се да сам нагласио да додавање реда није тако лако као пуцање прстима.

Како се редови користе у модерној архитектури

Редови су свеприсутни у данашњој модерној архитектури дистрибуираних система - усвојени у различитим индустријама за различите случајеве употребе, а свакодневних је нових случајева примене.

Ево неких случајева стварне употребе редова:

Стриминг у реалном времену

Када се МапРедуце појавио, то је био огроман феномен у индустрији, јер је омогућавао простим смртницима да обрађују петабајте података у разумном року, било где од дана до сати. Ово би могло изгледати апсурдно данас када су подаци доступни за скоро секунде, али пре МапРедуце-а није било лако извући употребљиве податке из изузетно великих скупова података.

Апетит за аналитику података је порастао и сада обрађујемо податке у року од неколико сати, а понекад и милисекунди .

Да би се континуирано постизала аналитика и перформансе са малим кашњењем, конципиран је концепт струјања у реалном времену.

Овде је користан пример размишљања о огласима: огласи на Твиттер-у се, на пример, дневно приказују милионима људи. Ипак, како би био сигуран да корисници неће видети исте огласе више пута у одређеном временском периоду, Твиттер мора некако знати када је корисник последњи пут био изложен одређеном огласу.

Да смо се при извођењу ове радње ослањали на МапРедуце, ​​то се чак не би ни сматрало решењем, јер ће за обраду свих тих података требати више сати. Уместо тога, стримовање у реалном времену омогућава нам да обрађујемо приказе огласа чим стигну. Све је то омогућено због редова који омогућавају континуирано струјање и обраду података у реалном времену.

Неке технологије о којима ћете често чути у случајевима коришћења стримовања у реалном времену су Кафка, Кафка потоци, Редис, Спарк Стреаминг (који се разликује од Спарка) и тако даље.

Архитектура вођена догађајима

Редови се користе као критична компонента архитектуре вођене догађајима или у колоквијалном називу Пуб (лисхер) - Суб (сцрибер). Архитектура вођена догађајима је, према Википедији:

Архитектура вођена догађајима (ЕДА) је образац софтверске архитектуре који промовише производњу, откривање, потрошњу и реакцију на догађаје.

Волео бих да ово сматрам претплатом на билтен: као продуцент билтена знате ко се претплатио на ваш билтен, а ко не. Садржај напишете, а затим га пошаљете претплатницима.

С друге стране, као претплатник можда ћете бити претплаћени на више билтена, али не знате ко су други претплатници. Али вас заправо није брига за то. Ово је заиста лепа функција, јер сада можете писати софтвер који преслушава гомилу догађаја и одговара само на оне који вас занимају.

РаббитМК и Амазон СКС (Једноставна услуга чекања) су неке од технологија које се често користе за ове типове случајева употребе.

Дистрибуирана, скалабилна инфраструктура отпорна на кварове

Дистрибуирани системи су склони грешкама, а ред је један од неколико начина за повећање еластичности у архитектури. У архитектури микро-услуга (или архитектури оријентисаној на услуге), више микро-услуга међусобно комуницирају кроз редове као дељени интерфејс.

Када микро-услуга неочекивано закаже, ред и даље може да прихвати поруке. Ово у основи пружа бафер за опоравак наше микро услуге. Када се микросервис врати на мрежу, може да преузме поруке из реда и поново их обради.

Схватите то као своје поштанско сандуче. Док сте на одмору на Хавајима, поштар ће вам и даље достављати пошту у поштанско сандуче. Када се вратите са одмора, можете подићи пошту и обрађивати је у слободно време.

Хвала вам за читање! Надам се да сте из мог чланка научили нешто о расподељеним редовима. Ако сте уживали читајући ово, оставите пљесак и слободно се придружите мом билтену овде где пишем о софтверским и техничким интервјуима!

Ресурси које препоручујем

Да бисте даље разумели редове и разне горе поменуте теме, топло бих препоручио ове ресурсе у наставку. Или се придружите мом курсу скалирања дистрибуираних система да бисте сазнали више о редовима :)

  • Дизајнирање апликација интензивних података: Сјајна књига за учење о скалирању дистрибуираних система! Препоручује.
  • Водич Кафка: Користио сам ову књигу као референтни водич и уживао сам у опису на високом нивоу.
  • Кафка потоци: Ово је информативни чланак компаније Цонфлуент који у неким детаљима на високом нивоу говори о Кафкиној примени обраде токова.
  • Елементи програмских интервјуа: Одличан за решавање проблема кодирања.
  • Црацкинг Тхе Цодинг Интервиев: Одличан за покривање основних ЦС проблема кодирања.
  • Даили Цодинг Проблем.цом: Ово је бесплатна веб локација која нуди бесплатне дневне проблеме са кодирањем. Можете се пријавити за занимљиве свакодневне изазове кодирања, а решења можете платити ако желите. Ако користите мој реферални линк (даилицодингпроблем.цом/зхиацхонг), добијате 10 УСД попуста!

(ФИИ, више ресурса делим на својој веб локацији: зхиацхонг.цом где сам лично пробао и тестирао и препоручујем софтверским инжењерима свих нивоа.)

Живели!