Ръководство за манекен за разпределени опашки

Ако някога сте се чудили какво представляват Kafka, Heron, стрийминг в реално време, SQS или RabbitMQ , то тази статия е за вас. Ще обсъдя подробно защо се нуждаем от опашка за днешната модерна софтуерна архитектура, кои са някои често използвани технологии и как опашките често се използват в индустрията. Ако харесвате тази статия, имам курс за мащабиране на разпределени системи, където обсъждам тези теми по-подробно.

Добре, нека да влезем в него!

Първо и най-важно, защо имате нужда от посредник за опашки / съобщения?

Историята за това как опашка спаси лимонадата

Представете си, че пускате лимонада? стойка и създадохте страхотно малко уеб приложение, което проследява колко често клиентите ви се връщат на вашия щанд за лимонада.

Вашето уеб приложение има крайна точка, кажете yourlemonade.com/traffic и всеки път, когато щракнете върху бутон, броят на трафика се увеличава с 1. Красиво.

Тъй като трафикът към вашата стойка за лимонада се увеличава, вие натискате бутона все повече и повече. Е, тъй като живеете в сравнително малък квартал, получавате само 10–20 души на ден. Продажбите ви продължават както обикновено, уеб приложението се справя добре с трафика и всичко е наред. Перфектно.

Кошмарът на процъфтяващия бизнес

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

Както можете да си представите, трафикът към вашия лимонаден щанд се увеличава от 10–20 души на ден на 10 000 на ден. Докосвате неистово бутона за трафик, което от своя страна задейства обаждане до yourlemonade.com/traffic и вашето уеб приложение продължава да увеличава количеството трафик.

За съжаление, вашето уеб приложение се хоства на 8-битов 128MB RAM сървър във вашия гараж. С процъфтяващия бизнес и увеличения трафик, вашето уеб приложение не може повече да се справя с мащаба на трафика.

В крайна сметка вашият сървър умира. ☠️

С това цялото ви уеб приложение е свалено. Вече не можете да следите трафика. Хората се втурват, поръчките се трупат, но уеб приложението ви не работи и не можете да обработвате транзакции, докато не започнете да регистрирате трафика отново.

Какво правиш?

Опашка за спасяване

Миг на блясък ви поразява, ами ако поставя кутия пред гишето, където всеки клиент може просто да пусне бележка, че е бил там?

Всеки път, когато клиент мине през вратата и направи поръчка, вие го молите учтиво да пуснат своите листове за поръчки в малка кутия, поставена пред гишето за плащания. Изключителен! По същество сте въвели механизъм за проследяване на пристиганията, като същевременно оставяте бизнеса си да функционира както обикновено.

Това наричаме асинхронна обработка и добре дошли в света на опашките . ?

Когато започнете да изграждате софтуер, подобно на стойката за лимонада, която споменах по-горе, е обичайно задачата да

  1. обадете се на услуга, след това
  2. изчакайте услугата да приключи и след това
  3. преминете към следващата задача.

Това се нарича синхронна обработка. Асинхронната обработка , от друга страна, позволява на задачата да извика услуга и да премине към следващата задача, докато услугата обработва заявката със свое собствено темпо. Ето защо опашката е красив, елегантен начин за деблокиране на вашите системи, защото поставя слой пред вашите услуги и им позволява да се справят със задачите със свое собствено темпо.

Ако опашката е толкова мощна, защо просто не я поставим пред всичко?

Както всеки, който се е занимавал с разпределени системи, може да потвърди това, мащабирането на разпределена система е изключително сложно и сложно. Има няколко неща, които трябва да знаете за опашките, които могат да направят опашката непривлекателно предложение за вашата система.

Някои въпроси, които бих задал, преди да реша дали опашката е правилното решение за вас:

  • Има ли проблеми с вашата услуга поради голям трафик? Ако не е, може би трябва да разгледате какво е пречките, преди да преминете на опашки. Както Доналд Кнут известен каза, преждевременната оптимизация е коренът на всяко зло.
  • Имате ли вътрешен опит в управлението на опашка? Или е необходимо да наемете екип, който да го направи вместо вас? Разходите за поддръжка, като мащабиране на опашката, могат да скочат до небето, ако не сте внимателни. Има услуги като Amazon SQS (Simple Queuing Service), които предлагат управлявано решение (т.е. не е необходимо да поддържате нищо самостоятелно).
  • Възможно ли е да има дублиращи се записи в опашката? Ако да, приемливо ли е това?
  • Трябва ли да водите запис на всички транзакции, в случай че опашката падне?
  • В случай, че опашката падне, трябва ли опашката да може да преиграе всички записи? Какви са вашите опции за архивиране?

Има още много опасения, които може да са специфични за вашия случай на употреба, но се надявам, че казах, че добавянето на опашка не е толкова лесно, колкото щракването с пръсти.

Как се използват опашки в съвременната архитектура

Опашките са повсеместни в съвременната архитектура на съвременните разпределени системи - приети в различни индустрии за различни случаи на употреба и всеки ден има повече нови случаи на употреба.

Ето някои реални случаи на използване на опашки:

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

Когато MapReduce се появи, това беше огромно явление в индустрията, защото позволява на простосмъртните да обработват петабайта данни за разумен период от време, от дни до часове. Днес това може да изглежда абсурдно, когато данните са достъпни за почти секунди, но преди MapReduce не беше лесно да се извлекат използваеми данни от изключително големи масиви от данни.

Апетитът за анализ на данни е нараснал и сега разглеждаме обработката на данни в рамките на часове, а понякога и милисекунди .

За да се постигне непрекъснат анализ и ефективност с ниска латентност, беше замислена концепцията за поточно предаване в реално време.

Полезен пример тук е да мислим за реклами: рекламите в Twitter например се показват на милиони хора на ден. И все пак, за да се увери, че потребителите не виждат едни и същи реклами няколко пъти в рамките на определен период от време, Twitter трябва по някакъв начин да знае последния път, когато потребителят е бил изложен на определена реклама.

Ако бяхме разчитали на MapReduce да извърши това действие, то дори нямаше да се счита за решение, защото обработването на всички тези данни ще отнеме повече часове. Вместо това стриймингът в реално време ни позволява да обработваме рекламни импресии, когато те пристигнат. Всичко това е възможно поради опашки, които позволяват непрекъснато поточно предаване и обработка на данни в реално време.

Някои технологии, за които често ще чувате в случаи на използване на поточно предаване в реално време, са Kafka, потоци Kafka, Redis, Spark Streaming (което е различно от Spark) и т.н.

Архитектура, управлявана от събития

Опашките се използват като критичен компонент на управлявана от събития архитектура или в разговорно наименование Pub (lisher) - Sub (scriber). Според Wikipedia архитектурата, управлявана от събития, е:

Архитектура, управлявана от събития (EDA), е модел на софтуерна архитектура, насърчаващ производството, откриването, потреблението и реакцията на събития.

Бих искал да мисля за това като абониране за бюлетин: като продуцент на бюлетин вие знаете кой е абониран за вашия бюлетин и кой не. Вие пишете съдържанието и след това го изпращате на абонатите си.

От друга страна, като абонат, може да сте абонирани за множество бюлетини, но не знаете кои са другите абонати. Но всъщност не ви интересува това. Това е наистина хубава функция, защото вече можете да пишете софтуер, който слуша куп събития и отговаря само на тези, които ви интересуват.

RabbitMQ и Amazon SQS (Simple Queuing Service) са някои от технологиите, често използвани за тези видове случаи на употреба.

Разпределена, устойчива на грешки, мащабируема инфраструктура

Разпределените системи са склонни към грешки и опашката е един от няколкото начина за увеличаване на устойчивостта в архитектурата. В архитектура на микросервис (или ориентирана към услуги архитектура) множество микроуслуги комуникират помежду си чрез опашки като споделени интерфейси.

Когато микросервизът се провали неочаквано, опашката все още може да приема съобщения. Това по същество осигурява буфер за възстановяване на нашата микрослужба. След като микросервизът се върне онлайн, той може да вземе съобщенията от опашката и да ги обработи отново.

Мислете за това като за вашата пощенска кутия. Докато сте на почивка на Хавай, пощенският служител все пак ще достави пощата ви в пощенската кутия. След като се върнете от почивка, можете да вземете пощата и да ги обработите в свободното си време.

Благодаря ви, че прочетохте! Надявам се да сте научили нещо или две за разпределените опашки от моята статия. Ако ви е било приятно да четете това, моля, оставете ръкопляскане и не се колебайте да се присъедините към моя бюлетин тук, където пиша за софтуерни и технически интервюта!

Ресурси, които препоръчвам

За да разберете по-горе опашките и различните теми, горещо препоръчвам тези ресурси по-долу. Или се присъединете към моя курс за мащабиране на разпределени системи, за да научите повече за опашките :)

  • Проектиране на интензивни за данни приложения: Страхотна книга за изучаване на мащабиране на разпределени системи! Силно препоръчително.
  • Ръководството на Кафка: Използвах тази книга като справочно ръководство и се насладих на нея за описанието на високо ниво.
  • Kafka Streams: Това е информативна статия от Confluent, която разказва в някои подробности на високо ниво за изпълнението на Kafka за обработка на потоци.
  • Елементи на програмиране Интервюта: Страхотно за решаване на проблеми с кодирането.
  • Пробиване на интервюто за кодиране: Страхотно за покриване на основните проблеми с кодирането на CS.
  • Daily Coding Problem.com: Това е безплатен за изпробване уебсайт, който предлага безплатни ежедневни проблеми с кодирането. Можете да се запишете за интересни ежедневни предизвикателства за кодиране и можете да платите за решения, ако искате. Ако използвате моята реферална връзка (dailycodingproblem.com/zhiachong), получавате 10 $ отстъпка!

(За пръв път споделям повече ресурси на уебсайта си: zhiachong.com, където лично съм опитвал и тествал и препоръчвам за софтуерни инженери от всички нива.)

Наздраве!