A lecke végére el tudod magyarázni, mit biztosít és mit nem egy partíciókulcs, hogyan kezeld a késői és sorrenden kívüli üzeneteket, és mikor biztonságos a dead-letter üzenetek visszajátszása.
Miért kell?
Az aszinkron üzenetek késhetnek, ismétlődhetnek, és párhuzamos fogyasztás miatt eltérő sorrendben dolgozódhatnak fel. A termelő kibocsátási sorrendje, a közvetítő tárolási sorrendje és az üzleti hatások sorrendje három külön fogalom.
Sorrend és partíció
Az Azure versengő fogyasztók mintája szerint a fogyasztók által kapott üzenetek sorrendje nem garantált, és nem feltétlenül tükrözi a keletkezés sorrendjét; ezért az ajánlás az idempotens feldolgozás, amely megszünteti a sorrendfüggést. A Kafka bemutatója szerint viszont az azonos kulcsú események ugyanabba a partícióba kerülnek, és a fogyasztó egy partíció eseményeit pontosan a megírás sorrendjében olvassa. Egyes szolgáltatások (például az Azure Service Bus üzenetmunkamenetei) szigorú FIFO-sorrendet adhatnak.
Ebből következik: egy entitás (például egy rendelés) eseményeinek sorrendje partíciókulccsal követhetővé tehető, de külön partíciók között általában nem feltételezhető közös teljes sorrend. A kulcsválasztás a terhelést is befolyásolja: ha minden üzenet ugyanazt a kulcsot kapja, egy partíció szűk keresztmetszet lesz; ha véletlen kulcsot kap, az ugyanazon entitáshoz tartozó sorrend elveszhet.
Verzió és késői esemény
Egy entitás eseménye hordozhat növekvő verziószámot. Ha a read model már a 12-es verziót alkalmazta, a később érkező 11-est nem kezelheti friss állapotként. Deltaeseménynél (a változás leírásánál) a hiányzó előzmény jelentős: a köztes művelet nem hagyható el úgy, mint egy teljes pillanatkép esetén. Az időbélyeg nem biztosít megbízható globális sorrendet, mert az órák eltérhetnek és az üzenetek külön utakon járnak. Ha sorrendre van szükség, az azonosító, a verzió és a forrás szerződése legyen az elsődleges támpont.
Ismétlés az ok alapján
Átmeneti adatbázis-elérési hiba később megszűnhet; érvénytelen séma vagy hiányzó kötelező mező ugyanazon tartalom ismétlésétől nem javul. A fogyasztó különítse el az átmeneti, a tartós és az üzleti elutasítást. Késleltetett ismétlés és backoff (6.5) védi a kiesett függőséget, de legyen próbálkozási vagy időbeli korlát. Egy sikertelen üzenet ne akadályozza korlátlanul a többi feldolgozását, ha az üzleti sorrend ezt nem indokolja.
Dead-letter queue
A dead-letter queue (DLQ, „halott levelek sora”) a sikertelen vagy nem kezelhető üzenetek elkülönítésére szolgál. Az Azure leírása szerint egy mérgező üzenet (hibás formátum, elérhetetlen erőforrás) ne kerüljön újra és újra vissza a sorba, hanem a részletei kerüljenek máshová elemzésre; a Service Bus például a kézbesítési próbák számának túllépése után automatikusan a dead-letter sorba teszi az üzenetet.
Nem megoldás önmagában: kell ok, eredeti azonosító, próbálkozási információ és visszajátszási rend; a DLQ mélységét figyelni kell, hogy a hibát ki lehessen vizsgálni és az üzenetet megfelelő esetben újra be lehessen küldeni. A visszajátszás megismételheti a korábbi hatásokat, ezért idempotencia kell. Egy üzletileg fontos üzenet „DLQ-ba került” állapota felhasználói vagy működési következmény, nem sikeres befejezés.
Sorrend, ismétlés és dead-letter feldolgozás
Célok
A lecke végére el tudod magyarázni, mit biztosít és mit nem egy partíciókulcs, hogyan kezeld a késői és sorrenden kívüli üzeneteket, és mikor biztonságos a dead-letter üzenetek visszajátszása.
Miért kell?
Az aszinkron üzenetek késhetnek, ismétlődhetnek, és párhuzamos fogyasztás miatt eltérő sorrendben dolgozódhatnak fel. A termelő kibocsátási sorrendje, a közvetítő tárolási sorrendje és az üzleti hatások sorrendje három külön fogalom.
Sorrend és partíció
Az Azure versengő fogyasztók mintája szerint a fogyasztók által kapott üzenetek sorrendje nem garantált, és nem feltétlenül tükrözi a keletkezés sorrendjét; ezért az ajánlás az idempotens feldolgozás, amely megszünteti a sorrendfüggést. A Kafka bemutatója szerint viszont az azonos kulcsú események ugyanabba a partícióba kerülnek, és a fogyasztó egy partíció eseményeit pontosan a megírás sorrendjében olvassa. Egyes szolgáltatások (például az Azure Service Bus üzenetmunkamenetei) szigorú FIFO-sorrendet adhatnak.
Ebből következik: egy entitás (például egy rendelés) eseményeinek sorrendje partíciókulccsal követhetővé tehető, de külön partíciók között általában nem feltételezhető közös teljes sorrend. A kulcsválasztás a terhelést is befolyásolja: ha minden üzenet ugyanazt a kulcsot kapja, egy partíció szűk keresztmetszet lesz; ha véletlen kulcsot kap, az ugyanazon entitáshoz tartozó sorrend elveszhet.
Verzió és késői esemény
Egy entitás eseménye hordozhat növekvő verziószámot. Ha a read model már a 12-es verziót alkalmazta, a később érkező 11-est nem kezelheti friss állapotként. Deltaeseménynél (a változás leírásánál) a hiányzó előzmény jelentős: a köztes művelet nem hagyható el úgy, mint egy teljes pillanatkép esetén. Az időbélyeg nem biztosít megbízható globális sorrendet, mert az órák eltérhetnek és az üzenetek külön utakon járnak. Ha sorrendre van szükség, az azonosító, a verzió és a forrás szerződése legyen az elsődleges támpont.
Ismétlés az ok alapján
Átmeneti adatbázis-elérési hiba később megszűnhet; érvénytelen séma vagy hiányzó kötelező mező ugyanazon tartalom ismétlésétől nem javul. A fogyasztó különítse el az átmeneti, a tartós és az üzleti elutasítást. Késleltetett ismétlés és backoff (6.5) védi a kiesett függőséget, de legyen próbálkozási vagy időbeli korlát. Egy sikertelen üzenet ne akadályozza korlátlanul a többi feldolgozását, ha az üzleti sorrend ezt nem indokolja.
Dead-letter queue
A dead-letter queue (DLQ, „halott levelek sora”) a sikertelen vagy nem kezelhető üzenetek elkülönítésére szolgál. Az Azure leírása szerint egy mérgező üzenet (hibás formátum, elérhetetlen erőforrás) ne kerüljön újra és újra vissza a sorba, hanem a részletei kerüljenek máshová elemzésre; a Service Bus például a kézbesítési próbák számának túllépése után automatikusan a dead-letter sorba teszi az üzenetet.
Nem megoldás önmagában: kell ok, eredeti azonosító, próbálkozási információ és visszajátszási rend; a DLQ mélységét figyelni kell, hogy a hibát ki lehessen vizsgálni és az üzenetet megfelelő esetben újra be lehessen küldeni. A visszajátszás megismételheti a korábbi hatásokat, ezért idempotencia kell. Egy üzletileg fontos üzenet „DLQ-ba került” állapota felhasználói vagy működési következmény, nem sikeres befejezés.
Jellemzők
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források