Проверка на задачи в опашка в Laravel: конфигурация, наблюдение и контрол

Начало » Python » Проверка на задачи в опашка в Laravel: конфигуриране, наблюдение и контрол

Проверката на задачи в опашка в Laravel е много повече от проверка дали дадена задача е чакаща или завършена; тя включва разбиране на това как работят връзките и опашките, как се държат работниците в продукцията, как да се ограничават, планират и наблюдават задачи и как да се реагира, когато нещо се повреди. Съвременният Laravel добавя мощни инструменти като атрибути, middleware и Horizon в допълнение към класическата система за опашки, така че да можете да виждате, контролирате и отстранявате грешки в действителност, когато се случва на заден план във вашето приложение.

Ако редовно се занимавате с дългосрочни задачи, като изпращане на имейли, обработка на CSV файлове, манипулиране на изображения или достъп до отдалечени API, Възможността за безопасно проучване, приоритизиране, регулиране и повторен опит за задачи е от решаващо значение. В това ръководство ще разгледаме цялата картина: от основната конфигурация на опашката и класовете задачи до уникални и криптирани задачи, междинен софтуер, забавено изпълнение с атрибути като... #, вериги от задачи и партиди, наблюдение на Laravel Horizon, обработка на неуспешни задачи, настройване на работници и дори как да тествате и фалшифицирате опашките си.

Разбиране на опашките, връзките и драйверите в Laravel

Laravel предлага унифициран API за опашки, разположен върху множество бекендове, като например база данни, Redis, Amazon SQS и Beanstalkd. плюс синхронен и нулев драйвер за локално развитие или изхвърляне на задачи. Всичко започва в config/queue.php, където дефинирате вашата опашка връзки и техните опашки по подразбиране, поведение при повторен опит и времеви ограничения.

Ключова концепция за правилното инспектиране на задачите е разликата между връзка и опашка: a връзка представлява бекенд услуга (например, redis, sqs, database), докато всяка връзка може да има множество имена тура като default, emails, high or lowКогато изпратите задача без да посочите опашка, Laravel я поставя в опашката, дефинирана във връзката. queue опция.

Това разделяне ви позволява да класифицирате и приоритизирате натоварванията, като просто ги преместите в различни опашки на една и съща връзка, и по-късно да стартират работници, които слушат само определени опашки или ги приоритизират в даден ред; например, един работник може да бъде стартиран с php artisan queue:work --queue=high,low така че всички high задачите се обработват преди всичко в low.

Всеки шофьор има няколко специфични изисквания, които трябва да изпълните, преди да можете безопасно да проверявате и обработвате задачи, като например таблици на базата данни за database драйвер, правилна конфигурация на Redis за redis драйвер и AWS идентификационни данни за SQS. Без тази основа, инструментите за проверка на опашки няма да имат нищо последователно за разглеждане.

Драйвери за бази данни и Redis, подробности за блокиране и конфигурация

Когато използвате драйвера за опашка на базата данни, задачите са просто редове в таблица на базата данни, което прави директната проверка тривиална със SQL. В съвременния Laravel тази таблица обикновено се създава чрез миграция по подразбиране create_jobs_tableно ако проектът ви е по-стар или персонализиран, можете да го генерирате с php artisan make:queue-table (или queue:table в по-ранни версии) и след това изпълнете php artisan migrate.

Драйверът на Redis изисква Redis връзка, дефинирана в config/database.php, и съхранява задачи в Redis списъци и свързани ключове. Когато използвате Redis Cluster, имената на опашките трябва да включват хаштаг, като например {default} така че всички свързани ключове да попаднат в един и същ хеш слот; в противен случай може да се сблъскате с фини грешки, при които една логическа опашка е разпределена в множество слотове.

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

Както връзките към базата данни, така и тези към Redis предоставят retry_after опция в config/queue.php който контролира изтичането на срока на работа, което означава колко дълго една задача може да се счита за „в процес на изпълнение“, преди системата да приеме, че работникът е починал и да я върне в опашката. За точна проверка трябва да зададете retry_after да бъде малко по-голямо от максималното време, разумно необходимо за дадена работа.

Други драйвери, като Amazon SQS и Beanstalkd, идват със собствени предварителни изисквания, включително Composer пакети като aws/aws-sdk-php за SQS или pda/pheanstalk за Beanstalkd и специфични за SQS времеви ограничения за видимост, конфигурирани от страната на AWS, вместо retry_after стойности в queue.php.

Създаване, структуриране и проверка на работни места

По конвенция, Laravel поддържа задачи за опашка в app/Jobs указател, и можете да ги генерирате с php artisan make:job SomeJobName, следвайки доброто програмна логикаГенерирани задачи се изпълняват Illuminate\Contracts\Queue\ShouldQueue, което сигнализира на рамката да ги постави в опашката, вместо да ги изпълнява вградено.

Типичен клас задачи съдържа конструктор за събиране на данни и handle метод, при който работата действително се извършва, например обработка на качен подкаст, преоразмеряване на изображения или изпращане на приветствен имейл. Благодарение на характеристики като Queueable, Dispatchable, InteractsWithQueue намлява SerializesModels, по-голямата част от шаблона за изпращане и сериализиране се обработва вместо вас.

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

Когато задачите включват тежки или сложни взаимоотношения, може изобщо да не искате те да бъдат сериализирани, в този случай можете да премахнете връзките чрез $model->withoutRelations(), премахват отделни взаимоотношения или в съвременния Laravel маркират специфични свойства, промотирани от конструктора, или дори цели класове задачи с WithoutRelations атрибут, така че полезните товари да останат компактни и фокусирани.

Двоични данни, като например сурови изображения или съдържание на файлове, никога не трябва да се изпращат директно като низове в свойствата на заданието, защото JSON сериализацията вероятно ще ги повреди; вместо това, кодирайте това съдържание в base64 или го съхранете някъде (диск, S3, база данни) и оставете заданието да го извлече отново чрез препратка, когато се изпълни.

Изпращане, забавяне и условно изпълнение на задачи

Изпращането на задача обикновено е толкова просто, колкото извикването на нейната static функция. dispatch метод, например ProcessPodcast::dispatch($podcast) от контролер. Под капака това създава екземпляр и го изпраща към конфигурираната връзка и опашка, готов за обработка от страна на работниците.

Ако трябва да изпълните задача незабавно в текущия процес, вместо да я поставите на опашка, можеш да използваш dispatchSync (или по-стари dispatchNow), което е полезно за тестове или операции, които трябва да завършат преди връщане на отговор. Laravel също така предоставя отложено синхронно изпращане чрез deferred намлява background връзки, което ви позволява да обработвате задачи след изпращане на HTTP отговор, без да е необходим отделен работен процес на системно ниво.

Условното изпращане е лесно с помощници като dispatchIf намлява dispatchUnless, които изпращат задачата само когато дадено условие е вярно или невярно. Този модел държи класовете ви на задачи фокусирани, като същевременно прави логиката на изпращане четлива и самодокументираща се.

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

Обратно, ако връзката е конфигурирана да изпраща след commit по подразбиране и ви е необходимо задачата да се изпълни веднага, можете да се обадите ->beforeCommit() (или съответния метод за вашата Laravel версия), за да се откажете и да разрешите незабавно поставяне в опашка, което може да бъде полезно, когато самата задача извършва компенсираща работа в случай на неуспех на по-късна стъпка.

Планиране на изпълнението на опашката с атрибута #

Laravel исторически е използвал delay() метод в конструктора на задачи за отлагане на изпълнението на задача, като Job::dispatch()->delay(now()->addMinutes(10)), но съвременният Laravel (13.5 и по-нови версии) въвежда по-изчистен и по-декларативен подход, използвайки нативния PHP атрибут #.

с # дефинирате времето за изчакване директно в класа на заданието, например #, като запазва правилата за време там, където им е мястото, вместо да ги разпръсква по контролери и услуги. Това прави проверката на задачите много по-лесна, защото както поведението, така и планирането са видими в дефиницията на задачата.

Атрибутът поддържа множество мерни единици, като секунди, минути, часове и дни, така че можете да пишете задачи като бърза задача за 30 секунди, генериране на отчет за 2 часа или напомняне за изоставена количка за 1 ден с изразителни атрибути, а не с ad-hoc изчисления на датата по време на изпращане.

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

Можете спокойно да комбинирате # с други атрибути като # или свойства, свързани с повторен опит, изграждане на задачи, които не само започват по-късно, но и избягват едновременна модификация на един и същ ресурс и прилагат правила за отсрочка или повторен опит. Това, което трябва да избягвате, е смесването # намлява ->delay() при едно и също изпращане на задача, тъй като става неясно кое правило трябва да победи и усложнява отстраняването на грешки.

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

Мидълуерът за задачи ви позволява да обгърнете междусекторната логика около изпълнението на задачите, подобно на HTTP middleware, който обгръща заявките. Вместо да претрупва handle метод със заключване, ограничаване или проверки за безопасност, можете да капсулирате тези проблеми в специални класове за междинен софтуер.

Класически пример е ограничаването на скоростта, базирано на Redis, където искате само един екземпляр на задача да се изпълнява на всеки няколко секунди, като например изпращане на известия до външен API със строги ограничения на скоростта. Въпреки че можете да извикате Redis::throttle() директно в handle, поставянето на тази логика в междинен софтуер поддържа самата задача чиста и ви позволява да използвате повторно един и същ ограничител в множество задачи.

Laravel се доставя с удобен междинен софтуер като RateLimited намлява RateLimitedWithRedis, които се свързват с RateLimiter дефинициите на фасадите, които конфигурирате в AppServiceProvider::boot()Тези междинни софтуери могат автоматично да връщат задачи обратно в опашката, когато ограниченията са превишени, като увеличават броя на опитите и прилагат отсрочка според вашите атрибути или retryUntil метод.

За да се предотврати едновременното докосване на два ресурса, можете да върнете WithoutOverlapping междинен софтуер от заданието middleware() метод с ключ, базиран на нещо като потребителски идентификатор или идентификатор на поръчка. Припокриващите се задачи ще бъдат забавени или изтрити в зависимост от вашата конфигурация, а също така можете да зададете изрично изтичане на заключването с expireAfter за да се избегне задържането на заключванията завинаги, ако нещо се срине.

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

Уникални, декодирани и криптирани задания

Понякога проверката ви ще покаже много еднакви задачи в опашката, които е трябвало да бъдат обединени в една, например при актуализиране на индекс за търсене или синхронизиране на продукт с външна услуга. За да се справи с това, Laravel предлага ShouldBeUnique намлява ShouldBeUniqueUntilProcessing договори, които гарантират, че само една задача с даден уникален ключ се намира на опашката в даден момент.

Можете да дефинирате ключа за уникалност чрез uniqueId метод или атрибут, като например UniqueFor, често го свързвайки с продуктов идентификатор, потребителски идентификатор или подобен идентификатор. Laravel използва кеш системата, за да получи заключване при изпращане и го освобождава, когато задачата приключи или изчерпи всичките си опити, като можете да изберете кое кеш хранилище да използвате чрез uniqueVia метод.

Друг модел са debounced задачите, при които честите изпращания в кратък прозорец трябва да се свиват, така че да се изпълни само последното, като например запазване на често редактирани настройки или стрийминг на промени към индекс за търсене. С DebounceFor атрибут, можете да кажете на Laravel да отложи изпълнението за определен интервал и да отхвърли по-стари чакащи задачи за същия ключ, дори при задействане на JobDebounced събитие, когато това се случи.

Ако поверителността на полезния товар на заданието е от значение, можете да внедрите ShouldBeEncrypted интерфейс в класа на заданието, Така Laravel автоматично криптира сериализираната задача, преди да я изпрати към backend-а. Това е полезно, когато трябва да проверите метаданните на задачата на високо ниво, но не можете да изложите сурови имейл адреси, токени или лични данни по време на пренос или в състояние на покой в ​​опашката backend-а.

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

Верижно свързване на задачи, пакети и разширена оркестрация

За работни потоци, където множество стъпки трябва да се изпълняват последователно, верижното подреждане на задачи ви позволява да поставите на опашка основна задача, последвана от списък със зависими задачи, всички от които се изпълняват само ако предишният е успешен. Можете да се свържете чрез Bus::chain() или помощници като ProcessPodcast::withChain(), и можете също така да свързвате затваряния, не само класове.

Верижните задачи могат да споделят една и съща връзка и опашка чрез използване onConnection намлява onQueue, и можете да регистрирате catch затваряне за обработка на всяка повреда във веригата, като се получи точното изключение, което я е причинило. Това улеснява проверката защо дадена последователност е спряла и съответното реагиране, като например изпращане на предупреждения или отмяна на частична работа.

Когато искате да изпълнявате много задачи паралелно и след това да действате, след като всички те завършат, В действие влизат пакети от задачи, изградени върху командната шина на Laravel. Дефинирате пакет чрез Bus::batch(), прикачете then, catch намлява finally обратни извиквания, по избор му дайте приятелско име и го изпратете. Пакетите се проследяват в специално хранилище (база данни или DynamoDB), така че можете да заявите състояние, напредък и неуспехи.

Партидите могат да съдържат прости задачи, вложени вериги и дори йерархии, където една задача хидратира партида с допълнителна работа, което е особено полезно за големи импорти, където първо разделяте файл и след това изпращате задачи за обработка за всяка част. Можете дори да добавяте задачи към работеща партида от самата задача, използвайки batch() помощник и add() метод.

За дълго работещи системи ще е добре да премахнете стари пакетни метаданни, за да избегнете неограниченото разрастване на таблици или дялове на DynamoDB. което обикновено се прави с помощта на queue:prune-batches Команда Artisan по график, с опции за премахване само на стари, недовършени или анулирани партиди и, в случая на DynamoDB, чрез конфигуриране на TTL атрибути, така че AWS автоматично да изтрива изтекли записи.

Управление, настройване и проверка на работниците в опашките

Основният двигател, който консумира вашите задачи в опашката, е queue:work Занаятчийска команда, който стартира дългоживеещ работен процес, който продължава да извлича и изпълнява задачи, докато не бъде спрян. За отстраняване на грешки можете да използвате --once or --max-jobs опции за обработка на ограничен брой задачи или --max-time да излезе след определен брой секунди.

Работниците могат да слушат по определена връзка и списък с опашки, например php artisan queue:work redis --queue=emails or --queue=high,low, така че по време на проверката да знаете точно кой работник е отговорен за кое натоварване. Ако трябва да изчистите всички чакащи задачи от опашка, queue:clear е достъпно с параметри за връзка и опашка.

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

Работниците също са засегнати от --sleep, който контролира колко дълго ще се правят паузи, когато няма налични задачи, и по режим на поддръжка: по подразбиране работниците спират обработката по време на поддръжка, но можете да промените това с --force флаг. Laravel също така поддържа паузиране на работници на ниво опашка с queue:pause и по-късно възобновяването им с queue:continue.

Тъй като опашечните работници са дългоживеещи демони, ви е необходим мениджър на процеси, като например Supervisor (в Linux) или systemd услуги, за да се гарантира, че те остават активни. рестартиране при неуспех и мащабиране чрез изпълнение на множество работни процеси. Конфигурациите на супервайзора обикновено декларират numprocs, командата Artisan за изпълнение, регистриране на пътища, рестартиране на политики и a stopwaitsecs което трябва да надвишава най-дългата Ви продължителност на работата.

Мониторинг и проверка на опашки с Laravel Horizon

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

Инсталацията е лесна чрез Composer и php artisan horizon:install, който публикува config/horizon.php файл, в който конфигурирате супервайзори, връзки към опашки, стратегии за балансиране и ограничения, като например колко процеса да се изпълняват или кои опашки да се наблюдават. Стартирането на Horizon е толкова просто, колкото изпълнението му. php artisan horizon, но в производствения режим трябва отново да го стартирате под Supervisor или systemd, за да го поддържате.

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

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

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

Обработка на неуспешни задачи, повторни опити и стратегии за отлагане

Във всяко сериозно приложение някои задачи в опашката евентуално ще се провалят, и Laravel предлага пълен поток за регистрирането, проверката, повторното им изпълнение и почистването. Неуспешните асинхронни задачи се съхраняват в failed_jobs таблица (или таблица на DynamoDB), която можете да създадете с вградени миграции или чрез специални команди на Artisan.

Максималният брой опити, които една задача може да има, се контролира чрез комбинация от опции за работници и атрибути на задачата. , като --tries on queue:work or Tries/MaxExceptions атрибути на самата работа, а също така можете да предоставите retryUntil метод за времеви ограничения, вместо за броене на опити. Когато дадена задача надвиши разрешените опити, тя се счита за неуспешна и се регистрира.

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

Когато проверявате неуспешни задачи и искате да ги опитате отново, можеш да използваш php artisan queue:failed да ги изброя, queue:retry <id|all> да ги пренаредим на опашка, queue:forget <id> да изтриете едно, или queue:flush да ги изтриете всички, по избор ограничено от възрастта чрез --hours флаг. За неуспешни задачи, поддържани от DynamoDB, има и поддръжка за премахване на стари записи, като същевременно се запазват по-нови за анализ.

Работата може да внедри failed(Throwable $exception) метод за извършване на почистване, когато най-накрая се провалят, изпращане на предупреждения, отмяна на частични действия или регистриране на допълнителен контекст. Типът изключение ви показва дали неуспехът се дължи на максимален брой опити, време за изчакване или реално генерирано изключение. handle, което може да насочва вашата логика за отстраняване.

За допълнителен контрол можете също да извикате ръчно $this->fail() or $this->release() от работното място, по избор, предаване на забавяне за отлагане на следващия опит. Middleware като FailOnException позволява ви да съкратите повторните опити, когато възникнат специфични типове изключения, поддържайки нюансирани стратегии, при които временните проблеми се опитват да се отстранят отново, но забранените грешки се провалят окончателно.

Тестване, фалшифициране и програмна проверка на опашки

Ефективната инспекция не спира в производството; вашите тестове трябва да потвърждават как се разпределят и свързват задачите, и на Laravel Queue::fake() намлява Bus::fake() правят това много по-лесно. Чрез фалшифициране на опашката предотвратявате реалното изпълнение на задачи, като същевременно можете да проверите дали са били изпратени с правилните типове и данни.

Помощници като Queue::assertPushed, assertNotPushed, assertClosurePushed и техните отрицания ви позволяват да изразявате очаквания по отношение на класове задачи или дори затваряния, които проверяват екземпляри на задачи за специфични атрибути. Можете също така да фалшифицирате само определени задачи или да фалшифицирате всичко освен набор, което ви позволява да смесвате реално и фалшиво поведение в един и същ набор от тестове.

За вериги, Bus::assertChained намлява assertDispatchedWithoutChain помощ за потвърждаване на оркестрацията на работата, докато твърдения, свързани с партиди, като например assertBatched намлява assertBatchCount Проверете дали групите от задачи са групирани правилно, като очакваните типове задачи са налични в дефинициите на пакетите.

Понякога е необходимо да тествате как дадена задача взаимодейства със собствения си жизнен цикъл на опашката, като например връщане на себе си за по-късно или изтриване на себе си при определени условия; за този сценарий Laravel предоставя помощни функции за инжектиране на фалшиви взаимодействия с опашката в екземпляр на задача, изпълнение handle и след това да се потвърдят методи като assertReleased or assertDeleted върху фалшивия слой.

Накрая, системата за опашки предоставя събития от ниско ниво и обратни извиквания за допълнителна инструментация, включително и Queue::before, Queue::after, Queue::looping, Queue::failing намлява QueueBusy събития, повдигнати от queue:monitor, като всички те могат да бъдат свързани към вашите доставчици на услуги за проследяване на показатели, показване на персонализирани табла за управление или интегриране с външни платформи за мониторинг.

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