Търсите ли система от опашки? Или може би търсите по-добра? Ето цялата информация, от която се нуждаете!


Системите за поставяне на опашки са най-добре пазената тайна на развитието на бекенда.

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

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

Преди да започнем, отказ от отговорност: ако вече ви е удобно с системите за опашка и искате да сравните различните опции, следващите няколко уводни раздела ще предизвикат основен сън. �� Така че не се колебайте да скочите право напред. Уводните секции са предназначени за онези, които имат само мътна представа за системите за опашка или просто са чули името минаващо.

Какво представлява опашката?

Нека започнем с разбирането какво е опашка.

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

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

Защо се нуждаете от системи за опашка?

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

Обработка на фона

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

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

Паралелно изпълнение

Много разработчици, особено тези, които предимно кодират по-прости приложения с нисък трафик, имат навика да използват задания 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, поне по подразбиране).
  • Поддръжка на клъстери и федерации за разпределени внедрения.
  • Полезни инструменти за управление и наблюдение на вашите внедрения.
  • Поддръжка на практически всички нетривиални езици за програмиране там.
  • Внедряване с вашия инструмент по избор (Докер, Готвач, Кукленка и т.н.).

Кога да използвам 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

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

  • Това е строго система за опашка на работа и нищо друго. Можете да натиснете работни места към него, които се изтеглят от работниците по-късно. Така че ако приложението ви има дори малка нужда от предаване на съобщение, бихте искали да избегнете Beanstalkd.
  • Няма разширени структури от данни като набори, приоритетни опашки и т.н..
  • Beanstalkd се нарича опашка First In, First Out (FIFO). Няма начин да подредите работни места по приоритет.
  • Няма опции за групиране.

Всичко това каза Beanstalkd създава гладка и бърза система от опашки за прости проекти, които живеят на един сървър. За мнозина той е по-бърз и по-стабилен от Redis. Така че, ако имате въпроси с Redis, който просто не можете да решите, независимо какво и нуждите ви са прости, Beanstalkd си струва да опитате.

заключение

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

Бих искал да ви кажа, че опашката е проста и 100% надеждна, но не е така. Това е разхвърляно и тъй като всичко е на заден план и се случва много бързо (грешките могат да останат незабелязани и да станат много скъпи). Въпреки това опашките са много необходими извън точка и ще откриете, че те са мощно оръжие (може би дори най-мощното) във вашия арсенал. Късмет! ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me