Oppdatert kafka config. Det er blant annet tydeligere hvilken config som gjelder for hvilket topic

[olekvernberg]

Gjennomgang av kafka config

Setter auto-offset-reset: earliest for å sikre at ingen hendelser går tapt dersom offset mangler eller blir slettet. Ulempen er at dersom det må leses fra start, kan det ta noe tid (leesah/personhendelse-topic har 30 dagers retention). Likevel anses det som akseptabelt at hendelser i verste fall leses en dag etter publisering. For kontantstøtte-vedtak-topicet, som har 60 dagers retention og relativt få hendelser, er det også uproblematisk å lese fra start om offset mistes.

Transaksjoner
Konfigurasjon av transaksjoner og offset-commit kan være litt forvirrende siden det finnes to forskjellige innstillinger: enable-auto-commit: true/false og ackMode. enable-auto-commit er en Kafka-native innstilling, mens ackMode er spesifikk for Spring, og de fungerer i utgangspunktet uavhengig av hverandre. Problemer kan imidlertid oppstå hvis de er konfigurert på en «motstridende» måte. Generelt anbefales det å sette enable-auto-commit til false og la ackMode styre offset-commit. Det er sjelden nødvendig å sette auto-commit til true i applikasjoner. I enkelte tilfeller, som PoC eller logging hvor duplikater ikke er kritiske, kan auto-commit være hensiktsmessig. For de fleste produksjonsapplikasjoner er det imidlertid tryggest å sette auto-commit til false og konfigurere offset-commit med ackMode i Spring.

Standard ackMode i Spring er BATCH, som betyr at Spring committer offset etter at en batch er fullstendig prosessert. Siden vi ønsker å prioritere stabilitet og robusthet fremfor ytelse i alle apper, er det fornuftig å sette ackMode til MANUAL_IMMEDIATE. Dette gjør at offset committer så snart ack.acknowledge() kalles, uten å vente på eventuell post-prosessering som Spring ellers ville ha utført før commit.

max-poll-records er fortsatt viktig å sette, siden den styrer hvor mange hendelser som hentes inn til prosessering per poll, uavhengig av transaksjoner. Generelt anbefales det å ha en lav verdi dersom stabilitet prioriteres over ytelse. Jeg har satt denne til 1 for å være på den sikre siden, da ytelse ikke er et problem i vårt tilfelle, men det kan være noe defensivt.

Tiltak for å gjøre konfigurasjon mer forståelig
For apper med flere Kafka-listenere kan det være hensiktsmessig å unngå Kafka-consumer-konfigurasjon i application.yaml, da det lett kan bli uklart hvilke listenere konfigurasjonen gjelder for. I stedet anbefales det å opprette en egen kafkaListenerContainerFactory per topic, ettersom ulike topics ofte har behov for spesifikk konfigurasjon – for eksempel om de bruker Avro eller ikke.

Dette er hva jeg har kommet frem til, men er selvfølgelig åpen for diskusjon :)

Favro

[ViktorGSolberg]

setter pris på den utfyllende forklaringen 👍

[throndi]

Veldig bra 👏