Cloudflare Queues: Joburi De Fundal La Edge

Cloudflare Queues rezolvă problema în care ajunge, mai devreme sau mai târziu, orice aplicație serverless: sosește o cerere care declanșează o muncă pe care utilizatorul nu ar trebui să o aștepte. Trimiterea emailului de confirmare, redimensionarea fișierului încărcat, sincronizarea înregistrării către un serviciu extern. Pe un server clasic dai treaba asta unui proces de fundal. Pe Workers nu există niciun proces căruia să i-o dai.

Soluțiile de compromis obișnuite sunt mai proaste decât par. Dacă faci munca în linie, utilizatorul ajunge să aștepte un furnizor de email. Dacă lansezi o cerere către alt Worker fără să o aștepți, pierzi jobul de fiecare dată când invocarea apelantă se termină prima. Niciuna dintre variante nu supraviețuiește unei căderi a furnizorului.

Ce îți oferă de fapt o coadă: durabilitate și reîncercări, nu viteză. Producătorul scrie un mesaj și revine imediat, un Worker consumator separat îl preia, iar dacă acesta eșuează mesajul se întoarce în coadă în loc să dispară în neant. Aceasta este toată valoarea. Dacă jobul tău de fundal nu suportă să fie reluat, o coadă nu te va salva.

Cum se îmbină piesele

O coadă are două capete și amândouă sunt Workers.

Producătorul este orice Worker care are un binding de coadă. Apelează send cu un corp de mesaj, iar apelul revine imediat ce mesajul a fost stocat durabil. Cererea utilizatorului se încheie fără să aștepte munca propriu-zisă.

Consumatorul este un Worker cu un handler de coadă. Cloudflare îl invocă cu un lot de mesaje, iar handlerul confirmă fiecare mesaj pe care îl procesează cu succes. Tot ce nu este confirmat este relivrat.

Comportamentul de relivrare este partea în jurul căreia merită să proiectezi. Un mesaj poate ajunge de mai multe ori, ceea ce înseamnă că un consumator trebuie să fie idempotent. Să debitezi un card într-un consumator de coadă fără cheie de idempotență este calea sigură către rambursări. Un email trimis de două ori este enervant, o plată încasată de două ori este un incident de suport.

O dead letter queue prinde mesajele care eșuează în mod repetat. Fără ea, un mesaj definitiv stricat este reîncercat până își epuizează tentativele, apoi dispare. Cu ea, ajunge undeva unde îl poți inspecta. Configureaz-o înainte să ai nevoie de ea.

Cât costă în realitate o operațiune

Modelul de preț este suficient de neobișnuit încât să încurce echipele, pentru că factura nu se face pe mesaj.

O operațiune este numărată pentru fiecare 64 KB de date scrise, citite sau șterse. Un mesaj sub 64 KB livrat normal costă trei operațiuni: o scriere, o citire, o ștergere. Un mesaj de 127 KB costă două operațiuni pentru fiecare acțiune, deci șase în total pentru aceeași livrare unică.

Reîncercările schimbă aritmetica. Fiecare relivrare este încă o citire, iar o scriere în dead letter queue este încă o scriere. Un consumator care eșuează de cinci ori pe un mesaj înainte să reușească costă mult mai mult decât trei operațiuni, ceea ce este un motiv bun să repari un consumator instabil în loc să îi crești numărul de reîncercări.

Fă socoteala pe traficul tău înainte să presupui că este ieftin. Un milion de mesaje pe lună, cu trei operațiuni fiecare, înseamnă trei milioane de operațiuni, adică peste pragul inclus în planul plătit, la un cost de aproximativ optzeci de penny. Asta chiar este ieftin. Zece milioane de mesaje pe zi este o discuție complet diferită.

Limitele care decid dacă ți se potrivește

Din documentația limitelor Queues a Cloudflare, verificată în august 2026.

Două dintre ele contează mai mult decât restul. Plafonul de 128 KB per mesaj înseamnă că nu pui fișiere într-o coadă. Pui un pointer în coadă și fișierul în R2, care oricum este forma corectă. Backlogul de 25 GB este ceea ce te protejează de dezastrul tăcut: dacă un consumator se strică vineri și nimeni nu observă, coada se umple și apoi respinge mesajele noi cu o eroare de stocare, în loc să le arunce pe tăcute.

Debitul de 5.000 de mesaje pe secundă este generos, dar se aplică per coadă. O singură coadă suprasolicitată este un blocaj pe care îl poți elimina din proiectare, distribuind încărcarea pe mai multe cozi.

Când Cloudflare Queues este răspunsul greșit

Când munca este cu adevărat sincronă. Dacă utilizatorul are nevoie de rezultat pe ecran, punerea lui în coadă adaugă doar un drum în plus și o problemă de polling. Fă-o în linie și fă-o rapid.

Când ai nevoie de procesare ordonată și exactly-once. Queues îți oferă livrare at-least-once. Orice necesită ordine strictă sau semantică exactly-once are nevoie de o coordonare pe care coada nu o oferă, iar pe Cloudflare asta înseamnă de obicei un Durable Object.

Când este un job programat, nu unul declanșat. O curățenie de noapte nu are nevoie de coadă. Un cron trigger care invocă direct un Worker este mai simplu și are mai puține piese în mișcare.

Când munca depășește 15 minute. Un consumator care trece de limita sa de execuție va fi oprit în mijlocul jobului. Procesele lungi, cu mai mulți pași, vor Cloudflare Workflows, construit pentru execuție durabilă de-a lungul pașilor, nu un consumator de coadă care încearcă să țină starea un sfert de oră.

Ghidul nostru despre construirea unui API serverless cu Cloudflare Workers acoperă traseul cererii care produce de obicei aceste joburi, iar Cloudflare Workers față de AWS Lambda arată cum diferă modelul de execuție de tiparul SQS plus Lambda cu care vin majoritatea echipelor.

De unde începi

Alege singura bucată de muncă din handlerul tău de cereri pe care utilizatorul nu trebuie să o aștepte și mută doar atât. Dă-i o dead letter queue din prima zi, fă consumatorul idempotent și urmărește metrica de backlog în loc să presupui că este goală.

Mecanik proiectează și analizează arhitecturi edge prin echipa noastră de dezvoltare software , inclusiv partea în care cineva întreabă dacă jobul chiar are nevoie de o coadă. Majoritatea sistemelor vor una sau două, nu una pentru fiecare funcționalitate.

Lecturi conexe: Cloudflare Hyperdrive: Postgres de la edge , Cum să construiești o aplicație web în 2026: ghid UK , Cloudflare D1: construiește o bază de date SQL serverless la edge și Cloudflare Workers AI: rulează modele AI la edge în 2026 .

Întrebări frecvente

Cât costă Cloudflare Queues? Planul Workers Free include 10.000 de operațiuni pe zi, iar planul Paid include un milion de operațiuni pe lună, operațiunile suplimentare costă 0,40 $ per milion și nu există taxe de egress. O operațiune este numărată pentru fiecare 64 KB scriși, citiți sau șterși, așa că un mesaj normal sub 64 KB costă în total trei operațiuni: o scriere, o citire și o ștergere.

Ce se numără ca operațiune în Cloudflare Queues? Fiecare 64 KB de date scrise, citite sau șterse. Un mesaj mai mic de 64 KB costă o operațiune pentru fiecare acțiune, în timp ce un mesaj de 127 KB costă două pentru fiecare acțiune. Fiecare reîncercare adaugă încă o citire, iar o scriere în dead letter queue adaugă încă o scriere, deci un consumator instabil costă considerabil mai mult decât cele trei operațiuni de bază per mesaj.

Care este dimensiunea maximă a unui mesaj în Cloudflare Queues? 128 KB per mesaj, iar trimiterile în lot sunt limitate la 100 de mesaje sau 256 KB în total. Din cauza acestui plafon stochezi conținutul în R2 sau în alt object store și pui în coadă doar un pointer, ceea ce este oricum designul mai bun, indiferent de limită.

Garantează Cloudflare Queues livrarea exactly-once? Nu. Livrarea este at-least-once, deci un mesaj poate ajunge de mai multe ori, iar consumatorul tău trebuie să fie idempotent. Dacă încasezi o plată sau emiți un credit într-un consumator fără cheie de idempotență, mai devreme sau mai târziu se va dubla. Ordinea strictă sau semantica exactly-once cer în schimb un Durable Object.

Când nu ar trebui să folosesc Cloudflare Queues? Când utilizatorul așteaptă rezultatul, când ai nevoie de ordine strictă sau de procesare exactly-once, când jobul este programat în loc să fie declanșat și un cron trigger ar fi de ajuns, sau când munca durează mai mult decât limita de 15 minute a consumatorului. Exact pentru ultimul caz există Cloudflare Workflows.