Broker-konfigurationer
| Ejendom | Standard | Beskrivelse | | broker.id | | Hver mægler kan identificeres med et unikt ikke-negativt heltals-ID; Dette id kan bruges som "navnet" på mægleren, og dets eksistens gør det muligt for mægleren at migrere til en anden vært/port uden at forvirre forbrugerne. Du kan vælge et hvilket som helst nummer, du vil, som ID, så længe ID'et er unikt. | | log.dirs | /tmp/kafka-logs | Stien hvor Kafka gemmer data. Denne sti er ikke unik, den kan være multipla, og stierne behøver kun at være adskilt med kommaer; Når en ny partition oprettes, vælges den til at ske under den sti, der indeholder færrest partitioner. | | Havn | 6667 | Serveren accepterer den port, som klienten forbinder til | | zookeeper.connect | nul | Formatet for ZooKeeper-forbindelsesstrengen er: hostname:port, hvor værtsnavn og port henholdsvis er vært og port for en node i ZooKeeper-klyngen. For at forbinde til andre ZooKeeper-noder, når en vært går ned, kan du oprette flere værter som følger:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper giver dig mulighed for at tilføje en "chroot"-sti til at gemme alle kafka-data i klyngen under en bestemt sti. Når flere Kafka-klynger eller andre applikationer bruger den samme ZooKeeper-klynge, kan du bruge denne metode til at indstille datalagringsstien. Dette kan implementeres ved at formatere forbindelsesstrengen således:
værtsnavn1:port1,værtsnavn2:port2,værtsnavn3:port3/chroot/sti
Denne opsætning gemmer alle kafka-klyngedata under /chroot/path-stien. Bemærk, at før du starter mægleren, skal du oprette denne sti, og forbrugerne skal bruge samme forbindelsesformat. | | message.max.bytes | 1000000 | Den maksimale størrelse af beskeder, som en server kan modtage. Det er vigtigt, at forbrugerens og producentens indstillinger i forhold til denne ejendom er synkroniserede, ellers bliver det budskab, producenten offentliggør, for stort for forbrugeren. | | num.netværk.tråde | 3 | Antallet af netværkstråde, som serveren bruger til at behandle netværksforespørgsler; Du behøver som regel ikke ændre denne ejendom. | | num.io.threads | 8 | Antallet af I/O-tråde, som serveren bruger til at behandle anmodninger; Antallet af tråde bør mindst svare til antallet af harddiske. | | baggrund. tråde | 4 | Antallet af tråde brugt til baggrundsbehandling, såsom filsletning; Du behøver ikke ændre denne ejendom. | | queued.max.anmodninger | 500 | Det maksimale antal forespørgsler, der kan sættes i kø for en I/O-tråd at behandle, før en netværkstråd stopper med at læse nye forespørgsler. | | host.name | nul | Brokers værtsnavn; Hvis værtsnavnet allerede er sat, vil mægleren kun være bundet til denne adresse; Hvis der ikke er nogen indstilling, vil den binde til alle interfaces og udgive én kopi til ZK | | advertised.host.name | nul | Hvis det er sat, sendes det til producenter, forbrugere og andre mæglere som mæglerens værtsnavn | | annonceret.port | nul | Denne port gives til producenter, forbrugere og andre mæglere og bruges til at etablere en forbindelse; Det skal kun sættes, hvis den faktiske port og den port, serveren skal binde, er forskellige. | | socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Cache-størrelse, som serveren bruger til at lave socket-forbindelser | | socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF cache-størrelse, som serveren bruger til at forbinde til sockets | | socket.request.max.bytes | 100 * 1024 * 1024 | Den maksimale anmodningsstørrelse, som serveren tillader; Dette vil undgå serveroverløb, som bør være mindre end Java-heapens størrelse | | num.partitioner | 1 | Hvis antallet af partitioner ikke er angivet, når et emne oprettes, vil dette tal være standardantallet af partitioner under emnet. | | log.segment.bytes | 1014*1024*1024 | Logs for emnepartitionen gemmes i mange filer i en bestemt mappe, som opdeler partitionens logfiler i segmenter; Denne attribut er den maksimale størrelse af hver fil; Når dimensionerne når denne værdi, oprettes en ny fil. Denne indstilling kan tilsidesættes af grunden for hvert emne.
Udsigt Hyperlink-login er synlig. | | log.roll.timer | 24 * 7 | Selv hvis filen ikke når log.segment.bytes, oprettes en ny fil, når filoprettelsestiden når denne egenskab. Denne indstilling kan også tilsidesættes af emneniveau-indstillinger;
UdsigtHyperlink-login er synlig. | | log.cleanup.policy | Slet | | | log.retention.minutes og log.retention.hours | 7 dage | Tiden hvor hver logfil blev gemt, før den blev slettet. Standard databesparende tid er den samme for alle emner.
log.retention.minutes og log.retention.bytes bruges begge til at sætte sletning af logfiler, uanset hvilken egenskab der er blevet overfyldt.
Denne egenskabsindstilling kan tilsidesættes, når emnet grundlæggende er sat.
UdsigtHyperlink-login er synlig. | | log.retention.bytes | -1 | Den samlede mængde data gemt af hver partition under hvert emne; Bemærk, at dette er den øvre grænse pr. partition, så dette tal ganget med antallet af partitioner er den samlede mængde data lagret pr. emne. Bemærk også: Hvis både log.retention.hours og log.retention.bytes sættes, vil overskridelse af nogen af grænserne medføre, at en segmentfil slettes.
Bemærk, at denne indstilling kan tilsidesættes af hvert emne.
UdsigtHyperlink-login er synlig. | | log.retention.check.interval.ms | 5 minutter | Tjek intervallet mellem logsegmenterede filer for at afgøre, om filattributterne opfylder sletningskravene. | | log.cleaner.enable | false | Når denne egenskab sættes til falsk, slettes den, når loggen er gemt i en maksimal tid eller størrelse. Hvis den sættes til sand, sker det, når gemmeattributten når den øvre grænseHyperlink-login er synlig.。 | | log.cleaner.threads | 1 | Antallet af tråde, der udfører log-komprimering | | log.cleaner.io.max.bytes.per.sekund | Ingen | Det maksimale antal I/O'er, som en logrenser kan have ved udførelse af en logkompaktering. Denne indstilling begrænser rengøringsfunktionen for at undgå at forstyrre aktive anmodningstjenester. | | log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indekserer logs under oprydningsprocessen og reducerer størrelsen af den anvendte cache. Det er bedst at sætte den stor for at give rigelig hukommelse. | | log.cleaner.io.buffer.load.factor | 512*1024 | Størrelsen på den I/O-klump, der kræves til tømmerrensning. Du behøver ikke ændre denne indstilling. | | log.cleaner.io.buffer.load.factor | 0.9 | belastningsfaktoren for hashtabellen, der bruges i logrensning; Du behøver ikke ændre denne mulighed. | | log.cleaner.backoff.ms | 15000 | Det tidsinterval, hvor loggen ryddes op, udføres | | log.cleaner.min.cleanable.ratio | 0.5 | Denne konfiguration styrer, hvor ofte logkompaktoren forsøger at rydde op i logstammerne (antagetHyperlink-login er synlig.er åben). Som standard bør du undgå at rense mere end 50% af stammerne. Dette forhold er knyttet til den maksimale plads, backuploggen bruger (50% af logs komprimeres ved 50%). En højere sats betyder mindre spild, og mere plads kan ryddes mere effektivt. Denne indstilling kan tilsidesættes i hver emneindstilling.
UdsigtHyperlink-login er synlig.。 | | log.cleaner.delete.retention.ms | 1 dag | opbevaringstid; Den maksimale tid til at opbevare komprimerede logfiler; Det er også den maksimale tid for klienten til at modtage beskeder, og forskellen mellem log.retention.minutes er, at den ene styrer de ukomprimerede data, og den anden kontrollerer de komprimerede data, som vil blive overskrevet inden det angivne tidspunkt, hvor emnet oprettes. | | log.index.size.max.bytes | 10*1024*1024 | Den maksimale størrelse pr. stammesegment. Bemærk, at hvis log-størrelsen når denne værdi, skal et nyt log-segment genereres, selvom størrelsen ikke overstiger log.segment.bytes-grænsen. | | log.index.interval.bytes | 4096 | Når du udfører en fetch, skal du scanne den nærmeste offset med en vis plads, jo større indstillingen er, desto bedre, brug generelt standardværdien | | log.flush.interval.messages | Long.MaxValue | Logfilen "synkroniserer" til disken, før den akkumulerer beskeder. Da disk-IO-operationer er langsomme, men også et nødvendigt middel til "datapålidelighed", skal man kontrollere, om tidsintervallet for at hærde til harddisken er nødvendigt. Hvis denne værdi er for stor, vil det føre til for lang en "synkroniserings"-tid (IO-blokering), hvis denne værdi er for lille, vil det føre til lang tid med "fsync" (IO-blokering), hvis denne værdi er for lille, vil det føre til et stort antal "synkroniserings"-tider, hvilket betyder, at den samlede klientanmodning har en vis forsinkelse, og fejlen af den fysiske server vil føre til tab af beskeder uden fsync. | | log.flush.scheduler.interval.ms | Long.MaxValue | Tjek om der kræves fsync-intervaller | | log.flush.interval.ms | Long.MaxValue | Dette tal bruges til at kontrollere tidsintervallet for "fsync"; hvis antallet af beskeder aldrig når det antal beskeder, der er fastgjort til disken, men tidsintervallet fra den sidste disksynkronisering når tærsklen, vil disksynkronisering også blive udløst. | | log.delete.delay.ms | 60000 | Opbevaringstiden efter filen er slettet i indekset behøver som regel ikke at blive ændret | | auto.create.topics.enable | true | Om man skal tillade automatisk oprettelse af emner. Hvis det er sandt, vil det automatisk oprette et emne, der ikke eksisterer, når produce eller fetch ikke eksisterer. Ellers skal du bruge kommandolinjen til at oprette et emne | | controller.socket.timeout.ms | 30000 | Timeout-tiden for socketen, når partitionstyringscontrolleren udfører en backup. | | controller.message.queue.size | Int.MaxValue | Controller-til-mægler-Channles | | default.replication.factor | 1 | Standardantallet af backupkopier refererer kun til automatisk oprettede emner | | replica.lag.time.max.ms | 10000 | Hvis en følger ikke sender en henteanmodning inden for denne tid, vil lederen fjerne følgeren fra ISR og betragte følgeren som hængt | | replica.lag.max.beskeder | 4000 | Hvis en replika har flere end dette antal ubackup, vil lederen fjerne følgeren og betragte følgeren som hængende | | replica.socket.timeout.ms | 30*1000 | Leder timeout-tid for socket-netværksanmodninger ved sikkerhedskopiering af data | | replica.socket.receive.buffer.bytes | 64*1024 | Socket modtagsbuffer, når en netværksforespørgsel sendes til lederen under backup | | replica.fetch.max.bytes | 1024*1024 | Den maksimale værdi af hver hent på backuptidspunktet | | replica.fetch.min.bytes | 500 | Den maksimale ventetid på, at data når lederen, når lederen laver en backup-anmodning | | replica.fetch.min.bytes | 1 | Den mindste størrelse af responsen efter hver hentning, når man bakker op | | num.replica.fetchers | 1 | Antallet af tråde, der sikkerhedskopierer data fra lederen | | replica.high.watermark.checkpoint.interval.ms | 5000 | Hver kopi tjekker, hvor ofte det højeste vandniveau hærdes | | fetch.purgatory.purge.interval.requests | 1000 | hent anmodning om rensningsintervallet | | producer.purgatory.purge.interval.requests | 1000 | producent anmoder om et purge-interval | | zookeeper.session.timeout.ms | 6000 | Timeout for dyrepassersessionen. | | zookeeper.connection.timeout.ms | 6000 | Den maksimale tid, klienten venter på at etablere forbindelse med dyrepasseren | | zookeeper.sync.time.ms | 2000 | ZK-følgeren halter bagefter ZK-leder i lang tid | | controlled.shutdown.enable | true | Om det er muligt at kontrollere mæglerens lukning. Hvis muligt, vil mægleren kunne flytte alle ledere til andre mæglere inden afslutningen. Dette reducerer utilgængelighed under nedlukningsprocessen. | | controlled.shutdown.max.forsøger igen | 3 | Antallet af kommandoer, der kan udføre en nedlukning med succes, før en ufuldstændig nedlukning udføres. | | controlled.shutdown.retry.backoff.ms | 5000 | Tilbageholdstid mellem nedlukninger | | auto.leader.rebalance.enable | true | Hvis dette er sandt, vil controlleren automatisk balancere mæglernes ledelse over partitionerne | | leder.ubalance.per.broker.percentage | 10 | Den maksimale ubalance, som hver mægler tillader | | leder.ubalance.check.interval.seconds | 300 | Tjek hyppigheden af lederubalance | | offset.metadata.max.bytes | 4096 | Tillader klienter at gemme det maksimale antal af deres offsets | | max.connections.per.ip | Int.MaxValue | Det maksimale antal forbindelser pr. mægler kan foretages til hver IP-adresse | | max.connections.per.ip.overrides | | Den maksimale dækning af standardforbindelsen pr. IP eller værtsnavn | | connections.max.idle.ms | 600000 | Timeout-grænse for tomme forbindelser | | log.roll.jitter. {ms,timer} | 0 | Det maksimale antal jitters abstraheret fra logRollTimeMillis | | num.recovery.threads.per.data.dir | 1 | Antallet af tråde, som hver datamappe bruger til at logge gendannelse | | uren.leder.valg.aktiver | true | Angiver om det er muligt at bruge ikke-replika-indstillingen i ISR som leder | | delete.topic.enable | false | Kan slette emner | | offsets.topic.num.partitions | 50 | Antallet af partitioner for offset-commit-emnet. Da det i øjeblikket ikke understøttes at ændre dette efter udrulning, anbefaler vi at bruge en højere indstilling til produktion (f.eks. 100-200). | | offsets.topic.retention.minutes | 1440 | Offsets, der har eksisteret længere end denne tidsgrænse, vil blive markeret som afventende sletning | | offsets.retention.check.interval.ms | 600000 | Offset-manageren kontrollerer hyppigheden af formodnede offsets | | offsets.topic.replication.factor | 3 | Antallet af backup-kopier af emnets offset. Det anbefales at sætte højere tal for at sikre højere tilgængelighed | | offset.topic.segment.bytes | 104857600 | Offsets emne. | | offsets.load.buffer.size | 5242880 | Denne indstilling er relateret til batchstørrelsen og bruges, når man læser fra offset-segmentet. | | offsets.commit.required.acks | -1 | Antallet af bekræftelser skal sættes, før offset-commit er acceptabelt, og behøver generelt ikke ændres |
| Ejendom | Standard | Serverstandardegenskab | Beskrivelse | | oprydningspolitik. | Slet | log.cleanup.policy | Enten "slette" eller "kompakt"; Denne streng angiver, hvordan man udnytter den gamle logstamme-del; Standardmetoden ("slet") kasserer den gamle del, når deres genbrugstid eller størrelsesgrænse nås. "kompakt" komprimerer logs | | delete.retention.ms | 864000000 (24 timer) | log.cleaner.delete.retention.ms | Forskellen mellem log.retention.minutes er, at den ene styrer ukomprimerede data, og den anden kontrollerer komprimerede data. Denne konfiguration kan overskrives af fastgørelsesparametrene, når emnet oprettes | | flush.messages | Ingen | log.flush.interval.messages | Denne konfiguration specificerer et tidsinterval for at tvinge fsync-logfiler. For eksempel, hvis denne mulighed er sat til 1, kræves fsync efter hver besked, og hvis den er sat til 5, kræves fsync for hver 5. besked. Generelt anbefales det, at du ikke sætter denne værdi. Indstillingen af denne parameter kræver den nødvendige afvejning mellem "datapålidelighed" og "ydeevne". Hvis denne værdi er for stor, vil det medføre lang tid til at "fsynce" hver gang (IO-blokering), og hvis denne værdi er for lille, vil det føre til et stort antal "fsync", hvilket også betyder, at der er en vis forsinkelse i den samlede klientforespørgsel. Fysisk serverfejl vil få beskeder til at gå tabt uden fsync. | | flush.ms | Ingen | log.flush.interval.ms | Denne konfiguration bruges til at fastholde tidsintervallet mellem at tvinge fsync-logs til disken; For eksempel, hvis den er sat til 1000, kræves fsync hver 1000 ms. Denne mulighed anbefales generelt ikke | | index.interval.bytes | 4096 | log.index.interval.bytes | Standardindstillingen sikrer, at vi tilføjer et indeks til beskeden for hver 4096 bytes, og flere indekser gør læsebeskeden tættere på, men indeksstørrelsen øges. Denne mulighed er generelt ikke nødvendig | | max.message.bytes | 1000000 | max.message.bytes | Den maksimale størrelse af kafka-tilføjelsesbeskeden. Bemærk, at hvis du øger denne størrelse, skal du også øge hentestørrelsen på din forbruger, så forbrugeren kan hente beskeder til de maksimale størrelser. | | min.rengørlig.beskidt.ratio | 0.5 | min.rengørlig.beskidt.ratio | Denne konfiguration styrer, hvor ofte log-kompressoren forsøger at rense logs. Som standard undgås logfiler med en komprimeringsrate på over 50%. Dette forhold undgår det største pladsspild | | min.insync.replicas | 1 | min.insync.replicas | Når produceren sættes til request.required.acks til -1, specificerer min.insync.replicas det minimale antal replikaer (hver repica-skrivning skal være succesfuld), og hvis dette tal ikke nås, vil produceren producere en undtagelse. | | retention.bytes | Ingen | log.retention.bytes | Hvis du bruger "delete"-opbevaringspolitikken, refererer denne konfiguration til den maksimale størrelse, loggen kan opnå, før den slettes. Som standard er der ingen størrelsesbegrænsning, kun en tidsbegrænsning | | retention.ms | 7 dage | log.retention.minutes | Hvis du bruger "delete"-opbevaringspolitikken, refererer denne konfiguration til det tidspunkt, hvor loggen blev gemt før sletteningsloggen. | | segment.bytes | 1GB | log.segment.bytes | I Kafka gemmes logstammer i chunks, og denne konfiguration refererer til størrelsen af loglogs opdelt i chunks | | segment.index.bytes | 10MB | log.index.size.max.bytes | Denne konfiguration svarer til størrelsen af indeksfilen, der er kortlagt mellem offsets og filplaceringer; Denne konfiguration behøver generelt ikke at blive ændret | | segment.ms | 7 dage | log.roll.timer | Selv hvis log chunk-filen ikke når den størrelse, der skal slettes eller komprimeres, vil en ny log chunk-fil blive tvunget til at blive tvunget til at udføre en ny log chunk-fil, når log-tiden når denne øvre grænse. | | segment.jitter.ms | 0 | log.roll.jitter. {ms,timer} | Den maksimale jitter skal trækkes fra logRollTimeMillis. |
Forbrugerkonfigurationer
| Ejendom | Standard | Beskrivelse | | group.id | | En streng, der entydigt identificerer gruppen, hvor forbrugerprocessen er placeret, og hvis det samme gruppe-ID sættes, betyder det, at disse processer tilhører den samme forbrugergruppe | | zookeeper.connect | | Angiv strengen for Zookeeper-forbindelsen, formatet er hostname:port, her er værten og porten både vært og port for Zookeeper-serveren. For at undgå at miste kontakten efter en Zookeeper-maskine går ned, kan du angive flere hostname:ports ved at bruge kommaer som separation:
værtsnavn1:port1,værtsnavn2:port2,værtsnavn3:port3:port3
Du kan tilføje ZooKeepers chroot-sti til ZooKeeper-forbindelsesstrengen, som bruges til at gemme sine egne data, på følgende måde:
værtsnavn1:port1,værtsnavn2:port2,værtsnavn3:port3/chroot/sti | | consumer.id | nul | Der kræves ingen opsætning, og den genereres generelt automatisk | | socket.timeout.ms | 30*100 | Timeout-grænser for netværksforespørgsler. Den sande timeout-grænse er max.fetch.wait+socket.timeout.ms | | socket.receive.buffer.bytes | 64*1024 | socket bruges til at modtage cache-størrelsen af netværksforespørgsler | | fetch.message.max.bytes | 1024*1024 | Det maksimale antal bytes pr. hentebesked pr. henteanmodning. Disse bytes vil blive overvåget i den hukommelse, der bruges for hver partition, så denne indstilling vil styre, hvor meget hukommelse forbrugeren bruger. Fetch-anmodningsstørrelsen skal mindst svare til den maksimale beskedstørrelse, som serveren tillader, ellers er størrelsen på den besked, producenten kan sende, større end den størrelse, forbrugeren kan forbruge. | | num.forbruger.hentere | 1 | Antallet af hentertråde, der bruges til hentedata | | auto.commit.enable | true | Hvis det er sandt, vil offsetet af den besked, som forbrugeren henter, automatisk blive synkroniseret med zookeeperen. Denne commit-offset vil blive brugt af den nye forbruger, når processen går i stå | | auto.commit.interval.ms | 60*1000 | Den frekvens, hvormed forbrugeren indsender offset til dyrepasseren, er i sekunder | | queued.max.message.chunks | 2 | Det maksimale antal beskeder, der bruges til at cache til forbrug. Hver chunk skal være den samme som fetch.message.max.bytes | | rebalance.max. forsøg | 4 | Når en ny forbruger tilføjes til en forbrugergruppe, forsøger samlingen af forbrugere at ombalancere antallet af partitioner, der tildeles hver forbruger. Hvis forbrugerens samling ændres, fejler denne rebalancering og genentrifikeres, når allokeringen udføres | | fetch.min.bytes | 1 | Det minimale antal bytes, som serveren skal returnere ved hver henteanmodning. Hvis der ikke returneres nok data, venter anmodningen, indtil der er returneret nok data. | | fetch.wait.max.ms | 100 | Hvis der ikke er nok data til at opfylde fetch.min.bytes, refererer denne konfiguration til den maksimale tid, serveren vil blokere, før den svarer på en fetch-anmodning. | | rebalance.backoff.ms | 2000 | Tid til at slapme af, før jeg prøver reblance igen | | refresh.leader.backoff.ms | 200 | Der er tid til at vente tilbage, før man prøver at afgøre, om en delings leder har mistet sin ledelse | | auto.offset.reset | Størst | Hvis der ikke er nogen initialiseret offset i zookeeper, hvis offset er et svar på følgende værdi:
mindst: Auto-nulstilling offset til mindste offset
størst: Auto-nulstilling offset til offset af største
Alt andet: Giver forbrugeren en undtagelse | | consumer.timeout.ms | -1 | Hvis der ikke er nogen besked tilgængelig, selv efter ventetid i en bestemt tid, kastes en timeout-undtagelse | | exlude.internal.topics | true | Om man skal eksponere beskeder fra interne emner til forbrugerne | | parition.assignment.strategy | Udbredelse | Vælg politikken for tildeling af partitioner til forbrugerflowet, eventuelt interval, roundrobin | | client.id | Gruppe-ID-værdi | er en brugerspecifik streng, der hjælper med at spore kald i hver forespørgsel. Den bør logisk bekræfte applikationen, der genererede anmodningen | | zookeeper.session.timeout.ms | 6000 | Timeout-grænser for zookeeper-sessioner. Hvis forbrugeren ikke sender en hjerteslagsbesked til dyrepasseren i denne periode, betragtes den som hængt op, og der vil blive genereret en reblance | | zookeeper.connection.timeout.ms | 6000 | Den maksimale ventetid for en klient til at etablere en Zookeeper-forbindelse | | zookeeper.sync.time.ms | 2000 | ZK-følgere kan halte efter ZK-lederen i maksimal tid | | offsets.storage | Dyrepasser | Steder, der bruges til at opbevare offsets: dyrepasser eller kafka | | offset.channel.backoff.ms | 1000 | Backoff-tiden for at genoprette forbindelsen til offset-kanalen eller genprøve fetch/commit-anmodningen af den fejlede offset | | offsets.channel.socket.timeout.ms | 10000 | Socket-timeout-grænsen for svaret på fetch/commit-anmodningen ved læseoffset. Denne timeout-begrænsning bruges af consumerMetadata-anmodningen til at anmode om offset-administration | | offsets.commit.max. prøver igen | 5 | Antallet af gange offset-commit blev prøvet igen. Dette forsøg anvendes kun på offset-commits mellem nedlukninger. ham | | dual.commit.enabled | true | Hvis du bruger "kafka" som offsets.storage, kan du committe offset til zookeeper to gange (og én gang til kafka). Dette er et must, når man migrerer fra zookeeper-baseret offset-lagring til kafka-baseret offset-lagring. For enhver given forbrugergruppe er det en sikker anbefaling at slå denne mulighed fra, når migreringen er fuldført | | partition.assignment.strategy | Udbredelse | Vælg mellem "range"- og "roundrobin"-politikkerne som politik for tildeling af partitioner til forbrugerdataflows; Den cirkulære partitionsallokator tildeler alle tilgængelige partitioner samt alle tilgængelige forbrugertråde. Den vil tildele partitionsløjfen til forbrugertråden. Hvis alle forbrugerinstanser abonneres på en determineret, opdeles partitionerne i deterministiske fordelinger. Round-robin allokeringsstrategien er kun mulig, hvis følgende betingelser er opfyldt: (1) Hvert emne har det samme antal datastrømme pr. forbrugerstyrke. (2) Samlingen af abonnerede emner bestemmes for hver forbrugerinstans i forbrugergruppen. |
Producer-konfigurationer
| Ejendom | Standard | Beskrivelse | | metadata.broker.list | | Tjen bootstrapping. producer bruges kun til at hente metadata (emner, partitioner, replikaer). Socket-forbindelsen til at sende de faktiske data vil blive etableret baseret på de returnerede metadata. Formatet er:
vært1:port1,vært2:port2
Denne liste kan være en underliste over mæglere eller en VIP, der peger på mæglere | | anmodning.påkrævet.acks | 0 | Denne konfiguration er en kvitteringsværdi, der angiver, hvornår en produktionsanmodning anses for at være fuldført. Især hvor mange andre mæglere må have indsendt data til deres logfiler og bekræftet disse oplysninger over for deres leder. Typiske værdier inkluderer:
0: Indikerer, at producenten aldrig venter på bekræftelse fra mægleren (samme adfærd som 0,7). Denne mulighed giver mindst latenstid, men samtidig den største risiko (fordi data går tabt, når serveren går ned).
1: Angiver at lederreplikaen har modtaget databekræftelsen. Denne mulighed har lav latenstid og sikrer, at serveren bekræfter, at den er modtaget.
-1: Producenten får bekræftet, at alle synkroniserede replikaer har modtaget data. Latenstiden er den største, men denne metode eliminerer ikke fuldstændigt risikoen for tabte beskeder, fordi antallet af synkroniserede replikaer kan være 1. Hvis du vil sikre, at nogle replikaer modtager data, bør du sætte indstillingen min.insync.replicas i emneniveau-indstillingerne. Læs designdokumentationen for en mere dybdegående diskussion. | | request.timeout.ms | 10000 | Mægleren gør sit bedste for at implementere request.required.acks-kravet, ellers vil der blive sendt en fejl til klienten | | producer.type | Synkronisering | Denne mulighed fastgør, om beskeden sendes asynkront i en baggrundstråd. Korrekte værdier:
(1) asynkron: Asynkron afsendelse
(2) synkronisering: Synkroniseret afsendelse
Ved at sætte produceren til asynkron kan vi behandle forespørgsler i batches (hvilket er godt for højere gennemstrømning), men det skaber også mulighed for, at klientmaskinen mister usente data | | serializer.class | kafka.serializer.DefaultEncoder | Serialiseringskategorien af beskeden. Standardkoderen indtaster én byte[] og returnerer den samme byte[] | | key.serializer.class | | Serialiseringsklasse for nøgleord. Hvis dette ikke er angivet, er standarden at matche beskeden | | partitioner.class | kafka.producer.DefaultPartitioner | partitioner-klasse til at opdele beskeder mellem underemner. Standardpartitioneren er baseret på nøglens hashtabel | | compression.codec | ingen | Denne parameter kan indstille codec'en til datakomprimering, som kan vælges som "ingen", "gzip", "snappy". | | komprimerede.emner | nul | Denne parameter kan bruges til at bestemme, om visse emner er komprimerede. Hvis den komprimerede codec er en anden codec end NoCompressCodec, anvendes disse codecs på de specificerede emnedata. Hvis listen over komprimerede emner er tom, skal den specifikke komprimerede codec anvendes på alle emner. Hvis den komprimerede codec er NoCompressionCodec, er komprimeringen ikke tilgængelig for alle emner. | | message.send.max. forsøg igen | 3 | Denne parameter får producenten til automatisk at forsøge fejlede send-forespørgsler igen. Denne parameter fastsætter antallet af gentagelser. Bemærk: Hvis du sætter en ikke-0 værdi, gentager visse netværksfejl: forårsager en send og tab af bekræftelse | | retry.backoff.ms | 100 | Før hver genforsøg opdaterer producenten metadata for det relevante emne for at se, om den nye leder er tildelt. Da ledervalget tager lidt tid, specificerer denne mulighed, hvor længe producenten skal vente, før metadataene kan opdateres. | | topic.metadata.refresh.interval.ms | 600*1000 | Producenten opdaterer generelt emnets metadata i nogle fejlscenarier (partition mangler, leder utilgængelig osv.). Han vil gennemgå en almindelig cyklus. Hvis du sætter den til en negativ værdi, vil metadataene kun blive opdateret, hvis den fejler. Hvis den sættes til 0, opdateres metadataene efter hver sendt besked (denne mulighed anbefales ikke, da systemet bruger for meget). Vigtigt: Opdateringer sker først efter beskeden er sendt, så hvis producenten aldrig sender beskeden, opdateres metadataene aldrig. | | queue.buffering.max.ms | 5000 | Det maksimale tidsinterval, hvor brugeren cacher data, når asynkron tilstand anvendes. For eksempel, hvis beskeden er sat til 100, vil beskeder inden for 100 ms blive behandlet i batcher. Dette vil forbedre gennemstrømningen, men øge latenstiden på grund af caching. | | queue.buffering.max.beskeder | 10000 | Når man bruger asynkron tilstand, skal det maksimale antal ikke-sendte beskeder, der kan caches i køen, før producenten blokeres, eller data skal gå tabt | | batch.num.messages | 200 | Når du bruger asynkron tilstand, kan du batchbehandle det maksimale antal beskeder. Eller antallet af beskeder er nået online, eller queue.buffer.max.ms er ankommet, og producenten vil behandle det | | send.buffer.bytes | 100*1024 | Socket write cache-størrelse | | client.id | “” | Dette klient-id er en brugerspecifik streng, der inkluderes i hver forespørgsel for at spore opkaldet, og han burde logisk kunne bekræfte, at applikationen har lavet anmodningen. |
Producer-konfigurationer
| Navn | Type | Standard | Betydning | Beskrivelse | | boostrap.servers | Liste | | højt | Vært/port-gruppe for at etablere en forbindelse til kafka-klyngen. Data vil blive indlæst jævnt på alle servere, uanset hvilken server der er udpeget til bootstrapping. Denne liste påvirker kun de initialiserede værter (som bruges til at opdage alle servere). Dette listeformat:
host1:port1,host2:port2,...
Da disse servere kun bruges til at initialisere forbindelser for at opdage alle klyngens medlemskaber (som kan ændre sig dynamisk), behøver denne liste ikke indeholde alle servere (du kan ønske mere end én server, selvom én server i dette tilfælde kan være nede). Hvis ingen server optræder i denne liste, vil forsendelsesdata fejle, indtil listen er tilgængelig. | | AKKS | Streng | 1 | højt | Producenten har brug for et signal fra serveren for at bekræfte modtagelsen efter at have modtaget dataene, og denne konfiguration refererer til, hvor mange sådanne bekræftelsessignaler procuderen har brug for. Denne konfiguration repræsenterer faktisk tilgængeligheden af databackups. Følgende indstillinger er almindelige muligheder:
(1) acks=0: Sat til 0 betyder, at producenten ikke behøver at vente på nogen bekræftelse af den modtagne information. Replikaen vil straks blive tilføjet til socket-bufferen og betragtet som sendt. Der er ingen garanti for, at serveren har modtaget dataene i dette tilfælde, og genprøven af konfigurationen vil ikke virke (fordi klienten ikke ved, om den fejlede), og offsetet af feedbacken vil altid være sat til -1.
(2) acks=1: Det betyder, at man i det mindste skal vente på, at lederen har skrevet dataene til den lokale log, men ikke på at alle følgere skriver succesfuldt. I dette tilfælde, hvis følgeren ikke får taget backup af dataene og lederen lægger på igen, vil beskeden gå tabt.
(3) acks=alle: Det betyder, at lederen skal vente på, at alle backups skriver logs med succes, og denne strategi sikrer, at data ikke går tabt, så længe én backup overlever. Dette er den stærkeste garanti.
(4) Andre indstillinger, såsom acks=2, er også mulige, hvilket kræver et givet antal acks, men denne strategi bruges generelt sjældent. | | buffer.memory | Lang | 33554432 | højt | Produceren kan bruges til at cache dataens hukommelsesstørrelse. Hvis dataene genereres hurtigere, end de sendes til mægleren, vil producenten blokere eller kaste en undtagelse, angivet med "block.on.buffer.full".
Denne indstilling vil være relateret til den samlede hukommelse, som producenten kan bruge, men det er ikke en hård grænse, da ikke al hukommelse, produceren bruger, bruges til caching. Noget ekstra hukommelse bruges til komprimering (hvis komprimering introduceres), og noget bruges til vedligeholdelsesanmodninger. | | compression.type | Streng | ingen | højt | Producer er den type komprimering, der bruges til at komprimere data. Standardindstillingen er ukomprimeret. De korrekte optionsværdier er ingen, gzip, snappy.
Komprimering er bedst egnet til batchbehandling; jo flere beskeder der behandles i batcher, desto bedre er komprimeringsydelsen. | | Forsøg igen | int | 0 | højt | Hvis man sætter en værdi større end 0, vil klienten sende alle data igen, når dataene fejler. Bemærk, at disse genforsøg ikke adskiller sig fra dem, når klienten modtager en send-fejl. Tillader gentagne forsøg på potentielt at ændre rækkefølgen af dataene; hvis begge beskedposter sendes til samme partition, fejler den første besked, og den anden besked vises tidligere end den første besked. | | batch.size | int | 16384 | Medium | Producenten vil forsøge at batche beskedposterne for at reducere antallet af forespørgsler. Dette vil forbedre ydeevnen mellem klient og server. Denne konfiguration styrer standardantallet af bytes for batchbehandlingsmeddelelser.
Der gøres ingen forsøg på at behandle beskedbytes større end dette byteantal.
Anmodninger sendt til mæglere vil indeholde flere batches, som vil indeholde én anmodning for hver partition.
Mindre batchværdier bruges mindre og kan reducere gennemstrømningen (0 vil kun bruge batchbehandling). Større batchværdier spilder mere hukommelsesplads, så du skal allokere hukommelse til specifikke batchværdier. | | client.id | Streng | | Medium | Denne streng sendes til serveren, når der foretages en anmodning. Formålet er at kunne spore kilden til anmodninger, så nogle applikationer uden for IP/Port-tillodslisten kan sende information. Denne app kan sætte enhver streng, fordi den ikke har andet funktionelt formål end at optage og spore | | linger.ms | Lang | 0 | Medium | Producergruppen samler alle beskeder, der ankommer mellem anmodningen og afsendelsen, og registrerer en separat batch af anmodninger. Typisk sker dette kun, når posten genereres hurtigere end afsendelseshastigheden. Men under visse betingelser vil klienten ønske at reducere antallet af forespørgsler eller endda til en moderat belastning. Denne opsætning sker ved at tilføje en lille forsinkelse – dvs. i stedet for at sende en post med det samme, vil producenten vente i en given forsinkelsestid for at tillade andre beskedposter at blive sendt, som kan batches. Dette kan betragtes som en lignende algoritme som TCP Nagle. Denne indstilling sætter en højere latenstid for batching: når vi har fået batch.size for en partition, sender den den straks uanset denne indstilling, men hvis vi får en besked med et meget mindre byteantal end denne indstilling, skal vi "dvæle" et bestemt tidspunkt for at modtage flere beskeder. Denne indstilling er som standard 0, dvs. ingen forsinkelse. At sætte linger.ms=5 vil for eksempel reducere antallet af forespørgsler, men samtidig øge forsinkelsen med 5 ms. | | max.request.size | int | 1028576 | Medium | Det maksimale antal bytes, der anmodes. Dette er også en effektiv dækning for den maksimale registrerede størrelse. Bemærk: Serveren har sin egen overstyring af beskedpoststørrelser, som adskiller sig fra denne indstilling. Denne indstilling begrænser antallet af forespørgsler, som producenter kan sende i bulk ad gangen for at forhindre et stort antal forespørgsler. | | receive.buffer.bytes | int | 32768 | Medium | TCP modtagercache-størrelse, som bruges ved læsning af data | | send.buffer.bytes | int | 131072 | Medium | TCP send cache-størrelse, som bruges ved dataoverførsel | | timeout.ms | int | 30000 | Medium | Denne konfigurationsmulighed styrer den maksimale tid, serveren venter på bekræftelse fra følgere. Hvis antallet af bekræftede anmodninger ikke er opfyldt inden for denne tid, returneres en fejl. Denne timeout-grænse måles på serversiden og har ingen netværkslatens inklusive anmodninger | | blok.på.buffer.fuld | Boolesk | true | lavt | Når vores hukommelsescache løber tør, skal vi stoppe med at modtage nye beskedposter eller give fejl. Som standard er dette sat til sand, men noget blokering er måske ikke værd at forvente, så det er bedre at give en fejl med det samme. Dette er tilfældet, når det sættes til false: produceren kaster en undtagelsesfejl: BufferExhaustedException, hvis posten er sendt, og cachen er fuld | | metadata.fetch.timeout.ms | Lang | 60000 | lavt | Det henviser til de første tidsdata for nogle elementer, vi har opnået. Elementer inkluderer: emne, vært, partitioner. Denne konfiguration refererer til den tid, det tager for elementet at fuldføre succesfuldt ifølge hentningen, ellers vil der blive sendt en undtagelse til klienten. | | metadata.max.age.ms | Lang | 300000 | lavt | Tid i mikrosekunder er det interval, hvor vi tvinger metadata til at blive opdateret. Selv hvis vi ikke ser nogen ændringer i delingsledelsen. | | metric.reporters | Liste | [] | lavt | En liste over klasser, der bruges til at måle målinger. Implementeringen af MetricReporter-grænsefladen vil muliggøre tilføjelse af klasser, der ændres, efterhånden som nye metrikker genereres. JmxReporter vil altid inkludere en måde at registrere JMX-statistikker på | | metrics.num.samples | int | 2 | lavt | Antallet af prøver, der bruges til at vedligeholde målinger | | metrics.sample.window.ms | Lang | 30000 | lavt | Metrics-systemet opretholder et konfigurerbart antal prøver i en korrigerbar vinduesstørrelse. Denne konfiguration konfigurerer for eksempel vinduesstørrelsen. Vi kan opbevare to prøver i 30 sekunder. Når et vindue rulles ud, sletter og omskriver vi det ældste vindue | | recoonect.backoff.ms | Lang | 10 | lavt | Når forbindelsen afbrydes, ventetiden når vi genopretter forbindelsen. Dette undgår gentagne klientforbindelser | | retry.backoff.ms | Lang | 100 | lavt | Ventetiden før man prøver at prøve igen en mislykket anmodning om frugt og grønt. Undgå at sidde fast i en send-fail dead loop.
|
|
Opslået på 24/06/2021 11.47.12
|
|
|
Udlejer