Търсите ли система за чакане? Или може би търсите по-добър? Ето цялата информация, от която се нуждаете!
Системите за опашка са най-добре пазената тайна на backend разработката.
Без да се опитвам да напиша стихотворение във възхвала на системите за опашки, бих казал, че младши бекенд разработчик става бекенд разработчик от средно ниво, след като се научи да интегрира опашки в системата. Опашките подобряват клиентското изживяване (ще видим как), намаляват сложността и подобряват надеждността на системата.
Разбира се, за много прости уеб приложения с почти нулев трафик и уебсайтове с брошури, опашките могат да бъдат цялостни (или дори невъзможни за инсталиране, ако сте в типична среда за споделен хостинг), но всички нетривиални приложения ще спечелят от опашка системи и големи приложения са невъзможни без участие в опашка.
Преди да започнем, отказ от отговорност: ако вече сте запознати със системите за опашка и искате да сравните различните опции, следващите няколко уводни раздела ще предизвикат голям сън. 🙂 Така че не се колебайте да продължите напред. Уводните раздели са предназначени за тези, които имат само мъглява представа за системите за масово обслужване или просто са чули името мимоходом.
Съдържание
Какво е система за чакане?
Нека започнем, като разберем какво е опашка.
Опашката е структура от данни в компютърните науки, която имитира опашките в реалния свят, които виждаме около нас. Ако отидете до гишето за билети например, ще забележите, че ще трябва да застанете в края на опашката, докато човекът в началото на опашката ще получи билета първи. Това е, което наричаме още феномена „първи дошъл, първи обслужен“. В компютърните науки е възможно да се пишат програми, които съхраняват задачите си по този начин в опашка, обработвайки ги една по една на същия принцип първи дошъл, първи обслужен.
Обърнете внимание, че самата опашка не извършва реална обработка. Това е просто временно хранилище, където задачите чакат, докато бъдат взети от нещо. Ако всичко това звучи твърде абстрактно, не се притеснявайте. Това е абстрактна концепция, но ще видим ясни примери в следващия раздел. 🙂
Защо се нуждаете от системи за опашка?
Без да навлизам в много дълго описание, бих казал, че основната нужда от системи за опашка е поради фоновата обработка, паралелното изпълнение и възстановяването от повреда. Нека да ги разгледаме с помощта на примери:
Фонова обработка
Да предположим, че провеждате маркетингова кампания за електронна търговия, в която времето е от съществено значение, и че вашето приложение е създадено така, че да изстрелва имейл за потвърждение точно преди клиентът да завърши плащането и да му бъде показана страницата „благодаря“. Ако пощенският сървър, към който се свързвате, не работи, уеб страницата просто ще умре, разрушавайки потребителското изживяване.
Представете си големия брой заявки за поддръжка, които бихте получили! В този случай е по-добре да поставите тази задача за изпращане на имейл в опашка със задачи и да покажете на клиента страницата за успех.
Паралелно изпълнение
Много разработчици, особено тези, които най-често кодират по-прости приложения с нисък трафик, имат навика да използват задачи на cron за фонова обработка. Това е добре, докато размерът на входа стане толкова голям, че да не може да бъде изчистен. Да предположим например, че имате cron задача, която компилира аналитични отчети и ги изпраща по имейл на потребителите и че вашата система може да обработва 100 отчета на минута.
Веднага щом приложението ви порасне и започне да получава средно повече от 100 заявки на минута, то ще започне да изостава все повече и повече и никога няма да може да завърши всички задачи.
В система за опашка тази ситуация може да бъде избегната чрез създаване на множество работници, всеки от които може да избере работа (съдържаща 100 отчета за изпълнение всеки) и да работят паралелно, за да завършат задачата много, много по-рано.
Възстановяване от провал
Като цяло ние като уеб разработчици не мислим за провал. Някак си приемаме за даденост, че нашите сървъри и API, които използваме, винаги ще бъдат онлайн. Но реалността е различна – прекъсванията на мрежата са твърде чести и отличните API, на които разчитате, може да не работят поради инфраструктурни проблеми (преди да кажете „не аз!“, не забравяйте масово прекъсване на Amazon S3). И така, връщайки се към примера за отчитане, ако част от генерирането на вашия отчет изисква да се свържете с API за плащания и тази връзка е прекъсната за 2 минути, какво се случва с 200-те неуспешни отчета?
Системите за опашка обаче включват значителни разходи. Кривата на обучение е доста стръмна, тъй като стъпвате в изцяло нов домейн, сложността на вашето приложение и внедряване се увеличава и задачите на опашка не винаги могат да бъдат контролирани със 100% точност. Въпреки това има ситуации, когато изграждането на приложение без опашки просто не е възможно.
Като приключим с това, нека да разгледаме някои от често срещаните опции сред задните части/системите за опашка днес.
Redis
Redis е известно като хранилище за ключ-стойност, което просто съхранява, актуализира и извлича низове от данни, без да познава структурата на данните. Въпреки че това може да е било вярно по-рано, днес Redis има ефективни и изключително полезни структури от данни като списъци, сортирани набори и дори система Pub-Sub, което го прави силно желан за внедряване на опашка.
Предимствата на Redis са:
- Изцяло база данни в паметта, което води до по-бързо четене/запис.
- Високоефективен: Може лесно да поддържа повече от 100 000 операции за четене/запис в секунда.
- Силно гъвкава схема за постоянство. Можете или да изберете максимална производителност с цената на възможна загуба на данни в случай на повреди, или да настроите напълно консервативен режим, за да пожертвате производителността за последователност.
- Поддържани клъстери извън кутията
Моля, обърнете внимание, че Redis няма никакви абстракции за съобщения/очакване/възстановяване, така че трябва или да използвате пакет, или да изградите сами лека система. Пример е, че Redis е бекендът на опашката по подразбиране за Laravel PHP рамката, където планировчикът е внедрен от авторите на рамката.
Изучаване на Redis лесно е.
RabbitMQ
Има няколко фини разлики между Redis и RabbitMQтака че нека първо ги махнем от пътя.
На първо място, RabbitMQ има по-специализирана, добре дефинирана роля и затова е създаден да отразява това – съобщения. С други думи, неговото приятно място е да действа като посредник между две системи, което не е случаят с Redis, който действа като база данни. В резултат на това RabbitMQ предоставя още няколко възможности, които липсват в Redis: маршрутизиране на съобщения, повторни опити, разпределение на натоварването и т.н.
Ако се замислите, опашките със задачи също могат да се разглеждат като система за съобщения, където планировчикът, работниците и „подавателите“ на задания могат да се смятат за субекти, участващи в предаването на съобщения.
RabbitMQ има следните предимства:
- По-добри абстракции за предаване на съобщения, намаляване на работата на ниво приложение, ако предаването на съобщения е това, от което се нуждаете.
- По-устойчив на прекъсвания на захранването и прекъсвания (от Redis, поне по подразбиране).
- Поддръжка на клъстер и обединение за разпределени внедрявания.
- Полезни инструменти за управление и наблюдение на вашите внедрявания.
- Поддръжка на практически всички нетривиални езици за програмиране.
- Внедряване с инструмент по ваш избор (Docker, Chef, Puppet и др.).
Кога да използвам RabbitMQ? Бих казал, че това е чудесен избор, когато знаете, че трябва да използвате асинхронно предаване на съобщения, но не сте готови да се справите с огромната сложност на някои от другите опции за опашка в този списък (вижте по-долу).
ActiveMQ
Ако сте в корпоративното пространство (или изграждането на силно разпространено и широкомащабно приложение) и не искате непрекъснато да преоткривате колелото (и да правите грешки по пътя), ActiveMQ заслужава си да се види.
Ето къде ActiveMQ превъзхожда:
- Той е внедрен в Java и така има наистина чиста Java интеграция (следва JMS стандарта).
- Поддържат се множество протоколи: AMQP, MQTT, STOMP, OpenWire и др.
- Обработва сигурността, маршрутизирането, изтичането на съобщенията, анализите и т.н.
- Вградена поддръжка за популярни модели за разпределени съобщения, което ви спестява време и скъпи грешки.
Това не означава, че ActiveMQ е наличен само за Java. Има клиенти за Python, C/C++, Node, .Net и други екосистеми, така че не трябва да има притеснения за евентуален колапс в бъдеще. Освен това ActiveMQ е изграден върху напълно отворени стандарти и изграждането на ваши собствени олекотени клиенти трябва да е лесно.
Всичко казано и направено, моля, имайте предвид, че ActiveMQ е просто брокер и не включва бекенд. Все пак ще трябва да използвате един от поддържаните бекендове, за да съхранявате съобщенията. Включих го тук, защото не е свързан с конкретен език за програмиране (като други популярни решения като Celery, Sidekiq и т.н.)
Amazon MQ
Amazon MQ заслужава бързо, но важно споменаване тук. Ако смятате, че ActiveMQ е идеалното решение за вашите нужди, но не искате сами да се занимавате с изграждането и поддръжката на инфраструктурата, Amazon MQ предлага управлявана услуга за това. Той поддържа всички протоколи, които ActiveMQ прави – няма никаква разлика във функциите – тъй като използва самия ActiveMQ под повърхността.
Предимството е, че това е управлявана услуга, така че не е нужно да се притеснявате за нищо друго освен да я използвате. Има още по-голям смисъл за тези внедрявания, които са на AWS, тъй като можете да използвате други услуги и предложения директно от вашето внедряване (например по-бързи трансфери на данни).
Amazon SQS
Не можем да очакваме Amazon да седи тихо, когато става въпрос за критични инфраструктурни части, нали? 🙂
И така имаме Amazon SQS, която е напълно хоствана проста услуга за опашка (съвсем буквално) от добре познатия гигант AWS. Още веднъж, фините разлики са важни, така че имайте предвид, че SQS няма концепцията за предаване на съобщения. Подобно на Redis, това е прост бекенд за приемане и разпределяне на задачи в опашки.
И така, кога бихте искали да използвате Amazon SQS? Ето някои причини:
- Вие сте фен на AWS и няма да пипате нищо друго (честно казано, има много такива хора и мисля, че няма нищо лошо в това).
- Нуждаете се от хоствано решение, така че се уверете, че процентът на неуспех е нула и нито едно от заданията не е загубено.
- Не искате да изграждате клъстер и трябва да го наблюдавате сами. Или още по-лошо, трябва да изградите инструменти за наблюдение, когато можете да използвате това време за продуктивно развитие.
- Вече имате значителни инвестиции в платформата AWS и да останете заключени има бизнес смисъл.
- Искате фокусирана, опростена система за опашка, без каквито и да било неуредици, свързани с предаването на съобщения, протоколи и какво ли още не.
Като цяло, Amazon SQS е солиден избор за всеки, който иска да включи опашки от задачи в своята система и да не се притеснява да инсталира/наблюдава нещата сам.
бобено стъбло
бобено стъбло съществува от дълго време и е тестван в битки, бърз и лесен бекенд за опашка за работа. Има няколко характеристики на Beanstalkd, които го правят значително различен от Redis:
- Това е строго система за опашка за работа и нищо друго. Вие натискате работни места към него, които по-късно се изтеглят от работниците, работещи по задание. Така че, ако вашето приложение има дори малка нужда от предаване на съобщения, бихте искали да избегнете Beanstalkd.
- Няма разширени структури от данни като набори, приоритетни опашки и т.н.
- Beanstalkd е това, което се нарича опашка First In, First Out (FIFO). Няма как да подредите работни места по приоритет.
- Няма опции за групиране.
Всичко това казано Beanstalkd създава гладка и бърза система за опашки за прости проекти, които живеят на един сървър. За мнозина той е по-бърз и по-стабилен от Redis. Така че, ако имате въпроси с Redis, който просто не можете да разрешите, независимо от всичко, и вашите нужди са прости, Beanstalkd си струва да опитате.
Заключение
Ако сте прочели дотук (или сте стигнали до тук бегло четене 😉), има доста голям шанс да се интересувате от системи за опашка или да имате нужда от такава. Ако е така, списъкът на тази страница ще ви служи добре, освен ако не търсите система за опашка, специфична за език/рамка.
Иска ми се да мога да ви кажа, че опашката е проста и 100% надеждна, но не е така. Объркано е и тъй като всичко е на заден план и се случва много бързо (грешките могат да останат незабелязани и да струват много). Все пак опашките са много необходими отвъд точка и ще откриете, че те са мощно оръжие (може би дори най-мощното) във вашия арсенал. Късмет! 🙂