Gwarancje zamówienia wiadomości

1) Czym jest „porządek” i dlaczego jest potrzebny

Kolejność wiadomości jest relacją „co powinno być przetwarzane przed” dla zdarzeń jednego podmiotu (zamówienia, użytkownika, portfela) lub dla całego strumienia. Ważne jest dla niezmienników: „status A przed B”, „saldo przed odpisem”, „wersja n przed n + 1”.
W systemach rozproszonych całkowite światowe zamówienie jest drogie i rzadko potrzebne; lokalne zamówienie na klucz jest zwykle wystarczające.

2) Rodzaje gwarancji zamówienia

1. Per-partition (lokalne zamówienie w sekcji dziennika) - Kafka: zamówienie wewnątrz strony jest zachowane, między stronami - nie.
2. Per-key (grupa klucza zamawiającego/wiadomości) - wszystkie wiadomości z jednym kluczem są przesyłane do jednego „wątku” przetwarzania (klucz Kafka, SQS FIFO, Pub/Sub order key).
3. Globalne całkowite zamówienie - cały system widzi jedno zamówienie (rozproszony dziennik/sekwencer). Drogie, degraduje dostępność i przepustowość.
4. Kolejność przyczynowa - „zdarzenie B po A, jeśli B obserwuje efekt A.” Osiągalne przez metadane (wersje, Lamport-times/zegary wektorowe) bez globalnego sekwencera.
5. Najlepszy nakład - broker stara się utrzymać porządek, ale w przypadku awarii permutacje są możliwe (często w NATS Core, RabbitMQ z kilkoma konsumentami).

3) W przypadku rozpadu zamówienia

Równolegli konsumenci tej samej kolejki (RabbitMQ: kilka konsumentów na kolejkę → interleaving).
Przekaźniki/ponowne dostawy (co najmniej raz), timeouts „ack”, ponowne kolejkowanie.
Rebalance/feilover (Kafka: party/leader move).
DLQ/regeneracja - „trujący” komunikat idzie do DLQ, następne idą dalej → logiczna przerwa.
Multi-region i replikacja - różne opóźnienia → misalignment.

4) Projekt zamówienia kluczowego

• Użyj klawiszy naturalnych: 'order _ id',' wallet _ id', 'aggregate _ id'.
• Zegarek na „gorące klucze” - jeden klucz może „zablokować” przepływ (blokowanie head-of-line). W razie potrzeby podziel klucz: 'order _ id # shard (0.. k-1) "z deterministyczną przebudową zamówienia na zlewie.
• W Kafce - jeden klucz → jedna część, zamówienie zostanie zachowane w ramach klucza.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(Klucz = 'Id' gwarantuje lokalne zamówienie.)

5) „Zamówienie vs. Przepustowość”

• Jeden konsument na kolejkę utrzymuje zamówienie, ale zmniejsza współistnienie.
• Co najmniej raz + jednoczesność poprawia wydajność, ale wymaga idempotencji i/lub ponownego zamawiania.
• Globalne zamówienie dodaje hop do sekwencera → "" latentnost "i ryzyko awarii.

Kompromis: porządek na klucz, paralelizm = liczba partii/grup, + idempotentne siniaki.

6) Kontrola porządku u konkretnych pośredników

Kafka

Porządek wewnątrz strony.
Obserwuj 'max. w. lot. wniosków. per. przyłączenie ≤ 5 '„” włącza. idempotence = true ', aby przekładki producenta nie zmieniały kolejności.
Grupa konsumentów: jedna strona → jeden pracownik na raz. Powtarzające się dostawy są możliwe → zachować sekwencję/wersję w warstwie biznesowej.
Transakcje typu read-process-write utrzymują spójność odczytu/zapisu/crumb offset, ale nie tworzą globalnego zamówienia.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

Zamówienie jest gwarantowane w jednej kolejce dla jednego użytkownika. Z kilku konsumentów wiadomości mogą być „mieszane”.
Dla zamówienia: jeden consummer lub prefetch = 1 + ack po zakończeniu. Dla równoległości, oddzielne kolejki według klawiszy (giełdy shading/konsekwentne-hash exchange).

NATS/JetStream

NATS Core - najlepszy wysiłek, niskie opóźnienia, zamówienia mogą być zakłócone.
JetStream: zamawianie w ciągu strumienia/sekwencji; podczas redeliveries, rearanżacje na konsoli są możliwe → użyj sekwencji i bufora odzysku.

SQS FIFO

Dokładnie raz przetwarzanie (skutecznie, z powodu deduplikacji) i zamówienie w ramach Grupy Id. Współzależność - liczba grup w grupie kierowniczej.

Google Pub/Sub

Klucz zamawiania daje zamówienie w ramach klucza; w przypadku błędów publikacja jest blokowana do czasu przywrócenia - uważaj na backpressure.

7) Wzory zachowania i przywrócenia porządku

7. 1 Sekwencja/wersioning

• przyjmuje zdarzenie tylko wtedy, gdy 'seq = last_seq + 1';
• w przeciwnym razie umieszcza się w buforze oczekującym przed przybyciem brakującego („last _ seq + 1”).

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 Bufory i okna (przetwarzanie strumieniowe)

Czas-okno + znak wodny: akceptujemy poza zamówieniem w oknie, zgodnie ze znakiem wodnym „zamykamy” okno i organizujemy go.
Dozwolone opóźnienie: kanał dla późnych przyjazdów (recompute/ignore).

7. 3 Sticky-routing przez klucz

Hash (key)% shards hash routing wysyła wszystkie kluczowe zdarzenia do jednego pracownika.
W Kubernetes - zachowaj sesję (lepką) na poziomie kolejki/sherds, a nie na balancerze L4 HTTP.

7. 4 Model aktora/” jeden strumień na klucz„

Dla agregatów krytycznych (portfel): aktor przetwarza kolejno, reszta paralelizmu - liczba aktorów.

7. 5 Idempotence + ponowne zamawianie

Nawet przy przywróceniu porządku, powtórzenia są możliwe. Połączenie UPSERT przez wersję klucza + i skrzynki odbiorczej (patrz Dokładnie raz vs Co najmniej raz).

8) Praca z „jadowitymi” wiadomościami (pigułki trujące)

Utrzymanie porządku stoi w obliczu zadania: „jak żyć, jeśli jedna wiadomość nie jest przetwarzana?”

Ścisłe zamówienie: blokowanie przepływu klucza (SQS FIFO: cała grupa). Rozwiązaniem jest DLQ by-key: przenosimy tylko klucz/grupę problemu do oddzielnej kolejki/ręcznego parsowania.
Elastyczne zamówienie: pozwalamy na pominięcie/odszkodowanie; logujemy i kontynuujemy (nie dla agregatów finansowych/krytycznych).
Polityka Retray: ograniczony 'max-deliver' + backoff + avidempotent effects.

9) Systemy wielobranżowe i globalne

Klaster-linking/replikacja (Kafka) nie gwarantuje międzyregionalnego globalnego porządku. Daj pierwszeństwo lokalnemu porządkowi na klucz i idempotentnym siniakom.
Dla prawdziwie globalnego zamówienia należy użyć sekwencera (dziennik centralny), ale ma to wpływ na dostępność (WPR: minus A dla przerw sieciowych).
Alternatywa: kolejność przyczynowa + CRDT dla niektórych domen (liczniki, zestawy) - nie jest potrzebne ścisłe zamówienie.

10) W przedmiocie widoczności porządku

Метрика: 'out _ of _ order _ total', 'reordered _ in _ window _ total', 'late _ events _ total', 'buffer _ size _ current', 'blocked _ keys _ total', 'fifo _ group _ backlog'.

11) Anty-wzory

Jedna kolejka + wielu konsumentów bez rzucania kluczem - zamówienie natychmiast się rozpada.
Retrai przez publiczność w tej samej kolejce bez idempotencji - podwaja + out-of-order.
Globalny porządek „na wszelki wypadek” jest eksplozją opóźnień i wartości bez realnych korzyści.
SQS FIFO jedna grupa dla wszystkich - full head-of-line. Użyj klucza.
Ignorowanie „gorących klawiszy” - jeden „portfel” spowalnia wszystko; podzielić klucz na subklucze w miarę możliwości.
Mieszanie strumieni krytycznych i masowych w tej samej kolejce/grupie - wzajemny wpływ i utrata porządku.

12) Lista kontrolna wdrażania

• Per-key/per-partition/causal/global?
• Zaprojektowana strategia sekwencjonowania kluczy i strategii przeciw gorącym kluczem.
• Router skonfigurowany: partycjonowanie/ GroupId/klucz zamawiania.
• Konsole są izolowane przez klucze (lepkie-routing, shard-workers).
• Uwzględniono idempotencję i/lub skrzynkę odbiorczą/UPSERT na siniakach.
• Wdrożona sekwencja/wersja i bufor ponownego zamawiania (w razie potrzeby).
• DLQ według kluczowych przekładów polityki i backoff.
• Pozagiełdowe, blocked_keys, late_events i mierniki alarmowe.
• Dzień gry: przywrócenie równowagi, utrata węzła, trująca wiadomość, opóźnienia w sieci.
• Dokumentacja: niezmienne zamówienia, granice okien, wpływ na SLA.

13) Przykłady konfiguracji

13. 1 Kafka konsument (minimalizacja łamania zamówień)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (zamówienie według ceny równoczesności)

Jeden konsument na kolejkę + "podstawowe. qos (prefetch = 1) "

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

Ustaw klucz. Równoczesność = liczba grup.
Na potrzeby ochrony przed duplikatami (w oknie dostawcy).

13. 4 NATS JetStream (zamówiony konsument, szkic)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

klucz> Monitoruj 'equence' i ponowne zamawianie bufora w aplikacji.

14) FAQ

P: Czy potrzebuję globalnego porządku?
Odp.: Prawie nigdy. Prawie zawsze wystarczy na klucz. Globalny porządek jest drogi i uderza w przystępność cenową.

P: A co z „jadowitym” przesłaniem pod ścisłym porządkiem?
Odp.: Przenieś tylko klucz/grupę do DLQ, reszta - kontynuuj.

P: Czy można uzyskać zamówienie i skalę w tym samym czasie?
Odp.: Tak, zamówienie kluczy + wiele klawiszy/części + operacje idempotent i ponowne zamawianie buforów w razie potrzeby.

P: Co jest ważniejsze: zamówienie czy dokładnie raz?
Odp.: Dla większości domen - kolejność kluczy + skutecznie dokładnie raz efekty (idempotencja/UPSERT). Transport może być przynajmniej raz.

15) Kwoty całkowite

Zamówienie jest lokalną gwarancją wokół klucza biznesowego, a nie kosztowną dyscypliną globalną. Projektowanie kluczy i imprez, ograniczenie gorących klawiszy, użyj idempotencji i, w razie potrzeby, kolejność + ponowne zamawianie bufora. Uważaj na niedostępne i zablokowane wskaźniki kluczy, awarie testów - a otrzymasz przewidywalne przetwarzanie bez poświęcania wydajności lub dostępności.