Backpressure: ha a fogyasztó lassabb a termelőnél
Célok
A lecke végére el tudod magyarázni a backpressure fogalmát, meg tudod mondani, mi történik, ha az érkezési ütem tartósan meghaladja a feldolgozásit, és fel tudod sorolni a védekezés eszközeit.
Miért kell?
Egy sor pufferel, de nem növeli végtelenül a kapacitást. Az Azure leírása szerint ha az átlagos termelői ütem meghaladja a fogyasztóit, a sor tovább nő, és a késleltetés is. Ha a rendszer korlátlanul átvesz több munkát, mint amennyit elvégez, a terhelést csak memóriába vagy tartós sorba tolja át.
Mi a backpressure?
Backpressure: a lassabb fogyasztó vagy feldolgozó visszahat a termelésre, a kézbesítésre vagy az elfogadásra, és így nem engedi, hogy a rendszer korlátlanul halmozzon fel munkát.
Legyen λ az érkezési ütem, μ a teljes feldolgozási ütem. Ha tartósan λ > μ, a várakozó munka nő; rövid ideig a puffer hasznos, a fenntartható működéshez azonban a kapacitásnak és a terhelési mintának illeszkednie kell. Több fogyasztó sem gyorsít, ha mind ugyanazon korlátozott külső szolgáltatásra vár. Az Azure figyelmeztet: az automatikus skálázás a fogyasztók összesített lefelé irányuló ütemének korlátozása nélkül csak a túlterhelést tolja a lefelé levő függőségekre.
flowchart LR
P["Termelő (λ)"] --> Q[("Sor / puffer")]
Q --> C["Fogyasztó (μ)"]
C -.->|"lassú: visszahatás"| P
Eszközök
- Fogyasztói korlát: a RabbitMQ prefetch értéke megadja, hány nem nyugtázott üzenetet kaphat egy csatorna egyszerre. Ez védi a memóriát, és segíti az egyenletes elosztást; túl nagy érték mellett egy fogyasztó sok munkát foglal le, miközben mások tétlenek. A dokumentáció a 100–300 közötti értéket említi gyakori jó kiindulásnak, az 1-et a legóvatosabbnak; ezt konkrét környezetben mérni kell.
- Korlát a belépési ponton: a rendszer megtagadhat vagy késleltethet új munkát, ha nincs vállalható kapacitás. Világos válasz kell: elfogadtuk és sorba állítottuk, később próbálja újra, vagy a művelet nem indítható. A tartósan elfogadott munka állapotát és lejáratát meg kell mutatni.
- Összevonás vagy eldobás: aktuális értéknél (például a legfrissebb mért érték) összevonható több frissítés; pénzügyi tranzakciónál nem dobható el köztes rekord. A „régi üzenet eldobása” szabály csak az üzenet jelentéséből következhet.
- Párhuzamosság korlátja: ha egy entitás eseményeit sorban kell alkalmazni, ugyanahhoz a kulcshoz nem indítanak korlátlan párhuzamos feldolgozást; a többi kulcs ettől még haladhat.
- Mérés: a sorhossz mellett a legrégebbi üzenet kora, a feldolgozási idő, az ismétlési arány és a végleges hiba is fontos.
Szinkron vagy aszinkron?
Azonnali döntéshez, például jogosultsági ellenőrzéshez vagy foglalási eredményhez gyakran közvetlen válasz kell. Hosszú feldolgozáshoz és több önálló reakcióhoz az aszinkron modell előnyös. Az aszinkron működés ára a függő állapot, a késői eredmény, az ismétlés és a több helyen követett folyamat, és a kliensnek is tudnia kell, hogy a munka még készül (6.2).
Jellemzők
| Szempont |
Aszinkron sor, backpressure-rel |
| Irány |
Termelő → fogyasztó; a lassúság visszahat |
| Kezdeményező |
A termelő küld; a fogyasztó a saját ütemében vesz ki |
| Késleltetés |
A sor hosszával nő |
| Terhelés |
Puffer; a lefelé levő függőség védett |
| Hibatűrés |
Átmeneti csúcsot elnyel; tartós túlterhelést nem |
| Mikor jó? |
Változó terhelés, lassú függőség védelme |
| Mikor nem? |
Ha azonnali válasz kell, vagy tartósan λ > μ |
Gyakori tévhitek
| Állítás |
Pontosítás |
| „A sor megoldja a túlterhelést.” |
Csak elnyeli a csúcsot; tartós λ > μ esetén nő. |
| „Több worker mindig gyorsabb.” |
Ha ugyanazon korlátos függőségre várnak, nem. |
| „Elég a sorhosszt figyelni.” |
A legrégebbi üzenet kora és az eredmény is kell. |
Röviden
- A backpressure a lassú fogyasztó visszahatása a termelésre.
- Tartós λ > μ esetén a sor nő; kapacitást vagy bemenet-korlátot kell tervezni.
- Eszközök: prefetch, belépési korlát, összevonás, kulcsonkénti párhuzamosság, mérés.
- Az aszinkron működésnek függő állapota van, ezt a felhasználó felé is jelezni kell.
Ellenőrző kérdések
- Mi történik, ha λ tartósan nagyobb μ-nél?
- Miért nem segít több worker, ha mind egy külső API-ra vár?
- Mikor szabad összevonni vagy eldobni üzeneteket?
Források
Backpressure: ha a fogyasztó lassabb a termelőnél
Célok
A lecke végére el tudod magyarázni a backpressure fogalmát, meg tudod mondani, mi történik, ha az érkezési ütem tartósan meghaladja a feldolgozásit, és fel tudod sorolni a védekezés eszközeit.
Miért kell?
Egy sor pufferel, de nem növeli végtelenül a kapacitást. Az Azure leírása szerint ha az átlagos termelői ütem meghaladja a fogyasztóit, a sor tovább nő, és a késleltetés is. Ha a rendszer korlátlanul átvesz több munkát, mint amennyit elvégez, a terhelést csak memóriába vagy tartós sorba tolja át.
Mi a backpressure?
Backpressure: a lassabb fogyasztó vagy feldolgozó visszahat a termelésre, a kézbesítésre vagy az elfogadásra, és így nem engedi, hogy a rendszer korlátlanul halmozzon fel munkát.
Legyen λ az érkezési ütem, μ a teljes feldolgozási ütem. Ha tartósan λ > μ, a várakozó munka nő; rövid ideig a puffer hasznos, a fenntartható működéshez azonban a kapacitásnak és a terhelési mintának illeszkednie kell. Több fogyasztó sem gyorsít, ha mind ugyanazon korlátozott külső szolgáltatásra vár. Az Azure figyelmeztet: az automatikus skálázás a fogyasztók összesített lefelé irányuló ütemének korlátozása nélkül csak a túlterhelést tolja a lefelé levő függőségekre.
flowchart LR P["Termelő (λ)"] --> Q[("Sor / puffer")] Q --> C["Fogyasztó (μ)"] C -.->|"lassú: visszahatás"| PEszközök
Szinkron vagy aszinkron?
Azonnali döntéshez, például jogosultsági ellenőrzéshez vagy foglalási eredményhez gyakran közvetlen válasz kell. Hosszú feldolgozáshoz és több önálló reakcióhoz az aszinkron modell előnyös. Az aszinkron működés ára a függő állapot, a késői eredmény, az ismétlés és a több helyen követett folyamat, és a kliensnek is tudnia kell, hogy a munka még készül (6.2).
Jellemzők
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források