Odpowiedź na pytanie

Historia pytania

Wzorzec skrzynki odbiorczej transakcyjnej stał się kluczowym rozwiązaniem dla problemu „podwójnego zapisu” charakterystycznego dla architektury systemów rozproszonych. Kiedy usługa aktualizuje bazę danych i jednocześnie publikuje wiadomość do brokera, te dwie operacje nie mogą być atomowe bez kosztownych transakcji rozproszonych, takich jak 2PC, których nowoczesne mikroserwisy unikają z powodu ograniczeń skalowalności i dostępności. Wzorzec zapisuje zdarzenia w tabeli skrzynki odbiorczej w ramach tej samej lokalnej transakcji bazy danych, co aktualizacje danych biznesowych, a następnie polega na oddzielnym procesie pośredniczącym w celu publikacji tych zdarzeń do magistrali wiadomości.

Problem

Podstawowym wyzwaniem walidacyjnym jest zapewnienie semantyki dokładnie raz (lub co najmniej raz z gwarantowaną idempotencją) podczas awarii infrastruktury, takich jak awarie PostgreSQL czy równoważenie brokerów Kafka. Bez rygorystycznych testów automatycznych, warunki wyścigu mogą powodować publikację zdarzeń wielokrotnie lub całkowitą ich utratę, prowadząc do niespójności danych i różnic finansowych. Dodatkowo weryfikacja, czy konsumenci downstream prawidłowo obsługują zduplikowane wiadomości, wymaga symulacji złożonych podziałów sieciowych i scenariuszy odzyskiwania po awarii, które są niemożliwe do reprodukcji w sposób konsekwentny poprzez testy manualne.

Rozwiązanie

Implementuj framework oparty na TestContainers, który orkiestruje klaster PostgreSQL główny-replika, broker Kafka oraz serwis aplikacyjny poddany testom. Zintegruj Toxiproxy, aby wprowadzać precyzyjne podziały sieciowe między bazą danych a serwisem pośredniczącym w kluczowych momentach. Zestaw walidacyjny musi potwierdzić, że zdarzenia są zapisywane w tabeli skrzynki odbiorczej z unikalnymi kluczami idempotencji, że proces pośredniczący (czy to oparty na polling, czy na Debezium CDC) publikuje te zdarzenia z kluczami nienaruszonymi oraz że konsumenci utrzymują magazyn do de-duplikacji, aby odrzucać duplikaty na podstawie tych kluczy. Wszyscy pracownicy testowi powinni wykonywać się w izolowanych przestrzeniach nazw Docker z efemerycznymi zespołami Zookeeper, aby zapobiec zanieczyszczeniu między testami.

-- Schemat tabeli skrzynki odbiorczej z ograniczeniem idempotencyjnym
CREATE TABLE outbox (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregate_id UUID NOT NULL,
    event_type VARCHAR(255) NOT NULL,
    payload JSONB NOT NULL,
    idempotency_key VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    processed BOOLEAN DEFAULT FALSE
);

-- Tabela de-duplikacji konsumenta
CREATE TABLE processed_messages (
    idempotency_key VARCHAR(255) PRIMARY KEY,
    processed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

// Logika idempotencji konsumenta
public void handleEvent(Message event) {
    try {
        deduplicationRepository.insert(event.getIdempotencyKey());
        businessService.processOrder(event.getPayload());
    } catch (DuplicateKeyException e) {
        log.info("Zignorowany duplikat idempotentny: {}", event.getIdempotencyKey());
    }
}

Sytuacja z życia

Opis problemu

Nasza platforma e-commerce wykorzystywała wzorzec skrzynki odbiorczej do publikacji zdarzeń zamówień z bazy danych PostgreSQL do Apache Kafka, zapewniając synchronizację usług inwentaryzacji i płatności. Podczas krytycznego wydarzenia Black Friday nagła awaria głównej bazy danych i przełączenie na replikę do odczytu spowodowały niespodziewane ponowne uruchomienie usługi publikowania, co skutkowało ponowną publikacją 15 000 zdarzeń „OrderCreated”, które już zostały przetworzone. Ta kaskada spowodowała podwójne obciążenie klientów i nadmierną sprzedaż zapasów, ponieważ konsumenci downstream nie mieli odpowiednich kontroli idempotencji, co skutkowało znacznymi stratami finansowymi i erozją zaufania klientów.

Rozwiązanie A: Ręczne testowanie awarii w stagingu

Zalety: Wykorzystuje infrastrukturę podobną do produkcyjnej bez konieczności dodatkowych narzędzi automatyzacyjnych lub złożonych skryptów; pozwala doświadczonym inżynierom QA intuicyjnie obserwować zachowanie systemu podczas scenariuszy awarii. Wady: Awarie bazy danych są z definicji nieprzewidywalne i trudne do precyzyjnego synchronizowania z wykonywaniem testów; nie można ich zintegrować z potokami CI/CD do ciągłego testowania regresyjnego; brak powtarzalności i nie można ich wykonać równolegle bez konfliktów koordynacyjnych.

Rozwiązanie B: Testowanie jednostkowe z udawanymi repozytoriami

Zalety: Zapewnia ekstremalnie szybkie czasy wykonywania poniżej 100 ms bez zewnętrznych zależności infrastrukturalnych; testy są w pełni deterministyczne i łatwe do debugowania w środowiskach IDE; pozwala na symulację teoretycznych przypadków brzegowych, które są trudne do wywołania w rzeczywistych systemach rozproszonych. Wady: Mocki nie potrafią symulować rzeczywistych poziomów izolacji transakcji PostgreSQL, zachowań równoważenia grup konsumenckich Kafka ani niuansów staku sieciowego TCP; nie mogą wykrywać warunków wyścigu w rzeczywistych sterownikach JDBC lub implementacjach na poziomie jądra.

Rozwiązanie C: Inżynieria chaosu w kontenerach z TestContainers

Zalety: Tworzy realistyczne środowisko wykorzystujące rzeczywistą replikację strumieniową PostgreSQL i brokerów Kafka; umożliwia precyzyjną iniekcję podziałów sieciowych i opóźnień przy użyciu Toxiproxy lub Pumba; w pełni powtarzalne i możliwe do zintegrowania z potokami CI/CD z obsługą wykonywania równoległego. Wady: Wymaga znacznego czasu początkowego ustawienia od 5 do 10 minut na zestaw testów; wymaga wyższych zasobów obliczeniowych i alokacji pamięci; wymaga starannej logiki czyszczenia, aby zapobiec wyczerpaniu portów i wiszącym kontenerom.

Wybrane rozwiązanie

Przyjęliśmy Rozwiązanie C, ponieważ tylko rzeczywiste interakcje z infrastrukturą mogły ujawnić specyficzny warunek wyścigu, gdzie PostgreSQL pomyślnie zatwierdził transakcję na węźle podstawowym, ale potwierdzenie zostało utracone podczas awarii sieci, co spowodowało, że publikator założył awarię i spróbował ponownie. wdrożyliśmy niestandardowe rozszerzenie JUnit 5, które orkiestruje Docker Compose z Pumba, aby symulować chaos sieciowy podczas kluczowych faz transakcji.

Wynik

Zautomatyzowany zestaw testów natychmiast wykrył, że nasza tabela skrzynki odbiorczej nie miała unikalnego ograniczenia na kolumnie idempotency_key, pozwalając publikatorowi na tworzenie zduplikowanych wierszy podczas ponownej próby. Po dodaniu ograniczenia i wdrożeniu warstwy de-duplikacji w konsumentach, test jest teraz uruchamiany w każdym buildzie CI, dostarczając informacji zwrotnej w ciągu 8 minut i redukując zdarzenia produkcyjne związane z duplikacją wiadomości o 95%. Zapobiegło to oszacowanym 50 tys. dolarów potencjalnych duplikatów obciążeń w kolejnych kwartałach.

Co często pomijają kandydaci

Jak wzorzec skrzynki odbiorczej zasadniczo różni się od wzorca sagi i dlaczego dwufazowe zatwierdzanie (2PC) jest nieskuteczne dla mikroserwisów?

Wzorzec skrzynki odbiorczej zapewnia atomowość między lokalnymi zmianami stanu bazy danych a publikacją zdarzeń w obrębie jednej granicy usługi, podczas gdy wzorzec sagi koordynuje długotrwałe transakcje rozproszone w wielu usługach za pomocą działań kompensacyjnych. 2PC jest nieskuteczne w mikroserwisach, ponieważ wymaga centralnego koordynatora do blokowania zasobów w obrębie granic usług, co tworzy ścisłe sprzężenie czasowe i ryzyko dostępności - jeśli jedna z uczestniczących usług przestaje odpowiadać, koordynator blokuje wszystkie inne uczestniczące usługi aż do upływu czasu, naruszając zasadę autonomii mikroserwisów.

Jakie są krytyczne kompromisy między używaniem publikatora pollingowego a opartym na logach przechwytywaniem danych zmian (CDC) takim jak Debezium dla pośrednictwa skrzynki odbiorczej?

Publikatory pollingowe zapytują tabelę skrzynki odbiorczej w odstępach czasu, co jest prostsze do wdrożenia i nie wymaga dodatkowej infrastruktury, ale wprowadza opóźnienia od 1 do 5 sekund i zwiększa obciążenie zapytań w bazie danych, które rośnie wraz z częstotliwością pollingu. Debezium i podobne rozwiązania CDC zapewniają niemal rzeczywiste strumieniowanie zdarzeń z minimalnym wpływem na bazę danych, odczytując WAL (Write-Ahead Log), ale dodają znaczną złożoność operacyjną, wymagając klastrów Kafka Connect, wymagają specyficznych konfiguracji bazy danych, takich jak logiczne sloty replikacji, i niosą ryzyko utraty danych, jeśli segmenty WAL zostaną skrócone przed zrealizowaniem.

Jak zapobiegać „zombie instance” - starym instancjom aplikacji, które tymczasowo ożywają z powodu uzdrowienia segmentu sieciowego - od publikowania przestarzałych zdarzeń skrzynki odbiorczej?

Zduplikowane instancje występują w przypadku, gdy segment sieciowy uzdrowi się po wybraniu nowej instancji podstawowej, co pozwala starej instancji kontynuować przetwarzanie swojej przestarzałej kolejki. Aby temu zapobiec, zaimplementuj tokeny ograniczające lub numery epok przechowywane w ZooKeeper lub etcd; proces pośredniczący musi weryfikować, czy jego epoka jest aktualna przed publikowaniem. Alternatywnie, użyj transakcyjnego producenta Kafka z unikalnym transactional.id, który automatycznie ogranicza starszych producentów, gdy nowa instancja się uruchamia, upewniając się, że tylko aktualna aktywna instancja może publikować zdarzenia do tematu.