Meglerkonfigurasjon og -justering

Hver broker i en Kafka-klynge trenger en unik identifikator. Denne angis ved hjelp av parameteren broker.id i server.properties.

Den må være et ikke-negativt heltall og være unik på tvers av alle brokerne i klyngen. Kafka bruker denne ID-en til å identifisere brokere for replikering, ledervalg og mer.

Parameteren log.dirs angir hvor Kafka lagrer loggsegmentene sine (de faktiske dataene for emner og partisjoner). Dette er en kritisk innstilling for ytelse og pålitelighet.

• Flere disker: Bruk en kommaseparert liste over mapper på forskjellige fysiske disker for bedre parallellitet ved I/O.
• Dedikerte disker: Bruk helst disker som er dedikert utelukkende til Kafka-logger, adskilt fra operativsystemet og andre applikasjoner.

Kafka-brokere kommuniserer via nettverkslyttere. Parameterne listeners og advertised.listeners definerer hvordan klienter og andre brokere kobler seg til.

• listeners: Grensesnittene som brokeren binder seg til (for eksempel PLAINTEXT://:9092).
• advertised.listeners: Adressen klienter og brokere bruker for å koble seg til (for eksempel PLAINTEXT://your.host.name:9092). Dette er avgjørende for ekstern tilgang eller oppsett med flere verter.

Når et emne opprettes uten eksplisitte innstillinger for partisjonering eller replikering, bruker Kafka standardverdier på brokernivå. Disse konfigureres ved hjelp av num.partitions og default.replication.factor.

• num.partitions: Angir standardantallet partisjoner for nye emner. Flere partisjoner gir høyere parallellitet.
• default.replication.factor: Angir standardantallet replikaer for nye emner. Flere replikaer gir bedre feiltoleranse.

Det anbefales vanligvis å angi disse eksplisitt for hvert emne, men standardverdiene fungerer som en reserve.

Kafka beholder meldinger i en konfigurerbar periode eller til de når en bestemt størrelse. Disse innstillingene hindrer at diskene blir fulle, og er avgjørende for å administrere lagringsplassen.

• log.retention.hours: Hvor lenge meldinger beholdes (for eksempel er 168 timer lik 7 dager).
• log.retention.bytes: Maksimal størrelse på et loggsegment før det kan slettes.

Kafka sletter meldinger basert på den grensen som nås først.

For å hindre at svært store meldinger påvirker brokerens ytelse eller forårsaker nettverksproblemer, lar Kafka deg angi en maksimal meldingsstørrelse på brokernivå via message.max.bytes.

Denne grensen gjelder den totale størrelsen på en komprimert meldingsgruppe. Hvis en produsent prøver å sende en melding som er større enn dette, blir den avvist. Produsenter har også sin egen max.request.size.

I tillegg til server.properties må også den underliggende Java Virtual Machine (JVM) og operativsystemet (OS) justeres for optimal Kafka-ytelse.

• JVM-heapstørrelse: Konfigurer KAFKA_HEAP_OPTS for å tildele tilstrekkelig minne (for eksempel 5–8 GB for dedikerte brokere).
• Søppelrydding: Velg en effektiv GC-algoritme (for eksempel G1GC), og juster parameterne til den.
• Fildeskriptorer: Øk operativsystemets grenser for åpne fildeskriptorer, siden Kafka bruker mange av dem til logger og tilkoblinger.

Vi har gått gjennom viktige Kafka-brokerkonfigurasjoner som påvirker ytelse, stabilitet og ressursbruk.

• Filen server.properties er sentral for hvordan en broker oppfører seg.
• Viktige parametere som broker.id, log.dirs, listeners, log.retention.hours og message.max.bytes er avgjørende for riktig oppsett.
• Husk også å ta hensyn til justeringer på JVM- og operativsystemnivå for en virkelig optimalisert klynge.

Grundig justering sikrer at Kafka-klyngen kan håndtere datastrømmene dine effektivt og pålitelig.