Kolejki zadań i bilansowanie

1) Dlaczego kolejki zadań

• Wygładza szczyty: bufor między przednim i ciężkim podsystemem.
• Stabilizuje SLA: priorytety i izolacja klas obciążeń.
• Upraszcza tolerancję błędów: przekładki, DLQ, ponowne ustawienie.
• Waga pozioma: Dodaj pracowników bez zmiany API.

Typowe domeny: przetwarzanie płatności, powiadomienia, generowanie raportów/mediów, odtworzenie ETL/ML, integracja z zewnętrznymi interfejsami API.

2) Model i podstawowe koncepcje

Producent: publikuje zadanie (ładunek użytkowy + metadane: klucz idempotencji, priorytet, termin).
Kolejka/temat: bufor/dziennik zadań.
Pracownik: bierze zadanie, procesy, potwierdza (ack) lub zwraca z błędem.
Visibility Timeout/Lease: „wynajem” zadań na czas przetwarzania, po - auto-redelivery.
DLQ (Dead Letter Queue): „zakopywanie” zadań po ograniczeniu prób/błędów śmiertelnych.
Limit/Równoczesność: na pracownika/na kolejkę/na najemcę limity zużycia.

• Pociągnij: sam pracownik prosi o zadanie (poda obciążenie).
• Push: Puszek maklerski; potrzebują ochrony przed „napełnianiem” słabych pracowników.

3) Semantyka dostawy i potwierdzenia

Najwyżej raz: brak przekaźników; szybciej, ale możliwe straty.
Co najmniej raz (domyślnie dla większości kolejek): możliwe są duplikaty → wymagana jest idempotencja obsługi.
Skutecznie dokładnie raz: osiągnięty na poziomie aplikacji (idempotencja, dedup, transakcje/outbox). Broker może pomóc, ale nie „magiczna kula”.

• Ack/Nack: wyraźny wynik.
• Requeue/Retry: • backoff + jitter.
• Trucizna - wyślij do DLQ.

4) Bilansowanie i planowanie

4. 1 Sekwencja i algorytmy

FIFO: Proste i przewidywalne.
Kolejka priorytetowa: klasy priorytetowe (P0... P3).
WRR/WSR (Weighted Round-Robin/Random): akcje procesora/przeszczep pomiędzy klasami.
WFQ/DRR (analogiczne do „uczciwych” kolejek w sieciach): akcje na najemcę/klienta.
Termin/EFR: dla zadań z terminami.
Sprawiedliwy udział: ograniczenie „hałaśliwych sąsiadów” (kwot na najemcę).

4. 2 Przepływy przetwórcze

Pojedynczy lot/Koalescing: Połączyć duplikat kluczowych zadań.
Czapki współistniejące: ścisłe limity paralelizmu według typu zadania/integracji (zewnętrzne interfejsy API).

4. 3 Geo i ostrzenie

Shards by key (lokator/id) → lokalizacja danych, stabilne kolejność w odłamkach.
Kleiste pamięci podręczne/zasoby: hash routing do pracowników z „załączonym” stanem.

5) Retrai, backoff i DLQ

Wykładniczy backoff + jitter: 'base 2 ^ attempt ± random'.
Maksymalne próby i całkowity termin (czas do śmierci) na zadanie.
Klasyfikacja błędów: „odzyskiwalny” (sieć/limit), „niepohamowany” (walidacja/zakaz prowadzenia działalności).
Kolejka parkowania/opóźnienia: zadania odroczone (na przykład powtórzyć po 15 minutach).
Polityka DLQ: należy wskazać, gdzie i w jakich warunkach dostaje się „trujący” komunikat; dostarczyć regenerator.

6) Idempotencja i deduplikacja

• widziane → skip/merge/result-cache.
• Klucze naturalne: Użyj 'order _ id/ payment_id' zamiast losowych UUID.
• Outbox - zapisz fakt zadania i jego status w jednej transakcji bazodanowej z transakcją biznesową.
• Dokładnie raz w kolorze niebieskim: 'UPSERT' przez klucz, wersioning, 'przynajmniej raz' w kolejce + idempotencja w bazie danych.

7) Klasy wielopoziomowe i SLA

Oddzielne kolejki/strumienie według klasy: „krytyczny”, „standardowy”, „luzem”.
Kwoty i priorytety na najemcę (złoto/srebro/brąz).
Izolacja: poświęcić pulę pracowników w ramach P0; tło - w osobnym klastrze/węzłach.
Kontrola wstęp: nie akceptować więcej niż można przetwarzać w terminach.

8) Pracownicy zajmujący się autoskalowaniem

Metryka do skalowania: głębokość kolejki, szybkość przyjazdu, czas przetwarzania, terminy SLA.
KEDA/Horizontal Pod Autoscaler: SQS/Królik/Kafka opóźnienia głębokości wyzwalaczy.
Czynniki ograniczające: zewnętrzne limity prędkości API, baza danych (nie niszczą tylnego końca).

9) Opcje i wzory technologii

9. 1 RabbitMQ/AMQP

Wymiana: bezpośredni/temat/fanout; Kolejki na język polski/ttl/DLQ (wymiana martwych listów).
Prefetch (QoS) reguluje „ile zadań jest na pracowniku”.

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.failed x-message-ttl=60000

9. 2 SQS (i analogi)

Wyświetlanie czasu, sekundy, zasady RedrاPolicy (DLQ).
Idempotencja - na aplikacji (tabela dedup).
Granice: masła 1-10 słupków; skupić się na idempotentnych siniakach.

9. 3 Kafka/NATS JetStream

Dla rurociągów wielkoskalowych: wysoka przepustowość, retencja/powtórka.
Kolejka zadań nad dziennikami: jedno zadanie = jeden komunikat; jeden pracownik na sterowanie kluczem poprzez/podział tematyczny.
Retrai: poszczególne tematy/przedmioty-przyrostki z backoff.

9. 4 kolejki Redis (Sidekiq/Resque/Bull/Selery-Redis)

Bardzo niskie opóźnienia; zegarek na stabilność (RDB/AOF), klawisze retry i klawisze blokady dla pojedynczego lotu.
Nadaje się do „lekkich” zadań, a nie do długotrwałej retencji.

9. 5 Ramy ramowe

Seler (Python), Sidekiq (Ruby), RQ/BullMQ (Węzeł), Huey/Resque - gotowe przekaźniki, harmonogramy, middleware, metryki.

10) Systemy routingu i bilansowania

Round-Robin: Równomiernie, ale nie uwzględnia „ciężkości” zadań.
RR ważone: rozkład według pojemności/puli pracowników.
Fair/Backpressure-aware: Pracownik odbiera nowe zadanie tylko wtedy, gdy jest gotowy.
Pasy priorytetowe: oddzielne kolejki na klasę; pracownicy czytać w kolejności [P0 →... → Pn] jeśli dostępne.
Hash-routing: 'hash (key)% shards' - do przetwarzania statycznego/buforowanego.

11) Terminy, terminy i SLA

Czas na zadanie: wewnętrzny „dzierżawa” pracy (w kodzie pracownika) ≤ Czas widoczności maklera.
Globalny termin: zadanie nie ma sensu po czasie T - NACK → DLQ.
Świadomość budżetowa: zmniejszyć pracę (brownout), gdy zbliża się termin (częściowe wyniki).

12) Obserwowalność i zarządzanie

12. 1 Metryka

'queue _ depth', 'arrival _ rate', 'service _ rate', 'lag' (Kafka), 'invisible _ messages' (SQS).
'success/failed/retired _ total', 'retry _ attempts', 'dlq _ in _ total', 'processing _ time _ ms {p50, p95, p99}'.
'idempotence _ hit _ rate', 'dedup _ drops _ total', 'trucizna _ total'.

12. 2 kłody/śledzenie

Korelacja: 'job _ id',' correlation _ id', klucz deduplicacji.
zaznaczyć jako zdarzenia 'retry/backoff/dlq'; linkowanie z początkowego żądania przęsła.

12. 3 Deski rozdzielcze/wpisy

Wyzwalacze: głębokość> X, p99> SLO, wzrost DLQ, utknęły zadania (wygasła widoczność> N), gorące klawisze.

13) Bezpieczeństwo i zgodność

Izolacja lokatora: poszczególne kolejki/przestrzenie kluczowe, ACL, kwoty.
Szyfrowanie w transporcie i/lub „w spoczynku”.
Minimalizacja PII w ładunku użytkowym; hash/ID zamiast surowego PII.
Sekrety: nie wkładaj żetonów do ciała zadaniowego, używaj skarbca/refs.

14) Anty-wzory

Retrai bez idempotencji → duplikat operacji/pieniędzy „dwa razy”.
Jedna wielka kolejka „za wszystko →” brak izolacji, nieprzewidywalne opóźnienia.
Niekończące się retrai bez DLQ → wieczne „trujące” zadania.
Widoczność Czas <czas przetwarzania → kaskadowe duplikaty.
Duży ładunek w kolejce → ciśnienie sieci/pamięci; lepiej jest przechowywać w magazynie obiektu i przesyłać link.
Model push bez oparcia → duszenie pracowników.
Mieszanie zadań krytycznych i masowych w jednej puli pracowników.

15) Lista kontrolna wdrażania

• Klasyfikacja zadań według SLA (P0/P1/P2) i objętości.
• Wybierz brokera/ramy z pożądaną semantyką i retencją.
• Klucze projektowe, priorytety i routing (hash/shards/priority lanes).
• Włącz retrasy backoff + jitter i politykę DLQ.
• Wdrożenie idempotencji (klucze, upsert, deadstore z TTL).
• Ustaw harmonogram dla każdego zadania, widoczność i ogólne terminy.
• Ograniczenie równoczesności i stawki przez integracje/najemców.
• Automatyczne skalowanie głębokości/opóźnienia za pomocą bezpieczników.
• Mierniki/śledzenie/wpisy; zakładki na „burzę” i przepełnienie DLQ.
• Testy na porażki: upadek pracownika, „trujący” komunikat, przeciążenie, długie zadania.

16) Konfiguracje próbki i kod

16. 1 Seler (Redis/Królik) - przepływ bazowy

python app = Celery("jobs", broker="amqp://...", backend="redis://...")
app.conf.task_acks_late = True        # ack после выполнения app.conf.broker_transport_options = {"visibility_timeout": 3600}
app.conf.task_default_retry_delay = 5 app.conf.task_time_limit = 300        # hard timeout

@app.task(bind=True, autoretry_for=(Exception,), retry_backoff=True, retry_jitter=True, max_retries=6)
def process_order(self, order_id):
if seen(order_id): return "ok"      # идемпотентность do_work(order_id)
mark_seen(order_id)
return "ok"

16. 2 RabbitMQ - DLQ/TTL

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.dlq x-message-ttl=600000   # 10 минут x-max-priority=10

16. 3 Kafka - Przekłady według poziomu

orders -> orders.retry.5s -> orders.retry.1m -> orders.dlq

(Przelew z opóźnieniem dostawy za pośrednictwem harmonogramu/cron-consumer.)

16. 4 NATS JetStream - konsument

bash nats consumer add JOBS WORKERS --filter "jobs.email" \
--deliver pull --ack explicit --max-deliver 6 \
--backoff "1s,5s,30s,2m,5m"

17) FAQ

P: Kiedy wybrać push versus pull?
Odp.: Pull daje naturalne obciążenie i „uczciwe” równoważenie; push jest łatwiejsze przy niskich prędkościach i gdy potrzebne jest minimalne TTFB, ale wymaga ograniczeń.

P: Jak uniknąć gorącego klucza?
Odp.: Shard przez klucz złożony ('order _ id% N'), bufor i proces wsadowy, wprowadź limity na klucz.

P: Czy możliwe jest „dokładnie raz”?
Odp.: Praktycznie - poprzez idempotencję i skrzynkę kontaktową. W pełni „matematyczne” dokładnie raz jest rzadko osiągalne i drogie przez cały czas.

P: Gdzie przechowywać duże załączniki do zadań?
A: W magazynie obiektów (S3/GCS), a w zadaniu - link/ID; zmniejsza ciśnienie na brokera i sieci.

P: Jak wybrać TTL/widoczność?
Odp.: Widoczność ≥ czas przetwarzania p99 × zapasy 2-3 ×. Zadania TTL - mniej terminów biznesowych.

18) Kwoty całkowite

Silny system kolejkowania to równowaga między semantyką, priorytetami i ograniczeniami dostaw. Projektowanie kluczy i routing, zapewnienie idempotencji, przekwalifikowanie z backoff i DLQ, przydzielenie zasobów do klas SLA i mierników monitoringu. Wtedy Twoje procesy tła będą przewidywalne, stabilne i skalowalne - bez niespodzianek pod szczytami.