Kafka w Node.js: niezawodne konsumery i skalowanie

# Efektywna obsługa wiadomości Kafka w Node.js: konsumenci, rebalansowanie i skalowanie

Korzystna implementacja konsumentów Kafka w Node.js wymaga zrozumienia nie tylko podstawowego API, ale także architekturalnych cech rozproszonej kolejki. Błędy w konfiguracji partycji, strategii odczytu lub zarządzaniu offsetami prowadzą do utraty wiadomości, nadmiernych rebalansów i spadku przepustowości. W tym artykule omawiamy kluczowe aspekty budowania niezawodnych i wydajnych konsumentów z wykorzystaniem KafkaJS.

Partycje jako podstawa skalowania

Skalowanie konsumpcji wiadomości z tematu Kafka jest ograniczone liczbą partycji. Niezależnie od liczby uruchomionych instancji, liczba aktywnych konsumentów w grupie nie może przekraczać liczby partycji w temacie. Formuła jest prosta: N_konsumentów ≤ N_partycji. Przekroczenie tego stosunku powoduje, że część instancji pozostaje bez przydziału i bezczynnie stoi, tworząc fałszywe obciążenie koordynatora grupy.

Wybor początkowej liczby partycji to decyzja strategiczna. Chociaż Kafka pozwala zwiększać liczbę partycji „w locie”, narusza to gwarancję kolejności wiadomości według klucza: nowe wiadomości z tym samym kluczem mogą trafić do innej partycji niż poprzednie. Dla elastyczności zaleca się wybór liczby z wieloma dzielnikami (np. 24), aby zapewnić równomierne rozłożenie przy dowolnej liczbie konsumentów od 1 do 24.

Warto pamiętać: całkowita liczba partycji w całym klastrze nie powinna przekraczać 200 000. Dlatego dla tematów o niskim obciążeniu nadmierne dzielenie nie jest uzasadnione.

Równoległa obróbka i wybór replik

Nawet przy kilku partycjach u jednego konsumenta obróbka domyślnie jest sekwencyjna. Aby włączyć paralelizm wewnątrz instancji, używa się opcji partitionsConsumedConcurrently:

consumer.run({
    partitionsConsumedConcurrently: 3,
    eachMessage: async ({ topic, partition, message }) => {
        // processing
    },
});

Wtedy gwarancja kolejności jest zachowana w ramach jednej partycji, ale nie między nimi. Pozwala to bezpiecznie zwiększać przepustowość bez naruszania logiki obróbki.

Dla klastrów rozproszonych geograficznie kluczowa jest latencja sieci. Domyślnie konsumenci czytają dane z repliki lidera, która obsługuje też zapis. Tworzy to wąskie gardło. Rozwiązanie — użycie rack-aware replikacji. Na brokerach ustawia się parametr broker.rack, a w kliencie rackId:

const consumer = kafka.consumer({
  groupId: 'user-service',
  rackId: 'sibir_tomsk'
});

Kafka wtedy kieruje zapytania do repliki w tym samym „domenie rackowym”, minimalizując latencję. Niewielkie opóźnienie replikacji jest dopuszczalne w większości scenariuszy, ponieważ Kafka nie jest przeznaczona do ścisłego czasu rzeczywistego.

Zarządzanie offsetami i początkowy odczyt

Nowe grupy konsumentów napotykają powszechny błąd: nie widzą historycznych wiadomości. Przyczyna — zachowanie parametru auto.offset.reset, który domyślnie jest ustawiony na latest. Oznacza to, że przy braku zatwierdzonego offsetu w __consumer_offsets konsument zacznie czytać od końca partycji.

Alternatywa — earliest, ale jej użycie bez kontroli jest ryzykowne: obróbka wieloletniej historii może przeciążyć serwis i zależne systemy. Bezpieczniejsze podejście:

• Używać fromBeginning: true przy subskrypcji, jeśli wymagana jest pełna historia:

await consumer.subscribe({ topic: 'user_events', fromBeginning: true });

Ta opcja działa tylko przy pierwszym połączeniu. Po pierwszym commicie offsetu Kafka ignoruje fromBeginning.

• Do punktowego przywracania — ręcznie ustawić offset przez CLI lub narzędzia UI (KafkaUI, Kadeck) po zatrzymaniu konsumenta.

Taki kontrol zapobiega przypadkowemu nadpisaniu offsetów i gwarantuje integralność obróbki.

Strategie rebalansowania i ich pułapki

Rebalans to proces redystrybucji partycji przy zmianie składu grupy. W KafkaJS obsługiwana jest tylko strategia Eager, w której wszyscy konsumenci zatrzymują obróbkę („stop-the-world”), kończą bieżące zadania, commitują offsety i czekają na przydział nowych partycji.

Częste rebalansy zmniejszają dostępność i zwiększają opóźnienie. Główne przyczyny:

• Mieszana funkcjonalność w jednym procesie — serwer HTTP, zadania tła i konsument w jednej instancji. Błąd krytyczny poza obróbką wiadomości powoduje upadek całego procesu i wyzwala rebalans.
• Nieprawidłowe timeouty — wartości sessionTimeout i heartbeatInterval muszą być skoordynowane. Typowa reguła: heartbeatInterval ≤ sessionTimeout / 3.
• Długa obróbka wiadomości — jeśli obróbka jednej wiadomości przekracza rebalanceTimeout, konsument jest wykluczany z grupy.

Do diagnostyki przydatne jest subskrybowanie zdarzenia REBALANCING:

consumer.on(consumer.events.REBALANCING, ({ payload }) => {
  console.log('Rebalancing started for group:', payload.groupId);
});

Pozwala to zbierać metryki i wykrywać anomalne częstotliwości rebalansów.

Chociaż Kafka 2.3+ oferuje Static Membership i CooperativeStickyAssignor do łagodzenia tych problemów, KafkaJS jeszcze ich nie obsługuje. Dlatego środki architektoniczne to jedyna droga do stabilności.

Co ważne

• Liczba partycji określa górny limit poziomego skalowania konsumentów.
• Równoległa obróbka (partitionsConsumedConcurrently) przyspiesza obróbkę bez utraty kolejności wewnątrz partycji.
• Odczyt z lokalnej repliki (rackId) zmniejsza opóźnienie sieciowe w środowiskach georozproszonych.
• Nowe grupy konsumentów domyślnie pomijają historię — używaj fromBeginning lub ręcznej ustanovki offsetów.
• Izoluj konsumentów od innych komponentów aplikacji, aby uniknąć nieuzasadnionych rebalansów.

— Editorial Team