Chyby Kafka producenta v Node.js: řešení a optimalizace

Problémy a řešení při práci s Kafka producerem v Node.js

Výběr partice pro zprávu je kritickým krokem ovlivňujícím rozložení zátěže mezi konzumenty. Nekorektní logika particirování může vést ke ztrátě rovnováhy a ztrátě škálovatelnosti.

Častou chybou je použití funkce particirování založené na celočíselném dělení hodnoty klíče zprávy (key). Pokud klíč není číslo nebo nelze správně převést na integer (např. MongoDB ObjectID), budou všechny zprávy směrovány do jediné partice.

const producer = await kafka.producer(topic, {
  createPartitioner: function () {
    return ({ partitionMetadata, message }: PartitionerArgs) => {
      return partitionMetadata.length
        ? partitionMetadata[Number(message.key) % partitionMetadata.length]?.partitionId || 0
        : 0;
    };
  },
});

V tomto případě konzumenti ve skupině nemohou efektivně rozdělit zátěž, protože všechna data budou soustředěna v jediné partici.

Řešení:

• Ověřovat typ a formát klíče partice na úrovni producenta.
• Nastavit metriky pro sledování nesymetrie velikostí partice.
• Použít spolehlivější algoritmy particirování, např. hashování řetězcového klíče.

Odeslání do neexistující partice

Číslování partice v tématu začíná od 0. Pokud producent pokusí o odeslání zprávy do partice s indexem vyšším než počet dostupných (např. do partice 1 v tématu s jednou particií), KafkaJS nevyhodí chybu. Metoda send() vrátí prázdný pole, a zpráva se ve skutečnosti nezaznamená.

const result = await producer.send({
  topic: 'user_events',
  messages: [
    { key: '2', value: 'user_created', partition: 1 }
  ]
});
console.log(result); // []

Řešení:

• Témata a partice vytvářet prostřednictvím konfiguračních souborů při nasazení, aby se vyhnuli ručním chybám.
• Ověřovat odpověď metody send() na úrovni aplikace. Pokud je výsledek prázdný nebo obsahuje chybu (např. errorCode není roven 0), je třeba podniknout akce: vyhodit výjimku, zaznamenat do logu, odeslat do rezervního tématu nebo odeslat metriku.
• Pravidelně ověřovat metadatové informace témat (seznam dostupných partice) před odesláním.

Neefektivní použití producentů

Vytvoření nové instance producenta (kafka.producer()) pro každý požadavek nebo operaci je běžnou chybou, která způsobuje významné náklady. Každý nový producent navazuje náročná síťová spojení s brokerama Kafka.

app.post('/send-message', async (request) => {
  const { topic, message } = request.body;
  const producer = kafka.producer(); // Nová instance na každý požadavek
  // ...
});

Řešení:

• Použít vzor Singleton nebo fond producentů. Vytvořte jednu instanci producenta a použijte ji pro všechny operace odesílání (producer.send()). To zvyšuje propustnost a snižuje zátěž brokerů.
• Pro vícevláknové nebo mikroservisové architektury zvažte použití sdíleného klienta Kafka s sdíleným producentem.

Síťové problémy a strategie opakovaných pokusů

Síť mezi producentem a klastru Kafka může být nestabilní. Pro zvýšení spolehlivosti doručení zpráv je třeba:

• Nakonfigurovat zpracování události request_timeout pro sledování síťových problémů.

producer.on('producer.network.request_timeout', (error) => {
  console.error({
    code: 'producer_network_timeout',
    message: error.message,
    data: { stack: error.stack },
  });
})

• Nakonfigurovat mechanismus opakování (retry) při vytváření producenta. Ve výchozím nastavení je počet pokusů roven 5.

kafka.producer({
  retry: { retries: 10 }
});

Důležité: Zvýšení počtu pokusů bez správné strategie (např. bez zvětšování intervalů mezi pokusy) může vést ke DDoS-podobné zátěži na brokeru. Používejte konfigurace s exponenciálním zpětným zpožděním (exponential backoff).

Zpracování velkých zpráv

Kafka není určena pro přenos zpráv větších než 1 MB. Odesílání velkých dat (5–10 MB) způsobuje vážné problémy:

• Častá rotace segmentů: při malém maximálním velikosti segmentu (např. 512 MB) způsobují velké zprávy rychlou rotaci, což zvyšuje zátěž systému.
• Vysoký síťový provoz: replikace velkých zpráv na všechny In-Sync Replicas (ISR) zvyšuje zátěž sítě.
• Snížená propustnost: buffer zpráv producenta roste, zvyšují se rizika ztráty dat a doba čekání na potvrzení při acks=-1.
• Spotřeba prostředků: vyžaduje více RAM pro os page cache na brokerech a pro JVM Kafka, zvyšuje se zátěž CPU kvůli práci sběrače odpadu (GC).

Doporučení pro velikost zpráv:

• Použijte vzorec: message.max.bytes = průměrná velikost zpráv * 2, ale menší než 1 Mb.
• Pro přenos velkých souborů (videa, zvuk, dokumenty) použijte externí úložiště (např. S3). V zprávě Kafka posílejte pouze odkaz na objekt.
• Pokud je nutné přenášet velké JSON/XML bez externího úložiště, pravděpodobně zpráva obsahuje nadbytečná data pro různé konzumenty. Zvažte rozdělení tématu na několik specializovaných, každé s minimálním nutným sadou polí.
• Alternativní, ale složitější přístup – rozdělení velké zprávy na bloky a sesbírání na straně konzumenta.

Co je důležité

• Particirování: Nekorektní výpočet partice vede ke ztrátě rovnováhy zátěže a ke ztrátě škálovatelnosti. Ověření klíče a monitorování metrik je povinné.
• Existence partice: Odeslání do neexistující partice v KafkaJS nevyvolá chybu, ale zpráva se nezaznamená. Ověření odpovědi send() je kritické.
• Efektivita producenta: Vytvoření nového producenta na každý požadavek je nákladná operace. Používejte Singleton nebo fond.
• Síť a opakování: Nastavení zpracování síťových timeoutů a strategie opakování zvyšuje spolehlivost doručení.
• Velikost zpráv: Přenos dat větších než 1 MB negativně ovlivňuje výkon klastru. Pro velké soubory používejte externí úložiště a optimalizujte strukturu zpráv.

— Editorial Team