Cloudflare Queues: Háttérfeladatok a Peremen

A Cloudflare Queues arra a problémára ad választ, amelybe előbb-utóbb minden szerver nélküli alkalmazás beleszalad: érkezik egy kérés, amely olyan munkát indít el, amire a felhasználónak nem kellene várnia. A visszaigazoló e-mail kiküldése, a feltöltött kép átméretezése, a rekord szinkronizálása egy külső szolgáltatóhoz. Hagyományos szerveren ezt átadod egy háttérfolyamatnak. A Workers platformon nincs olyan folyamat, amelynek átadhatnád.

A szokásos kerülőutak rosszabbak, mint amilyennek látszanak. Ha a munkát a kérésen belül végzed el, a felhasználó egy levelezőszolgáltatóra vár. Ha kérést lősz ki egy másik Workerhez, és nem várod meg, akkor elveszíted a feladatot minden olyan esetben, amikor a hívó futás ér véget előbb. Egyik megoldás sem éli túl a szolgáltató kiesését.

Amit egy sor valóban ad: tartósságot és újrapróbálkozást, nem sebességet. A producer kiír egy üzenetet, és azonnal visszatér, egy külön consumer Worker felveszi, és ha a consumer elhasal, az üzenet visszakerül a sorba, nem pedig a semmibe. Ennyi az egész haszna. Ha a háttérfeladatod nem viseli el, hogy újra lefusson, egy sor nem fog megmenteni.

Hogyan illeszkednek a darabok

Egy sornak két vége van, és mindkettő egy Worker.

A producer bármely Worker lehet, amelyhez sor-binding tartozik. Meghívja a send műveletet egy üzenettörzzsel, és a hívás abban a pillanatban visszatér, amint az üzenet tartósan eltárolódott. A felhasználó kérése úgy fejeződik be, hogy nem várt a munkára.

A consumer egy Worker, amelyben sorkezelő fut. A Cloudflare egy köteg üzenettel hívja meg, a kezelő pedig nyugtázza mindazt, amit sikeresen feldolgozott. Amit nem nyugtáz, azt a rendszer újra kikézbesíti.

Az újrakézbesítés viselkedése az a rész, amire tervezni érdemes. Egy üzenet többször is megérkezhet, tehát a consumernek idempotensnek kell lennie. Ha kártyát terhelsz egy sorfogyasztóban idempotenciakulcs nélkül, biztosan visszatérítéseket fogsz indítani. Egy e-mailt kétszer elküldeni bosszantó, egy összeget kétszer levonni már ügyfélszolgálati incidens.

A dead letter queue összegyűjti azokat az üzeneteket, amelyek ismételten elbuknak. Nélküle a végleg hibás üzenet addig próbálkozik, amíg el nem fogynak a kísérletei, aztán eltűnik. Vele olyan helyre kerül, ahol meg tudod nézni. Állítsd be, mielőtt szükséged lenne rá.

Mennyibe kerül valójában egy művelet

Az árazási modell épp elég szokatlan ahhoz, hogy megtévessze a csapatokat, mert nem üzenetenként számláznak.

Egy művelet minden 64 KB adatra jár , amelyet kiírnak, kiolvasnak vagy törölnek. Egy 64 KB alatti, normálisan kikézbesített üzenet három műveletbe kerül: egy írás, egy olvasás, egy törlés. Egy 127 KB-os üzenet műveletenként kettőt fogyaszt, vagyis ugyanazért az egyetlen kézbesítésért összesen hatot.

Az újrapróbálkozások átírják a számtant. Minden újrakézbesítés egy újabb olvasás, a dead letter queue-ba írás pedig egy újabb írás. Egy consumer, amely ötször bukik el egy üzeneten, mielőtt sikerrel jár, jóval többe kerül három műveletnél, és ez jó ok arra, hogy a megbízhatatlan consumert javítsd meg, ne pedig az újrapróbálkozások számát emeld.

Számolj a saját forgalmaddal, mielőtt olcsónak könyvelnéd el. Havi egymillió üzenet, egyenként három művelettel, hárommillió művelet, ami a fizetős keret fölé esik, és nagyjából nyolcvan pennybe kerül. Ez valóban olcsó. Napi tízmillió üzenet viszont már egészen más beszélgetés.

A korlátok, amelyek eldöntik az alkalmasságát

A Cloudflare Queues korlátokat leíró dokumentációjából , 2026 augusztusában ellenőrizve.

Kettő ezek közül többet nyom a latban a többinél. A 128 KB-os üzenetplafon azt jelenti, hogy fájlokat nem teszel a sorba. A sorba egy mutatót teszel, a fájlt pedig az R2-be, ami amúgy is a helyes forma. A 25 GB-os feltorlódási keret véd meg a csendes katasztrófától: ha a consumer pénteken elromlik, és senki nem veszi észre, a sor megtelik, és tárolási hibával utasítja vissza az új üzeneteket ahelyett, hogy némán eldobná őket.

Az 5 000 üzenet másodpercenkénti átbocsátás bőkezű, de soronként értendő. Egyetlen túlterhelt sor olyan szűk keresztmetszet, amelyet tervezéssel megszüntethetsz, ha több sor között osztod el a terhelést.

Mikor rossz válasz a Cloudflare Queues

Amikor a munka valóban szinkron. Ha a felhasználónak a képernyőn kell az eredmény, a sorba tétel csak egy plusz kört és egy lekérdezési problémát ad hozzá. Végezd el helyben, és tedd gyorssá.

Amikor rendezett, pontosan egyszeri feldolgozásra van szükséged. A Queues legalább egyszeri kézbesítést ad. Bármi, ami szigorú sorrendet vagy pontosan egyszeri feldolgozást kíván, olyan összehangolást igényel, amit a sor nem nyújt, és a Cloudflare világában ez rendszerint egy Durable Object.

Amikor ütemezett feladatról van szó, nem kiváltottról. Az éjszakai takarításhoz nem kell sor. Egy cron trigger, amely közvetlenül hív meg egy Workert, egyszerűbb, és kevesebb mozgó alkatrésze van.

Amikor a munka túllépi a 15 percet. Az a consumer, amely túlfut a futásidő-korlátján, munka közben áll le. A hosszú, több lépéses folyamatoknak a Cloudflare Workflows való, amelyet lépéseken átívelő tartós végrehajtásra terveztek, nem pedig egy olyan sorfogyasztó, amely negyed óráig próbálja tartani az állapotot.

A szerver nélküli API építéséről szóló útmutatónk Cloudflare Workersszel azt a kérésútvonalat mutatja be, amely rendszerint ezeket a feladatokat termeli, a Cloudflare Workers és az AWS Lambda összevetése pedig azt, mennyiben tér el a végrehajtási modell attól az SQS és Lambda mintától, amellyel a legtöbb csapat érkezik.

Hol érdemes kezdeni

Válaszd ki azt az egyetlen munkadarabot a kéréskezelődben, amelyre a felhasználónak nem kell várnia, és csak azt mozdítsd el. Adj neki dead letter queue-t már az első napon, tedd idempotenssé a consumert, és nézd a feltorlódás mérőszámát ahelyett, hogy üresnek feltételeznéd.

A Mecanik a szoftverfejlesztési csapatán keresztül tervez és vizsgál felül peremarchitektúrákat, beleértve azt a részt is, amikor valaki megkérdezi, kell-e egyáltalán sor a feladathoz. A legtöbb rendszernek egy vagy kettő kell, nem funkciónként egy.

Kapcsolódó olvasmányok: Cloudflare Hyperdrive: Postgres a peremről , Hogyan fejlesszünk webalkalmazást 2026-ban , Cloudflare D1: szerver nélküli SQL-adatbázis építése a peremen és Cloudflare Workers AI: AI-modellek futtatása a peremen 2026-ban .

Gyakran ismételt kérdések

Mennyibe kerül a Cloudflare Queues? A Workers Free csomag napi 10 000 műveletet tartalmaz, a fizetős csomag pedig havi egymilliót, a további műveletek milliónként 0,40 $-ba kerülnek, egress díj pedig nincs. Egy művelet minden kiírt, kiolvasott vagy törölt 64 KB után jár, így egy szokásos, 64 KB alatti üzenet összesen három műveletbe kerül: egy írás, egy olvasás és egy törlés.

Mi számít műveletnek a Cloudflare Queues esetében? Minden kiírt, kiolvasott vagy törölt 64 KB adat. A 64 KB-nál kisebb üzenet műveletenként egybe kerül, a 127 KB-os üzenet viszont kettőbe. Minden újrapróbálkozás egy újabb olvasást, a dead letter queue-ba írás pedig egy újabb írást ad hozzá, így egy megbízhatatlan consumer lényegesen többe kerül az üzenetenkénti három alapműveletnél.

Mekkora lehet egy üzenet a Cloudflare Queues szolgáltatásban? Üzenetenként 128 KB, a kötegelt küldés pedig 100 üzenetre vagy összesen 256 KB-ra korlátozott. Épp e plafon miatt a tartalmat az R2-ben vagy más objektumtárolóban tárolod, és csak egy mutatót teszel a sorba, ami a korláttól függetlenül is a jobb megoldás.

Garantál a Cloudflare Queues pontosan egyszeri kézbesítést? Nem. A kézbesítés legalább egyszeri, tehát egy üzenet többször is megérkezhet, és a consumernek idempotensnek kell lennie. Ha idempotenciakulcs nélkül terhelsz meg egy fizetést vagy írsz jóvá összeget egy consumerben, az előbb-utóbb duplázni fog. A szigorú sorrendhez vagy a pontosan egyszeri feldolgozáshoz Durable Object kell helyette.

Mikor ne használjam a Cloudflare Queues szolgáltatást? Amikor a felhasználó az eredményre vár, amikor szigorú sorrendre vagy pontosan egyszeri feldolgozásra van szükséged, amikor a feladat ütemezett és nem kiváltott, és egy cron trigger is megtenné, vagy amikor a munka tovább tart a consumer 15 perces futásidő-korlátjánál. Épp az utolsó esetre való a Cloudflare Workflows.