Dokładnie raz vs Co najmniej raz

1) Po co nawet omawiać semantykę

• Najwyżej - bez powtarzania, ale utrata jest możliwa (rzadko akceptowalna).
• Przynajmniej raz - nie przegrywaj, ale możliwe są duplikaty (domyślnie większość brokerów/kolejek).
• Dokładnie raz - każda wiadomość jest przetwarzana dokładnie raz pod względem obserwowanego efektu.

Kluczowa prawda: w rozproszonym świecie bez globalnych transakcji i synchronicznej spójności, „czyste” zakończenie dokładnie raz jest nieosiągalne. Budujemy skutecznie dokładnie raz: pozwalamy na powtórzenia na transporcie, ale robimy przetwarzanie idempotent tak, że obserwowany efekt jest „jakby raz”.

2) Schemat awarii i gdzie występują duplikaty

• Straty ack/commit (producent/broker/consummer „nie usłyszał” potwierdzenia).
• Reelekcja liderów/replik, odzyskiwanie po przerwach w sieci.
• Timeouts/retreats in any area (kliyent → broker → konsyumer → sink).

Konsekwencja: nie można polegać na „wyjątkowości dostawy” transportu. Zarządzanie efektami: pisanie do bazy danych, debetowanie pieniędzy, wysyłanie listu itp.

3) Dokładnie raz u dostawców i co to jest naprawdę

3. 1 Kafka

• Idempotent Producer ('enable. idempotence = true ') - zapobiega powielaniu po stronie producenta podczas cofania.
• Transakcje - atomowe publikowanie wiadomości w kilku partiach i dokonywanie kompensacji zużycia (wzorzec read-process-write bez „luk”).
• Zagęszczenie - zapisuje ostatnią wartość według klucza.

Ale „koniec łańcucha” (zlew: DB/płatność/poczta) nadal wymaga idempotencji. W przeciwnym razie podwójna obsługa spowoduje podwójny efekt.

3. 2 NATS/Królik/SQS

Domyślnie jest co najmniej raz z ack/redelivery. Dokładnie raz jest osiągany na poziomie aplikacji: klucze, terminal, upsert.

Wniosek: Dokładnie raz transport „dokładnie raz” efekt. Ten ostatni odbywa się w opiekuna.

4) Jak skutecznie zbudować dokładnie raz na co najmniej raz

4. 1 Klucz idempotencji

• Czeki „już widziane?” - Dedup-stor (Redis/DB) z TTL/Retsch.
• Jeśli widziałeś, powtarza wcześniej obliczony wynik lub nie-op.

lua
-- SET key if not exists; expires in 24h local ok = redis.call("SET", KEYS[1], ARGV[1], "NX", "EX", 86400)
if ok then return "PROCESS" else return "SKIP" end

4. 2 Upsert w podstawie (idempotent cink)

Wpisy są dokonywane przez UPSERT/ON CONFLICT z sprawdzaniem wersji/kwoty.

sql
INSERT INTO payments(id, status, amount, updated_at)
VALUES ($1, $2, $3, now())
ON CONFLICT (id) DO UPDATE
SET status = EXCLUDED.status,
updated_at = now()
WHERE payments.status <> EXCLUDED.status;

4. 3 Skrzynka kontaktowa/skrzynka odbiorcza

Outbox: transakcja biznesowa i wpis zdarzenia do publikacji występują w tej samej transakcji bazodanowej. Tło wydawca czyta outbox i wysyła do brokera → nie ma rozbieżności między stanem a wydarzeniem.
Skrzynka odbiorcza: dla poleceń przychodzących zapisz 'message _ id' i wynik przed wykonaniem; ponowne przetwarzanie widzi rekord i nie powtarza skutków ubocznych.

4. 4 Spójne przetwarzanie łańcucha (czytaj → proces → napisz)

Kafka: transakcja „czytaj offset → zapisać wyniki → commit” w jednym bloku atomowym.
Bez transakcji: „najpierw zapisz wynik/skrzynkę odbiorczą, a następnie ack”; z awarią, duplikat zobaczy skrzynkę odbiorczą i zakończy się bez opcji.

4. 5 SAGA/kompensaty

Kiedy idempotencja jest niemożliwa (zewnętrzny dostawca odpisał pieniądze), stosujemy operacje kompensacyjne (zwrot/nieważność) i idempotentne zewnętrzne interfejsy API (powtarzane 'POST' z tym samym 'Idempotency-Key' daje ten sam wynik).

5) Gdy przynajmniej raz wystarczy

Aktualizacje buforów/zmaterializowanych widoków z zagęszczeniem opartym na kluczach.
Liczniki/mierniki, w których możliwe jest ponowne przyrost (lub przechowywanie delt z wersją).
Powiadomienia, w których druga litera nie jest krytyczna (lepiej umieścić klucz w każdym razie).

Zasada: jeśli podwójny nie zmieni znaczenia biznesowego lub łatwo znajdziemy → przynajmniej raz + częściową ochronę.

6) Wydajność i koszt

Dokładnie raz (nawet „skutecznie”) kosztuje więcej: dodatkowe rekordy (Inbox/Outbox), klucze do przechowywania, transakcje, diagnostyka są trudniejsze.
Przynajmniej raz jest tańszy/prostszy, lepszy w przepustowości/p99.
Oceń: cena podwójnego x prawdopodobieństwo podwójnego vs koszt ochrony.

7) Konfiguracje próbki i kod

7. 1 producent Kafka (idempotencja + transakcje)

properties enable.idempotence=true acks=all retries=INT_MAX max.in.flight.requests.per.connection=5 transactional.id=orders-writer-1

java producer.initTransactions();
producer.beginTransaction();
producer.send(recordA);
producer.send(recordB);
// также можно atomically commit consumer offsets producer.commitTransaction();

7. 2 Konsola skrzyni odbiorczej (kod pseudo)

pseudo if (inbox.exists(msg.id)) return inbox.result(msg.id)
begin tx if!inbox.insert(msg.id) then return inbox.result(msg.id)
result = handle(msg)
sink.upsert(result)     # идемпотентный синк inbox.set_result(msg.id, result)
commit ack(msg)

7. 3 HTTP Idempotency-Key (zewnętrzne interfejsy API)

POST /payments
Idempotency-Key: 7f1c-42-...
Body: { "payment_id": "p-123", "amount": 10.00 }

Powtarzany POST z tym samym kluczem → ten sam wynik/stan.

8) Obserwowalność i metryki

'duplikat _ attempts _ total' - ile razy złapano podwójne (zgodnie z Inbox/Redis).
'idempotence _ hit _ rate' - odsetek powtórzeń „zapisanych” przez idempotencję.
„txn _ abort _ rate” (Kafka/DB) - udział zwrotów.
'outbox _ backlog' - publikacja lag.
'exactly _ once _ path _ latency {p95, p99}' vs' at _ least _ once _ path _ latency '- overhead.
Dzienniki audytu: kilka 'message _ id',' idempotence _ key ',' saga _ id', 'try'.

9) Test playbooks (Dni gry)

Wyślij powtórkę: producent przekłada się na sztuczne timeouts.
Awaria między „zlewozmywakiem a ackiem”: Upewnij się, że skrzynka odbiorcza/Upsert zapobiega podwójnemu.
Ponowna dostawa: zwiększenie redelivery w brokerze; sprawdź dedup.
Idempotencja zewnętrznych API: powtarzający się POST z tym samym kluczem jest tą samą odpowiedzią.
Zmiana ołowiu/Przerwa w sieci: Sprawdź transakcje Kafka/Zachowanie konsumentów.

10) Anty-wzory

Polegaj na transporcie: „Mamy Kafkę z dokładnie raz, więc można bez kluczy” - nie.
No-op ack przed nagraniem: ackled ale zlew spadł → strata.
Brak odwrotu DLQ/jitter: niekończące się powtórki i burza.
Losowe UUID zamiast kluczy naturalnych: nic do dedublikacji.
Mieszanie skrzynki odbiorczej/skrzynki ekspresowej z bezindeksowymi tabelami produkcyjnymi: gorącymi zamkami i ogonami p99.
Transakcje biznesowe bez idempotentnego API u zewnętrznych dostawców.

11) Lista kontrolna wyboru

1. Podwójna cena (pieniądze/prawne/UX) vs cena ochrony (opóźnienie/złożoność/koszt).
2. Czy istnieje naturalny klucz do zdarzenia/operacji? Jeśli nie, wymyśl stajnię.
3. Zlewozmywak obsługuje Upsert/versioning? W przeciwnym razie - odszkodowanie w skrzynce odbiorczej +.
4. Czy potrzebujesz globalnych transakcji? Jeśli nie, segment do SAGA.
5. Potrzebujesz powtórki/długiej retencji? Kafka + Outbox. Potrzebujesz szybkiego RPC/niskiego opóźnienia? NATS + Idempotency-Key.
6. Wielozadaniowość i kwoty: izolacja klucza/przestrzeni.
7. Obserwowalność: uwzględniono mierniki idempotencji i zaległości.

12) FAQ

P: Czy możliwe jest osiągnięcie „matematyki” dokładnie raz na koniec?
Odp.: Tylko w wąskich scenariuszach z jednym spójnym sklepem i transakcjami. W ogólnym przypadku nie; skutecznie używać dokładnie raz przez idempotencję.

P: Który jest szybszy?
Odp.: Przynajmniej raz. Dokładnie raz dodaje transakcje/przechowywanie kluczy → powyżej p99 i koszt.

P: Gdzie przechowywać klucze idempotencji?
Odp.: Szybki przystanek (Redis) z TTL lub tabelą skrzynki odbiorczej (PK = message _ id). W przypadku płatności - dłużej (dni/tygodnie).

P: Jak wybrać klawisze dedup TTL?
Odp.: Minimum = maksymalny czas ponownego dostarczenia + margines operacyjny (zazwyczaj 24-72 godziny). Dla finansów - więcej.

P: Czy potrzebuję klucza, jeśli mam zagęszczenie przez klucz w Kafce?
Odp.: Tak. Zagęszczenie zmniejszy przechowywanie, ale nie sprawi, że synchronizacja stanie się idempotentem.

13) Kwoty całkowite

Przynajmniej raz - podstawowe, niezawodne semantyki transportowe.
Dokładnie raz jako efekt biznesowy jest osiągany na poziomie procesora: Idempotency-Key, Inbox/Outbox, Upsert/versions, SAGA/compensation.
Wybór jest kompromisem w zakresie kosztu i ryzyka powielania. Projektuj naturalne klucze, sprawiają, że siniaki idempotent, dodać obserwowalność i regularnie grać w dni gry - wtedy rurociągi będą przewidywalne i bezpieczne nawet w burzy retras i awarii.