Broker-konfigurasjoner
| Eiendom | Standard | Beskrivelse | | broker.id | | Hver megler kan identifiseres med en unik ikke-negativ heltalls-ID; Denne ID-en kan brukes som "navnet" på megleren, og dens eksistens gjør at megleren kan migrere til en annen vert/port uten å forvirre forbrukerne. Du kan velge hvilket som helst nummer du vil som ID, så lenge ID-en er unik. | | log.dirs | /tmp/kafka-logs | Stien hvor kafka lagrer data. Denne stien er ikke unik, den kan være flere, og stiene trenger bare å være adskilt med kommaer; Når en ny partisjon opprettes, velges det å gjøre det under stien som inneholder færrest partisjoner. | | Havn | 6667 | Serveren aksepterer porten klienten kobler seg til | | zookeeper.connect | null | Formatet til ZooKeeper-tilkoblingsstrengen er: hostname:port, hvor vertsnavn og port henholdsvis er vert og port for en node i ZooKeeper-klyngen. For å koble til andre ZooKeeper-noder når en vert går ned, kan du opprette flere verter som følger:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper lar deg legge til en "chroot"-sti for å lagre all kafka-data i klyngen under en spesifikk sti. Når flere Kafka-klynger eller andre applikasjoner bruker samme ZooKeeper-klynge, kan du bruke denne metoden for å sette datalagringsstien. Dette kan implementeres ved å formatere tilkoblingsstrengen slik:
vertsnavn1:port1,vertsnavn2:port2,vertsnavn3:port3/chroot/path
Dette oppsettet lagrer all kafka-klyngedata under /chroot/path-stien. Merk at før du starter megleren, må du opprette denne veien, og forbrukerne må bruke samme tilkoblingsformat. | | message.max.bytes | 1000000 | Den maksimale størrelsen på meldinger en server kan motta. Det er viktig at innstillingene til forbruker og produsent når det gjelder denne eiendommen er synkronisert, ellers blir budskapet som publiseres av produsenten for stort for forbrukeren. | | num.nettverk.tråder | 3 | Antall nettverkstråder serveren bruker for å behandle nettverksforespørsler; Du trenger vanligvis ikke å endre denne eiendommen. | | num.io.threads | 8 | Antall I/O-tråder som brukes av serveren til å behandle forespørsler; Antall tråder bør være minst likt antall harddisker. | | bakgrunn.tråder | 4 | Antall tråder brukt til bakgrunnsbehandling, som filsletting; Du trenger ikke å endre denne eiendommen. | | queued.max.forespørsler | 500 | Det maksimale antallet forespørsler som kan stilles i kø for en I/O-tråd å behandle før en nettverkstråd slutter å lese nye forespørsler. | | host.name | null | meglerens vertsnavn; Hvis vertsnavnet allerede er satt, vil megleren kun være bundet til denne adressen; Hvis det ikke finnes noen innstilling, vil den binde til alle grensesnitt og publisere én kopi til ZK | | advertised.host.name | null | Hvis det er satt, sendes det til produsenter, forbrukere og andre meglere som vertsnavnet til megleren | | annonsert.port | null | Denne porten gis til produsenter, forbrukere og andre meglere, og brukes til å etablere en forbindelse; Den trenger bare å settes hvis den faktiske porten og porten serveren må binde er forskjellige. | | socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Cache-størrelse, som serveren bruker for å lage socket-tilkoblinger | | socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF cache-størrelse, som brukes av serveren til å koble til sockets | | socket.request.max.bytes | 100 * 1024 * 1024 | Maksimal forespørselsstørrelse tillatt av serveren; Dette vil unngå serveroverløp, som bør være mindre enn størrelsen på Java-heapen | | num.partisjoner | 1 | Hvis antallet partisjoner ikke er oppgitt ved opprettelse av et tema, vil dette tallet være standardantallet partisjoner under emnet. | | log.segment.bytes | 1014*1024*1024 | Loggene til emnepartisjonen lagres i mange filer i en bestemt mappe, som deler loggene til partisjonen inn i segmenter; Denne attributten er maksimal størrelse for hver fil; Når dimensjonene når denne verdien, opprettes en ny fil. Denne innstillingen kan overstyres av grunnlaget for hvert tema.
Utsikt Innloggingen med hyperkoblingen er synlig. | | logg.rull.timer | 24 * 7 | Selv om filen ikke når log.segment.bytes, opprettes en ny fil hver gang filopprettelsestiden når denne egenskapen. Denne innstillingen kan også overstyres av temanivå-innstillinger;
UtsiktInnloggingen med hyperkoblingen er synlig. | | log.cleanup.policy | Slett | | | logg.retention.minutes og log.retention.hours | 7 dager | Tiden hver loggfil ble lagret før den ble slettet. Standard datasparetid er den samme for alle temaer.
log.retention.minutes og log.retention.bytes brukes begge for å sette sletting av loggfiler, uavhengig av hvilken egenskap som er overløpt.
Denne egenskapsinnstillingen kan overstyres når emnet i praksis er satt.
UtsiktInnloggingen med hyperkoblingen er synlig. | | log.retention.bytes | -1 | Den totale mengden data lagret av hver partisjon under hvert emne; Merk at dette er øvre grense per partisjon, så dette tallet multiplisert med antall partisjoner er den totale mengden data lagret per emne. Merk også: Hvis både log.retention.hours og log.retention.bytes er satt, vil overskridelse av noen av grensene føre til at en segmentfil slettes.
Merk at denne innstillingen kan overstyres av hvert tema.
UtsiktInnloggingen med hyperkoblingen er synlig. | | log.retention.check.interval.ms | 5 minutter | Sjekk intervallet mellom loggsegmenterte filer for å avgjøre om filattributtene oppfyller slettingskravene. | | log.cleaner.enable | false | Når denne egenskapen settes til falsk, vil den bli slettet når loggen er lagret i maksimal tid eller størrelse. Hvis det settes til true, vil det skje når lagringsattributtet når øvre grenseInnloggingen med hyperkoblingen er synlig.。 | | log.cleaner.threads | 1 | Antallet tråder som utfører log-komprimering | | log.cleaner.io.max.bytes.per.sekund | Ingen | Det maksimale antallet I/O-er en loggrenser kan ha når den utfører en loggkomprimering. Denne innstillingen begrenser renseren for å unngå å forstyrre aktive forespørslingstjenester. | | log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indekserer logger under opprydningsprosessen og reduserer størrelsen på cachen som brukes. Det er best å sette den stor for å gi rikelig med minne. | | log.cleaner.io.buffer.load.factor | 512*1024 | Størrelsen på I/O-biten som kreves for tømmerrengjøring. Du trenger ikke å endre denne innstillingen. | | log.cleaner.io.buffer.load.factor | 0.9 | lastfaktoren til hashtabellen som brukes i loggrensing; Du trenger ikke å endre dette alternativet. | | log.cleaner.backoff.ms | 15000 | Tidsintervallet hvor loggen ryddes opp utføres | | tømmerrenser.min.rengjørbar.ratio | 0.5 | Denne konfigurasjonen styrer hvor ofte loggkompaktoren prøver å rydde opp i loggene (antattInnloggingen med hyperkoblingen er synlig.er åpen). Som standard bør du unngå å rense mer enn 50 % av stokkene. Dette forholdet er knyttet til maksimal plass som brukes av sikkerhetskopiloggen (50 % av loggene komprimeres ved 50 %). En høyere sats betyr mindre avfall og mer plass kan ryddes mer effektivt. Denne innstillingen kan overstyres i hver temainnstilling.
UtsiktInnloggingen med hyperkoblingen er synlig.。 | | log.cleaner.delete.retention.ms | 1 dag | lagringstid; Maksimal tid for å oppbevare komprimerte logger; Det er også maksimal tid for klienten til å konsumere meldinger, og forskjellen mellom log.retention.minutes er at den ene kontrollerer de ukomprimerte dataene og den andre kontrollerer de komprimerte dataene, som vil bli overskrevet innen den angitte tiden når temaet opprettes. | | log.index.size.max.bytes | 10*1024*1024 | Maksimal størrelse per tømmersegment. Merk at hvis log-størrelsen når denne verdien, må et nytt log-segment genereres selv om størrelsen ikke overstiger log.segment.bytes-grensen. | | log.index.interval.bytes | 4096 | Når du utfører en fetch, må du skanne nærmeste offset med en viss plass, jo større innstilling, desto bedre, vanligvis bruk standardverdien | | log.flush.interval.messages | Long.MaxValue | Loggfilen "synkroniserer" til disk før den akkumulerer meldinger. Siden disk-IO-operasjoner er en langsom operasjon, men også et nødvendig middele for "datapålitelighet", sjekk om tidsintervallet for å herde til harddisken er nødvendig. Hvis denne verdien er for stor, vil det føre til for lang "synkronisering"-tid (IO-blokkering), hvis denne verdien er for liten, vil det føre til lang tid med "fsync" (IO-blokkering), hvis denne verdien er for liten, vil det føre til et stort antall "synkroniserings"-tider, noe som betyr at den totale klientforespørselen har en viss forsinkelse, og feil på den fysiske serveren vil føre til tap av meldinger uten fsync. | | log.flush.scheduler.interval.ms | Long.MaxValue | Sjekk om det kreves fsync-intervaller | | log.flush.interval.ms | Long.MaxValue | Dette tallet brukes til å kontrollere tidsintervallet for «fsync»; hvis antall meldinger aldri når antallet meldinger som er festet til disken, men tidsintervallet fra siste disksynkronisering når terskelen, vil også disksynkronisering bli utløst. | | log.delete.delay.ms | 60000 | Oppbevaringstiden etter at filen er slettet i indeksen trenger vanligvis ikke å endres | | auto.create.topics.enable | true | Om man skal tillate automatisk opprettelse av emner. Hvis det er sant, vil det automatisk opprette et emne som ikke eksisterer når produce eller fetch ikke eksisterer. Ellers må du bruke kommandolinjen for å opprette et emne | | controller.socket.timeout.ms | 30000 | Tidsavbruddstiden for socketen når partisjonsstyringskontrolleren utfører en sikkerhetskopi. | | controller.message.queue.size | Int.MaxValue | Controller-til-megler-kanaler | | default.replication.factor | 1 | Standardantallet sikkerhetskopier refererer kun til automatisk opprettede emner | | replica.lag.time.max.ms | 10000 | Hvis en følger ikke sender en henteforespørsel innen denne tiden, vil lederen fjerne følgeren fra ISR og betrakte følgeren som hengt | | replica.lag.max.meldinger | 4000 | Hvis en replika har flere enn dette antallet usikkerhetskopierte, vil lederen fjerne følgeren og anse følgeren som hengt | | replica.socket.timeout.ms | 30*1000 | Lederens tidsavbrudd for socket-nettverksforespørsler ved sikkerhetskopiering av data | | replica.socket.receive.buffer.bytes | 64*1024 | Socket mottaksbuffer når man sender en nettverksforespørsel til lederen under backup | | replica.fetch.max.bytes | 1024*1024 | Maksimal verdi for hver henting ved sikkerhetskopiering | | replica.fetch.min.bytes | 500 | Maksimal ventetid for at data skal nå lederen når lederen gjør en backup-forespørsel | | replica.fetch.min.bytes | 1 | Den minste størrelsen på responsen etter hver henting når man rygger | | num.replica.fetchers | 1 | Antall tråder som sikkerhetskopierer data fra lederen | | replica.high.watermark.checkpoint.interval.ms | 5000 | Hver kopi sjekker hvor ofte det høyeste vannstanden herdes | | fetch.purgatory.purge.interval.requests | 1000 | hent forespørsel om purge-intervallet | | producer.purgatory.purge.interval.requests | 1000 | produsent ber om et purge-intervall | | zookeeper.session.timeout.ms | 6000 | Timeout for dyrepasser-økten. | | zookeeper.connection.timeout.ms | 6000 | Den maksimale tiden klienten venter på å etablere en forbindelse med dyrepasseren | | zookeeper.sync.time.ms | 2000 | ZK Follower ligger bak ZK Leader i lang tid | | controlled.shutdown.enable | true | Om det er mulig å kontrollere nedleggelsen av megleren. Hvis mulig, vil megleren kunne flytte alle ledere til andre meglere før overtakelsen. Dette reduserer utilgjengelighet under nedstengningsprosessen. | | controlled.shutdown.max.prøver på nytt | 3 | Antall kommandoer som kan utføre en avstenging før en ufullstendig avstenging. | | controlled.shutdown.retry.backoff.ms | 5000 | Tid for tilbaketrekning mellom nedstengninger | | auto.leader.rebalance.enable | true | Hvis dette stemmer, vil kontrolløren automatisk balansere meglerens ledelse over partisjonene | | leder.ubalanse.per.megler.prosent | 10 | Maksimal ubalansegrad tillatt av hver megler | | leader.imbalance.check.interval.seconds | 300 | Sjekk frekvensen av lederubalanse | | offset.metadata.max.bytes | 4096 | Lar klienter lagre maksimalt antall offsets sine | | max.connections.per.ip | Int.MaxValue | Maksimalt antall tilkoblinger per megler kan gjøres til hver IP-adresse | | max.connections.per.ip.overrides | | Maksimal dekning av standardtilkoblingen per IP eller vertsnavn | | connections.max.idle.ms | 600000 | Tidsbegrensning for tomme tilkoblinger | | logg.rull.jitter. {ms,timer} | 0 | Det maksimale antallet nerver abstrahert fra logRollTimeMillis | | num.recovery.threads.per.data.dir | 1 | Antall tråder som hver datakatalog bruker for å loggføre gjenoppretting | | uren.leder.valg.enable | true | Indikerer om det er mulig å bruke innstillingen for ikke-replikaer i ISR som leder | | delete.topic.enable | false | Kan slette emner | | offsets.topic.num.partitions | 50 | Antall partisjoner for offset-commit-temaet. Siden det å endre dette etter utrulling for øyeblikket ikke støttes, anbefaler vi å bruke en høyere innstilling for produksjon (f.eks. 100-200). | | offsets.topic.retention.minutes | 1440 | Offsets som har eksistert lenger enn denne tidsgrensen vil bli markert som ventende sletting | | offsets.retention.check.interval.ms | 600000 | Offset-manageren sjekker hyppigheten av stale offsets | | offsets.topic.replication.factor | 3 | Antall sikkerhetskopier av emnets offset. Det anbefales å sette høyere tall for å sikre høyere tilgjengelighet | | offset.topic.segment.bytes | 104857600 | Offset-tema. | | offsets.load.buffer.size | 5242880 | Denne innstillingen er relatert til batchstørrelsen og brukes når man leser fra offset-segmentet. | | offsets.commit.required.acks | -1 | Antallet bekreftelser må settes før offset-commit er akseptabelt, og trenger vanligvis ikke endres |
| Eiendom | Standard | Serverens standardegenskap | Beskrivelse | | Cleanup.policy | Slett | log.cleanup.policy | Enten «slette» eller «kompakt»; Denne strengen viser hvordan man kan bruke den gamle tømmerdelen; Standardmetoden ("slett") vil forkaste den gamle delen når resirkuleringstiden eller størrelsesgrensen er nådd. "kompakt" vil komprimere loggene | | delete.retention.ms | 864000000 (24 timer) | log.cleaner.delete.retention.ms | Forskjellen mellom log.retention.minutes er at den ene kontrollerer ukomprimerte data og den andre kontrollerer komprimerte data. Denne konfigurasjonen kan overstyres av pinningsparametrene når temaet opprettes | | flush.meldinger | Ingen | log.flush.interval.messages | Denne konfigurasjonen spesifiserer et tidsintervall for å tvinge fsync-logger. For eksempel, hvis dette alternativet er satt til 1, kreves fsync etter hver melding, og hvis det er satt til 5, kreves fsync for hver 5. melding. Generelt anbefales det at du ikke setter denne verdien. Innstillingen av denne parameteren krever den nødvendige avveiningen mellom «datapålitelighet» og «ytelse». Hvis denne verdien er for stor, vil det føre til lang tid med å "fsynce" hver gang (IO-blokkering), og hvis denne verdien er for liten, vil det føre til et stort antall "fsync", som også betyr at det er en viss forsinkelse i den totale klientforespørselen. Feil på den fysiske serveren vil føre til at meldinger går tapt uten fsync. | | flush.ms | Ingen | log.flush.interval.ms | Denne konfigurasjonen brukes for å fastsette tidsintervallet mellom tvinging av fsync-logger til disken; For eksempel, hvis den settes til 1000, kreves fsync hver 1000 ms. Dette alternativet anbefales generelt ikke | | index.interval.bytes | 4096 | log.index.interval.bytes | Standardinnstillingen sikrer at vi legger til en indeks i meldingen hver 4096 byte, og flere indekser gjør lesemeldingen nærmere, men indeksstørrelsen vil øke. Dette alternativet er vanligvis ikke nødvendig | | max.message.bytes | 1000000 | max.message.bytes | Den maksimale størrelsen på kafka-legg-meldingen. Merk at hvis du øker denne størrelsen, må du også øke hentestørrelsen til forbrukeren slik at forbrukeren kan hente meldinger til disse maksimale størrelsene. | | min.rengjøringsbart.skittent.forhold | 0.5 | min.rengjøringsbart.skittent.forhold | Denne konfigurasjonen styrer hvor ofte loggkompressoren forsøker å tømme loggene. Som standard vil logger med en komprimeringsrate på mer enn 50 % unngås. Dette forholdet unngår størst mulig plasssløsing | | min.insync.replicas | 1 | min.insync.replicas | Når produsenten settes til request.required.acks til -1, spesifiserer min.insync.replicas minimum antall replikaer (hver repica-skriving må være vellykket), og hvis dette tallet ikke nås, vil produsenten lage et unntak. | | retention.bytes | Ingen | log.retention.bytes | Hvis du bruker «delete»-lagringspolicyen, refererer denne konfigurasjonen til maksimal størrelse loggen kan oppnå før den slettes. Som standard finnes det ingen størrelsesgrense, bare en tidsbegrensning | | retention.ms | 7 dager | logg.retention.minutes | Hvis du bruker «slett»-oppbevaringspolicyen, refererer denne konfigurasjonen til tidspunktet da loggen ble lagret før slettingsloggen. | | segment.bytes | 1GB | log.segment.bytes | I Kafka lagres stokker i biter, og denne konfigurasjonen refererer til størrelsen på stokker delt inn i biter | | segment.index.bytes | 10MB | log.index.size.max.bytes | Denne konfigurasjonen er omtrent på størrelse med indeksfilen som er kartlagt mellom offsets og filplasseringer; Denne konfigurasjonen trenger vanligvis ikke å endres | | segment.ms | 7 dager | logg.rull.timer | Selv om loggchunk-filen ikke når den størrelsen som må slettes eller komprimeres, vil en ny log chunk-fil bli tvunget til å bli tvunget til å bli tvunget når logg-tiden når denne øvre grensen. | | segment.jitter.ms | 0 | logg.rull.jitter. {ms,timer} | Maksimal jitter som skal trekkes fra logRollTimeMillis. |
Forbrukerkonfigurasjoner
| Eiendom | Standard | Beskrivelse | | group.id | | En streng som entydig identifiserer gruppen der forbrukerprosessen befinner seg, og hvis samme gruppe-ID er satt, betyr det at disse prosessene tilhører samme forbrukergruppe | | zookeeper.connect | | Spesifiser strengen til Zookeeper-tilkoblingen, formatet er hostname:port, her er verten og porten både verten og porten til Zookeeper-serveren. For å unngå å miste kontakt etter at en Zookeeper-maskin går ned, kan du spesifisere flere hostname:ports, ved å bruke kommaer som separasjon:
vertsnavn1:port1,vertnavn2:port2,vertsnavn3:port3
Du kan legge til ZooKeepers chroot-sti i ZooKeeper-tilkoblingsstrengen, som brukes til å lagre egne data, på en måte:
vertsnavn1:port1,vertsnavn2:port2,vertsnavn3:port3/chroot/path | | consumer.id | null | Ingen oppsett er nødvendig, og det genereres vanligvis automatisk | | socket.timeout.ms | 30*100 | Tidsbegrensninger for nettverksforespørsler. Den egentlige timeout-grensen er max.fetch.wait+socket.timeout.ms | | socket.receive.buffer.bytes | 64*1024 | Socket brukes til å motta cache-størrelsen til nettverksforespørsler | | fetch.message.max.bytes | 1024*1024 | Maksimalt antall bytes per hentemelding per henteforespørsel. Disse bytene vil bli overvåket i minnet som brukes for hver partisjon, så denne innstillingen vil kontrollere mengden minne som brukes av forbrukeren. Størrelsen på henteforespørselen må være minst lik den maksimale meldingsstørrelsen serveren tillat, ellers er størrelsen på meldingen produsenten kan sende større enn størrelsen forbrukeren kan konsumere. | | num.forbruker.hentere | 1 | Antall hentetråder brukt for hentedata | | auto.commit.enable | true | Hvis det stemmer, vil offset av meldingen som hentes av forbrukeren automatisk synkroniseres med dyrepasseren. Denne commit-offset vil bli brukt av den nye forbrukeren når prosessen stopper opp | | auto.commit.interval.ms | 60*1000 | Frekvensen forbrukeren sender inn offset til dyrepasseren er i sekunder | | queued.max.message.chunks | 2 | Det maksimale antallet meldinger som brukes til å cache for konsum. Hver chunk må være den samme som fetch.message.max.bytes | | rebalance.max. prøver på nytt | 4 | Når en ny forbruker legges til i en forbrukergruppe, forsøker samlingen av forbrukere å rebalansere antall partisjoner tildelt hver forbruker. Hvis forbrukerens samling endres, feiler denne rebalanseringen og reenterifiseres når allokeringen utføres | | hent.min.bytes | 1 | Minimum antall bytes som serveren skal returnere med hver henteforespørsel. Hvis ikke nok data returneres, venter forespørselen til nok data er returnert. | | fetch.wait.max.ms | 100 | Hvis det ikke er nok data til å tilfredsstille fetch.min.bytes, refererer denne konfigurasjonen til maksimal tid serveren blokkerer før den svarer på en fetch-forespørsel. | | rebalance.backoff.ms | 2000 | Tid for å trekke seg tilbake før jeg prøver reblance på nytt | | refresh.leader.backoff.ms | 200 | Det er en tid til å vente før man prøver å avgjøre om lederen for en deling har mistet sitt lederskap | | auto.offset.reset | Størst | Hvis det ikke finnes noe initialisert offset i Zookeeper, hvis offset er et svar på følgende verdi:
minste: Auto-reset offset til minste offset
største: Automatisk tilbakestillingsoffset til offset av største
Alt annet: gir et unntak for forbrukeren | | consumer.timeout.ms | -1 | Hvis ingen melding er tilgjengelig, selv etter å ha ventet en bestemt tid, kastes et timeout-unntak | | ekskluder.intern.emner | true | Om man skal eksponere meldinger fra interne temaer til forbrukerne | | parition.assignment.strategy | Utbredelse | Velg policyen for å tildele partisjoner til forbrukerflyten, eventuelt range, roundrobin | | client.id | Gruppe-ID-verdi | er en brukerspesifikk streng som hjelper til med å spore kall i hver forespørsel. Den skal logisk bekrefte applikasjonen som genererte forespørselen | | zookeeper.session.timeout.ms | 6000 | Tidsbegrensninger for dyrepasser-økter. Hvis forbrukeren ikke sender en hjerteslagsmelding til dyrepasseren i denne perioden, regnes den som hengt opp og en reblance vil bli generert | | zookeeper.connection.timeout.ms | 6000 | Maksimal ventetid for en klient å etablere en Zookeeper-forbindelse | | zookeeper.sync.time.ms | 2000 | ZK-følgere kan henge etter ZK-lederen i maksimal tid | | offsets.storage | Dyrepasseren | Steder brukt til å lagre offsets: dyrepassere eller kafka | | offset.channel.backoff.ms | 1000 | Backoff-tiden for å koble til offset-kanalen igjen eller prøve hente-/commit-forespørselen på nytt for den mislykkede offseten | | offsets.channel.socket.timeout.ms | 10000 | Socket-timeout-grensen for responsen på hente-/commit-forespørselen når leseoffset. Denne tidsbegrensningen brukes av consumerMetadata-forespørselen for å be om offset-administrasjon | | offsets.commit.max. prøver på nytt | 5 | Antall ganger offset-commit ble prøvd på nytt. Dette forsøket brukes kun på offset-commits mellom nedstengninger. ham | | dual.commit.enabled | true | Hvis du bruker "kafka" som offsets.storage, kan du commit offset til Zookeeper to ganger (og én gang til kafka). Dette er et must når man migrerer fra dyrepasser-basert offset-lagring til kafka-basert offset-lagring. For enhver forbrukergruppe er det en trygg anbefaling å slå av dette alternativet når migreringen er fullført | | partition.assignment.strategy | Utbredelse | Velg mellom "range"- og "roundrobin"-policyene som policy for å tildele partisjoner til forbrukerdataflyter; Den sirkulære partisjonsallokatoren allokerer alle tilgjengelige partisjoner samt alle tilgjengelige forbrukertråder. Den vil tildele partisjonsløkken til forbrukertråden. Hvis alle forbrukerinstanser abonneres på en determinert, deles partisjonene inn i deterministiske fordelinger. Round-robin-allokeringsstrategien er kun mulig hvis følgende betingelser er oppfylt: (1) Hvert emne har samme antall dataflyter per forbrukerstyrke. (2) Samlingen av abonnerte temaer bestemmes for hver forbrukerinstans i forbrukergruppen. |
Produsentkonfigurasjoner
| Eiendom | Standard | Beskrivelse | | metadata.broker.list | | Tjener bootstrapping. Producer brukes kun til å hente metadata (emner, partisjoner, replikaer). Socket-tilkoblingen for å sende de faktiske dataene vil bli etablert basert på de returnerte metadataene. Formatet er:
vert1:port1,vert2:port2
Denne listen kan være en underliste over meglere eller en VIP som peker til meglere | | forespørsel.påkrevd.acks | 0 | Denne konfigurasjonen er en bekreftelsesverdi som indikerer når en produksjonsforespørsel anses som fullført. Spesielt hvor mange andre meglere som må ha sendt inn data til loggene sine og bekreftet denne informasjonen til sin leder. Typiske verdier inkluderer:
0: Indikerer at produsenten aldri venter på bekreftelse fra megleren (samme oppførsel som 0,7). Dette alternativet gir minst ventetid, men samtidig størst risiko (fordi data går tapt når serveren går ned).
1: Indikerer at lederreplikaen har mottatt databekreftelsen. Dette alternativet har lav latens og sikrer at serveren bekrefter at det er mottatt.
-1: Produsenten får bekreftelse på at alle synkroniserte replikaer har mottatt data. Forsinkelsen er størst, men denne metoden eliminerer ikke helt risikoen for tapte meldinger, fordi antallet synkroniserte replikaer kan være 1. Hvis du vil sikre at noen replikaer mottar data, bør du sette valget min.insync.replicas i temanivåinnstillingene. Les designdokumentasjonen for en mer grundig diskusjon. | | request.timeout.ms | 10000 | Megleren gjør sitt beste for å implementere request.required.acks-kravet, ellers vil en feil bli sendt til klienten | | producer.type | Synkronisering | Dette valget fester om meldingen sendes asynkront i en bakgrunnstråd. Riktige verdier:
(1) asynkron: Asynkron sending
(2) synkronisering: Synkronisert sending
Ved å sette produsenten til asynkron kan vi behandle forespørsler i batcher (noe som er bra for høyere gjennomstrømning), men dette skaper også muligheten for at klientmaskinen mister usendte data | | serializer.class | kafka.serializer.DefaultEncoder | Serialiseringskategorien til meldingen. Standardkoderen taster inn én byte[] og returnerer samme byte[] | | key.serializer.class | | Serialiseringsklasse for nøkkelord. Hvis dette ikke er gitt, er standarden å matche meldingen | | partitioner.class | kafka.producer.DefaultPartitioner | partisjonerklasse for å dele meldinger mellom underemner. Standardpartisjoneren er basert på nøkkelens hashtabell | | compression.codec | ingen | Denne parameteren kan sette kodeken for komprimering av data, som kan velges som "ingen", "gzip", "snappy". | | komprimerte.emner | null | Denne parameteren kan brukes til å bestemme om visse temaer skal komprimeres. Hvis den komprimerte kodeken er en annen kodek enn NoCompressCodec, brukes disse kodekene på de spesifiserte emnedataene. Hvis listen over komprimerte temaer er tom, bruk den spesifikke komprimerte kodeken på alle temaer. Hvis den komprimerte kodeken er NoCompressionCodec, er ikke komprimeringen tilgjengelig for alle emner. | | message.send.max. prøver på nytt | 3 | Denne parameteren vil få produsenten til automatisk å prøve mislykkede send-forespørsler på nytt. Denne parameteren fastsetter antall forsøk. Merk: Å sette en verdi som ikke er 0 vil føre til at visse nettverksfeil gjentas: forårsaker sending og tap av bekreftelse | | retry.backoff.ms | 100 | Før hvert nytt forsøk oppdaterer produsenten metadataene til det aktuelle temaet for å se om den nye lederen er tildelt. Fordi ledervalget tar litt tid, spesifiserer dette valget hvor lenge produsenten må vente før metadataene kan oppdateres. | | topic.metadata.refresh.interval.ms | 600*1000 | Produsenten oppdaterer vanligvis emnets metadata i noen feilscenarier (partisjon mangler, leder utilgjengelig, osv.). Han vil gå gjennom en vanlig syklus. Hvis du setter den til en negativ verdi, vil metadataene bare bli oppdatert hvis den feiler. Hvis den settes til 0, oppdateres metadataene etter hver melding som sendes (dette alternativet anbefales ikke, systemet bruker for mye). Viktig: Oppdateringer skjer først etter at meldingen er sendt, så hvis produsenten aldri sender meldingen, blir metadataene aldri oppdatert. | | queue.buffering.max.ms | 5000 | Det maksimale tidsintervallet brukeren cacher data når asynkron modus benyttes. For eksempel, hvis meldingen settes til 100, vil meldinger innenfor 100 ms bli behandlet i batcher. Dette vil forbedre gjennomstrømningen, men øke latensen på grunn av caching. | | queue.buffering.max.meldinger | 10000 | Når man bruker asynkron modus, må det maksimale antallet usendte meldinger som kan caches til køen før produsenten blokkeres, eller data må gå tapt | | batch.num.meldinger | 200 | Når du bruker asynkron modus, kan du batchbehandle maksimalt antall meldinger. Eller antallet meldinger har nådd dette på nettet eller queue.buffer.max.ms har ankommet, og produsenten vil behandle det | | send.buffer.bytes | 100*1024 | Socket write cache-størrelse | | client.id | “” | Denne klient-ID-en er en brukerspesifikk streng som inkluderes i hver forespørsel for å spore kallet, og han bør logisk kunne bekrefte at applikasjonen har gjort forespørselen. |
Produsentkonfigurasjoner
| Navn | Type | Standard | Betydning | Beskrivelse | | boostrap.servere | Liste | | høyt | Vert/port-gruppe for å etablere en forbindelse til kafka-klyngen. Data vil bli lastet jevnt på tvers av alle servere, uavhengig av hvilken server som er utpekt for oppstart. Denne listen påvirker kun de initialiserte vertene (som brukes til å oppdage alle servere). Dette listeformatet:
host1:port1,host2:port2,...
Siden disse serverne kun brukes til å initialisere tilkoblinger for å oppdage alle medlemskapene i klyngen (som kan endres dynamisk), trenger ikke denne listen å inneholde alle servere (du kan ønske mer enn én server, selv om én server i dette tilfellet kan være nede). Hvis ingen server vises i denne listen, vil sending av data feile inntil listen er tilgjengelig. | | ACKS | Streng | 1 | høyt | Produsenten trenger et signal fra serveren for å bekrefte mottak etter å ha mottatt dataene, og denne konfigurasjonen refererer til hvor mange slike bekreftelsessignaler prokuratoren trenger. Denne konfigurasjonen representerer faktisk tilgjengeligheten av sikkerhetskopier av data. Følgende innstillinger er vanlige alternativer:
(1) acks=0: Satt til 0 betyr at produsenten ikke trenger å vente på noen bekreftelse av den mottatte informasjonen. Replikaen vil umiddelbart bli lagt til socket-bufferen og regnes som sendt. Det er ingen garanti for at serveren har mottatt dataene i dette tilfellet, og et nytt forsøk på konfigurasjonen vil ikke fungere (fordi klienten ikke vet om det feilet), og offsetet av tilbakemeldingen vil alltid være satt til -1.
(2) acks=1: Dette betyr at man i det minste må vente på at lederen skal skrive dataene til den lokale loggen, men ikke at alle følgerne skal skrive riktig. I dette tilfellet, hvis følgeren ikke tar sikkerhetskopi av dataene og lederen legger på igjen, vil meldingen gå tapt.
(3) acks=alle: Dette betyr at lederen må vente på at alle sikkerhetskopier skal skrive logger, og denne strategien vil sikre at data ikke går tapt så lenge én sikkerhetskopi overlever. Dette er den sterkeste garantien.
(4) Andre innstillinger, som acks=2, er også mulige, som krever et gitt antall acks, men denne strategien brukes vanligvis sjelden. | | buffer.minne | lang | 33554432 | høyt | Produsenten kan brukes til å cache minnestørrelsen på dataene. Hvis dataene genereres raskere enn de sendes til megleren, vil produsenten blokkere eller kaste et unntak, indikert med "block.on.buffer.full".
Denne innstillingen vil være relatert til det totale minnet produsenten kan bruke, men det er ikke en hard grense, siden ikke alt minne produsenten bruker til caching. Noe ekstra minne brukes til komprimering (hvis komprimering introduseres), og noe brukes til vedlikeholdsforespørsler. | | compression.type | Streng | ingen | høyt | Produsent er typen komprimering som brukes til å komprimere data. Standardinnstillingen er ukomprimert. De riktige opsjonsverdiene er ingen, gzip, snappy.
Komprimering er best egnet for batchbehandling; jo flere meldinger som behandles i batcher, desto bedre komprimeringsytelse. | | Forsøk på nytt | Int | 0 | høyt | Å sette en verdi større enn 0 vil føre til at klienten sender data på nytt når dataene feiler. Merk at disse forsøkene ikke er annerledes enn de når klienten mottar en send-feil. Tillater nye forsøk på å potensielt endre rekkefølgen på dataene; hvis begge meldingspostene sendes til samme partisjon, feiler den første meldingen, og den andre meldingen vises tidligere enn den første. | | batch.size | Int | 16384 | Middels | Produsenten vil forsøke å batche meldingspostene for å redusere antall forespørsler. Dette vil forbedre ytelsen mellom klient og server. Denne konfigurasjonen styrer standardantall byte for batchbehandlingsmeldinger.
Det gjøres ingen forsøk på å behandle meldingsbytes større enn dette byteantallet.
Forespørsler sendt til meglere vil inneholde flere batcher, som vil inneholde én forespørsel for hver partisjon.
Mindre batchverdier brukes mindre og kan redusere gjennomstrømningen (0 vil kun bruke batchprosessering). Større batchverdier kaster bort mer minneplass, så du må allokere minne til spesifikke batchverdier. | | client.id | Streng | | Middels | Denne strengen sendes til serveren når en forespørsel gjøres. Hensikten er å kunne spore kilden til forespørsler slik at noen applikasjoner utenfor IP/Port-allowlisten kan sende informasjon. Denne appen kan sette hvilken som helst streng fordi den ikke har noen funksjonell funksjon annet enn å ta opp og spore | | linger.ms | lang | 0 | Middels | Produsentgruppen vil aggregere alle meldinger som ankommer mellom forespørselen og sendingen, og registrere en separat batch med forespørsler. Vanligvis skjer dette bare når posten genereres raskere enn sendehastigheten. Men under visse betingelser vil klienten ønske å redusere antall forespørsler, eller til og med til moderat belastning. Denne oppsettet gjøres ved å legge til en liten forsinkelse – det vil si at i stedet for å sende en post umiddelbart, vil produsenten vente til en gitt forsinkelsestid for å tillate at andre meldingsposter kan sendes, som kan batches. Dette kan betraktes som en lignende algoritme som TCP Nagle. Denne innstillingen setter en høyere latensgrense for batching: når vi får batch.size til en partisjon, vil den sende den umiddelbart uavhengig av denne innstillingen, men hvis vi får en melding med mye mindre byteantall enn denne innstillingen, må vi "bli værende" en bestemt tid for å få flere meldinger. Denne innstillingen er standard 0, altså ingen forsinkelse. Å sette linger.ms=5, for eksempel, vil redusere antall forespørsler, men samtidig øke forsinkelsen med 5 ms. | | max.request.size | Int | 1028576 | Middels | Maksimalt antall bytes som ønskes. Dette er også en effektiv dekning for maksimal registrert størrelse. Merk: Serveren har sin egen overstyring av meldingspoststørrelser, som er annerledes enn denne innstillingen. Denne innstillingen begrenser antall forespørsler produsenter kan sende i bulk om gangen for å forhindre et stort antall forespørsler. | | receive.buffer.bytes | Int | 32768 | Middels | TCP receivecache-størrelse, som brukes når man leser data | | send.buffer.bytes | Int | 131072 | Middels | TCP send cache-størrelse, som brukes når man sender data | | timeout.ms | Int | 30000 | Middels | Dette konfigurasjonsvalget styrer hvor lang tid serveren venter på bekreftelse fra følgere. Hvis antallet bekreftede forespørsler ikke er oppfylt innen denne tiden, returneres en feilmelding. Denne timeout-grensen måles på serversiden og har ingen nettverksforsinkelse inkludert forespørsler | | block.on.buffer.full | Boolesk | true | lavt | Når minnecachen vår går tom, må vi slutte å motta nye meldingsposter eller kaste feil. Som standard er dette satt til true, men noe blokkering er kanskje ikke verdt å forvente, så det er bedre å gi en feil med en gang. Dette er tilfellet når det settes til false: produsenten kaster en unntaksfeil: BufferExhaustedException hvis posten er sendt og cachen er full | | metadata.fetch.timeout.ms | lang | 60000 | lavt | Det refererer til førstegangsdata for noen elementer vi har innhentet. Elementene inkluderer: tema, vert, partisjoner. Denne konfigurasjonen refererer til tiden som kreves for at elementet skal fullføres i henhold til hentingen, ellers vil et unntak bli sendt til klienten. | | metadata.max.age.ms | lang | 300000 | lavt | Tid i mikrosekunder er intervallet hvor vi tvinger metadataene til å oppdateres. Selv om vi ikke ser noen endringer i delingsledelsen. | | metric.reporters | Liste | [] | lavt | En liste over klasser som brukes til å måle målinger. Implementeringen av MetricReporter-grensesnittet vil gjøre det mulig å legge til klasser som endres etter hvert som nye måleparametere genereres. JmxReporter vil alltid inkludere en måte å registrere JMX-statistikk på | | metrics.num.samples | Int | 2 | lavt | Antall utvalg brukt for å opprettholde måleparametere | | metrics.sample.window.ms | lang | 30000 | lavt | Metrics-systemet opprettholder et konfigurerbart antall prøver i et korrigerbart vindu. Denne konfigurasjonen konfigurerer for eksempel vindusstørrelsen. Vi kan beholde to prøver i 30 sekunder. Når et vindu rulles ut, sletter og skriver vi om det eldste vinduet | | recoonect.backoff.ms | lang | 10 | lavt | Når forbindelsen svikter, ventetiden når vi kobler til igjen. Dette unngår gjentatte klienttilkoblinger | | retry.backoff.ms | lang | 100 | lavt | Ventetiden før man prøver å prøve på nytt en mislykket forespørsel om frukt og grønt. Unngå å bli sittende fast i en send-fail deadloop.
|
|
Publisert på 24.06.2021 11:47:12
|
|
|
Vert