Röviden: A három szolgáltatás nem versenytárs, hanem különböző kézbesítési garancia és minta. A fan-out, a sorrend és a retry igénye dönti el, melyik való a feladathoz.
Amint egy serverless rendszer túlnő az egyszerű kérés-válasz mintán, felmerül a kérdés: hogyan kommunikáljanak a komponensek egymással aszinkron módon? A három leggyakoribb válasz — sor (SQS), publikálás-feliratkozás (SNS) és eseménybusz (EventBridge) — gyakran összemosódik a fejekben, pedig más problémára valók. A jó választáshoz nem az kell, hogy tudd, melyik a „legjobb”, hanem hogy tisztában legyél a kézbesítési modelljükkel.
Három különböző alapminta
- Sor (SQS) — egy termelő beteszi az üzenetet, egy fogyasztó kiveszi és feldolgozza. Egy üzenetet jellemzően egy fogyasztó dolgoz fel. Puffer és terheléskiegyenlítés a fő szerepe.
- Publikálás-feliratkozás (SNS) — egy üzenet több feliratkozóhoz jut el egyszerre (fan-out). Ha egy eseményről többeknek kell tudnia, ez a minta.
- Eseménybusz (EventBridge) — események útválasztása szabályok alapján, gazdag szűréssel, akár külső rendszerek és menedzselt integrációk felé.
A döntés a garanciákon múlik
A választásnál a lényegi kérdések: kell-e fan-out (több fogyasztó ugyanarra az eseményre), kell-e tartós puffer (a fogyasztó lassabb, mint a termelő), és milyen a retry- meg sorrendigény.
| Igény | SQS | SNS | EventBridge |
|---|---|---|---|
| Tartós puffer, terheléskiegyenlítés | Erős | Nem | Korlátozott |
| Fan-out több fogyasztónak | Nem közvetlenül | Erős | Erős |
| Tartalom szerinti útválasztás | Nem | Korlátozott | Erős |
| Beépített retry a fogyasztóig | Erős (DLQ-val) | Kevésbé | Igen |
A klasszikus kombináció
A gyakorlatban ezek gyakran együtt dolgoznak, nem egymás helyett. Elterjedt minta, hogy egy esemény fan-outol több feliratkozóhoz (SNS), és minden feliratkozó egy saját sorba (SQS) kapja, hogy pufferelten, a saját tempójában, megbízhatóan dolgozhassa fel. Így megkapod a szórást és a tartós, retry-olható feldolgozást is.
Az idempotencia mint alapfeltétel
Mindhárom modellnél számíts arra, hogy egy üzenet többször is megérkezhet (legalább-egyszer kézbesítés a jellemző). Ezért a fogyasztónak idempotensnek kell lennie: ugyanaz az üzenet kétszer feldolgozva ne okozzon dupla hatást. Ezt nem a sor oldja meg helyetted, hanem az alkalmazáslogika — egy feldolgozási azonosító nyilvántartásával vagy természetes idempotenciával.
Amikor az EventBridge a helyes
Az eseménybusz akkor jön elő, amikor sok forrásból, sokféle esemény érkezik, és ezeket tartalom alapján kell különböző célokhoz irányítani — esetleg külső szolgáltatások vagy menedzselt integrációk felé. Ha csak egyszerű pufferre vagy fan-outra van szükséged, az EventBridge túlzás lehet; a sor vagy a pub-sub egyszerűbb.
A kézbesítési garanciák megértése
A három szolgáltatás közötti választás gyakran a kézbesítési garanciákon dől el, amiket érdemes tisztán érteni. A legtöbb aszinkron rendszer legalább-egyszer kézbesítést ad, ami azt jelenti: egy üzenet többször is megérkezhet. Ez nem hiba, hanem tervezési peremfeltétel — a fogyasztónak fel kell készülnie a duplikátumra. A pontosan-egyszer feldolgozás illúzió, amit a fogyasztó oldali idempotenciával kell megvalósítani.
A sorrend is fontos szempont: bizonyos üzenetsorok garantálják a sorrendet, mások nem. Ha az üzenetek sorrendje számít (például egy állapotgép eseményeinél), ezt előre tisztázni kell, mert nem minden opció adja ingyen.
A holtlevél-sor tervezése
Bármelyik mintát választod, a holtlevél-sor (DLQ) elengedhetetlen. A feldolgozhatatlan üzenetnek mennie kell valahová, ahol később megvizsgálható — különben vagy elveszik, vagy végtelen retry-ba ragad és erőforrást éget. A DLQ mellé riasztás és rendszeres átnézés kell: egy figyelmen kívül hagyott DLQ csak egy csendes szemetes.
- Minden fogyasztóhoz állíts be DLQ-t.
- Riassz, ha üzenet kerül a DLQ-ba.
- Nézd át rendszeresen, mi és miért került oda.
A minták kombinálása
A gyakorlatban a három szolgáltatás gyakran együtt dolgozik. Egy klasszikus, erős minta: az esemény fan-outol több feliratkozóhoz (pub-sub), és minden feliratkozó egy saját sorba kapja, hogy pufferelten, a saját tempójában, megbízhatóan dolgozhassa fel. Az eseménybusz pedig a tartalom szerinti útválasztást adja hozzá, ha sokféle esemény sokféle célhoz tart. Nem versenytársak, hanem egy eszközkészlet — a feladat dönti el, melyik kombináció kell.
Mit jelent ez neked?
Ne azt kérdezd, melyik üzenetkezelő a legjobb, hanem azt, milyen kézbesítési mintát igényel a feladat. Sorra és pufferre a sor, egy eseményről többek értesítésére a pub-sub, tartalom szerinti, sokforrású útválasztásra az eseménybusz való — és ezek gyakran együtt a legerősebbek. Bármit választasz, tervezz DLQ-t és idempotens fogyasztót; ezek nélkül a legelegánsabb architektúra is csendben veszít üzeneteket.