Blog - MQTT QoS i backpressure — kiedy QoS 2 szkodzi

W integracjach Modbus → MQTT często pojawia się intuicja: „ustawmy QoS 2, będzie najbezpieczniej”. W praktyce przy burstach telemetrii QoS 2 potrafi zwiększyć opóźnienie i zgubić świeże dane.

Model kolejki

Załóżmy, że broker lub edge gateway ma skończoną kolejkę o pojemności $N$. Przy napływie $\lambda$ wiadomości/s i obsłudze $\mu$ wiadomości/s wykorzystanie wynosi:

$$\rho = \frac{\lambda}{\mu}$$

Gdy $\rho \to 1$, średnia liczba wiadomości w kolejce (M/M/1) rośnie jak:

$$L = \frac{\rho}{1 - \rho}$$

QoS 2 dodaje handshake (PUBREC / PUBREL / PUBCOMP), więc efektywne $\mu$ spada — $\rho$ rośnie szybciej niż przy QoS 0/1.

Przepływ decyzji

Praktyczna reguła

1. Telemetria wysokiej częstotliwości — QoS 0 + coalescing (ostatnia wartość wygrywa).
2. Alarmy / komendy — QoS 1 (co najmniej raz) z idempotentnym konsumentem.
3. QoS 2 — tylko gdy dokładnie-raz jest wymaganiem biznesowym i wolumen jest niski.

Wzór na budżet opóźnienia

Jeśli akceptujesz maksymalne opóźnienie $T$ sekund przy burstach, to przy średnim rozmiarze wiadomości $s$ bajtów i paśmie $B$ B/s:

$$N_{\max} \approx \frac{B \cdot T}{s}$$

Przekroczenie $N_{\max}$ bez strategii drop/coalesce oznacza, że „niezawodny” QoS 2 i tak dostarczy przestarzałe próbki.

Wniosek

Niezawodność w IoT to nie maksymalny QoS, tylko świadomy kontrakt: które dane muszą dotrzeć zawsze, a które wystarczy „najnowsze wygrywa”.