| Egendom | Standard | Beskrivning |
| broker.id | | Varje mäklare kan identifieras med ett unikt icke-negativt heltals-ID; Detta id kan användas som "namn" på mäklaren, och dess existens gör att mäklaren kan migrera till en annan värd/port utan att förvirra konsumenterna. Du kan välja vilket nummer du vill som ID, så länge ID:t är unikt. |
| log.dirs | /tmp/kafka-logs | Vägen där Kafka lagrar data. Denna väg är inte unik, den kan vara multipla, och vägarna behöver bara separeras med kommatecken; När en ny partition skapas väljs den att göra det under den väg som innehåller minst antal partitioner. |
| Portering | 6667 | Servern accepterar porten som klienten ansluter till |
| zookeeper.connect | noll | Formatet för ZooKeeper-anslutningssträngen är: hostname:port, där värdnamn och port är värd respektive port för en nod i ZooKeeper-klustret. För att ansluta till andra ZooKeeper-noder när en värd går ner kan du skapa flera värdar enligt följande:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper låter dig lägga till en "chroot"-sökväg för att lagra all kafka-data i klustret under en specifik väg. När flera Kafka-kluster eller andra applikationer använder samma ZooKeeper-kluster kan du använda denna metod för att ställa in datalagringsvägen. Detta kan implementeras genom att formatera anslutningssträngen så här:
värdnamn1:port1,värdnamn2:port2,värdnamn3:port3/chroot/path
Denna setup lagrar all kafka-klusterdata under /chroot/path-vägen. Observera att innan du startar mäklaren måste du skapa denna ruta, och konsumenter måste använda samma anslutningsformat. |
| message.max.bytes | 1000000 | Den maximala storleken på meddelanden som en server kan ta emot. Det är viktigt att konsumentens och producentens inställningar kring denna egendom synkroniseras, annars blir det budskap som producenten publicerar för stort för konsumenten. |
| num.network.threads | 3 | Antalet nätverkstrådar som servern använder för att behandla nätverksförfrågningar; Du behöver i allmänhet inte ändra denna egendom. |
| num.io.threads | 8 | Antalet I/O-trådar som servern använder för att behandla förfrågningar; Antalet trådar bör vara minst lika med antalet hårddiskar. |
| bakgrund.trådar | 4 | Antalet trådar som används för bakgrundsbehandling, såsom filradering; Du behöver inte ändra denna egendom. |
| queued.max.önskemål | 500 | Det maximala antalet förfrågningar som kan köas för en I/O-tråd att behandla innan en nätverkstråd slutar läsa nya förfrågningar. |
| host.name | noll | Mäklarens värdnamn; Om värdnamnet redan är satt kommer mäklaren endast att bindas till denna adress; Om det inte finns någon inställning binder den till alla gränssnitt och publicerar en kopia till ZK |
| advertised.host.name | noll | Om det är satt skickas det till producenter, konsumenter och andra mäklare som mäklarens värdnamn |
| advertised.port | noll | Denna port ges till producenter, konsumenter och andra mäklare, och används för att etablera en förbindelse; Det behöver bara ställas in om den faktiska porten och den port som servern behöver binda är olika. |
| socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Cachestorlek, som servern använder för att skapa socketanslutningar |
| socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF cachestorlek, som servern använder för att ansluta till sockets |
| socket.request.max.bytes | 100 * 1024 * 1024 | Den maximala begäransökningsstorleken som servern tillåter; Detta undviker serveröverflöden, som bör vara mindre än Java-heapens storlek |
| num.partitioner | 1 | Om antalet partitioner inte anges vid skapandet av ett ämne, kommer detta antal att vara standardantalet partitioner under ämnet. |
| log.segment.bytes | 1014*1024*1024 | Loggarna för ämnespartitionen lagras i många filer i en viss katalog, som delar upp loggarna för partitionen i segment; Detta attribut är den maximala storleken på varje fil; När dimensionerna når detta värde skapas en ny fil. Denna inställning kan åsidosättas av grunden för varje ämne.
Vy Inloggningen med hyperlänken är synlig. |
| logg.rull.timmar | 24 * 7 | Även om filen inte når log.segment.bytes skapas en ny fil när filskapandetiden når denna egenskap. Denna inställning kan också åsidosättas av ämnesnivå-inställningar;
UtsiktInloggningen med hyperlänken är synlig. |
| logg.cleanup.policy | Ta bort | |
| logg.retention.minutes och log.retention.hours | 7 dagar | Tiden varje loggfil sparades innan den raderades. Standarddatasparande tid är densamma för alla ämnen.
log.retention.minutes och log.retention.bytes används båda för att ställa in radering av loggfiler, oavsett vilken egenskap som har överflödats.
Denna egenskapsinställning kan åsidosättas när ämnet i princip är satt.
UtsiktInloggningen med hyperlänken är synlig. |
| log.retention.bytes | -1 | Den totala mängden data som sparas av varje partition under varje ämne; Observera att detta är den övre gränsen per partition, så detta tal multiplicerat med antalet partitioner är den totala mängden data lagrad per ämne. Observera också: Om både log.retention.hours och log.retention.bytes är satta, kommer överskridande av någon av gränserna att en segmentfil tas bort.
Observera att denna inställning kan åsidosättas av varje ämne.
UtsiktInloggningen med hyperlänken är synlig. |
| log.retention.check.interval.ms | 5 minuter | Kontrollera intervallet mellan loggsegmenterade filer för att avgöra om filattributen uppfyller raderingskraven. |
| log.cleaner.enable | false | När denna egenskap sätts till false kommer den att raderas när loggen har lagrats för maximal tid eller storlek. Om det sätts till true sker det när sparattributet når den övre gränsenInloggningen med hyperlänken är synlig.。 |
| log.cleaner.threads | 1 | Antalet trådar som utför log-komprimering |
| log.cleaner.io.max.bytes.per.sekund | Ingen | Det maximala antalet I/O:er som en loggrensare kan ha vid en loggkomprimering. Denna inställning begränsar rengöringen för att undvika att störa aktiva förfrågningstjänster. |
| log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indexerar loggar under saneringsprocessen och minskar storleken på cachen som används. Det är bäst att ställa in den stor för att ge gott om minne. |
| log.cleaner.io.buffer.load.factor | 512*1024 | Storleken på I/O-biten som krävs för stockrengöring. Du behöver inte ändra denna inställning. |
| log.cleaner.io.buffer.load.factor | 0.9 | lastfaktorn för hashtabellen som används vid logrensning; Du behöver inte ändra detta alternativ. |
| log.cleaner.backoff.ms | 15000 | Tidsintervallet då loggen rensas utförs |
| Log.cleaner.min.cleanable.ratio | 0.5 | Denna konfiguration styr hur ofta stockkomprimatorn försöker rensa upp loggarna (antasInloggningen med hyperlänken är synlig.är öppen). Som standard, undvik att rengöra mer än 50 % av stockarna. Denna kvot är kopplad till det maximala utrymme som förbrukas av backuploggen (50 % av loggarna komprimeras vid 50 %). En högre avgift innebär mindre avfall och mer utrymme kan rensas mer effektivt. Denna inställning kan åsidosättas i varje ämnesinställning.
UtsiktInloggningen med hyperlänken är synlig.。 |
| log.cleaner.delete.retention.ms | 1 dag | lagringstid; Maximal tid för att föra komprimerade loggar; Det är också den maximala tiden för klienten att konsumera meddelanden, och skillnaden mellan log.retention.minutes är att den ena kontrollerar den okomprimerade datan och den andra kontrollerar den komprimerade datan, som kommer att skrivas över vid den angivna tiden då ämnet skapas. |
| log.index.size.max.bytes | 10*1024*1024 | Maximal storlek per stocksegment. Observera att om logstorleken når detta värde måste ett nytt logsegment genereras även om storleken inte överskrider gränsen för log.segment.bytes. |
| log.index.interval.bytes | 4096 | När du utför en fetch behöver du skanna närmaste offset med en viss mängd utrymme, ju större inställning desto bättre, använd vanligtvis standardvärdet |
| log.flush.interval.messages | Long.MaxValue | Loggfilen "synkar" till disken innan meddelanden samlas. Eftersom disk-IO-operationer är en långsam operation, men också ett nödvändigt medel för "datatillförlitlighet", kontrollera om tidsintervallet för att härda hårddisken är lämpligt. Om detta värde är för högt leder det till för lång "synkroniserings"-tid (IO-blockering), om detta värde är för litet leder det till lång tid av "fsync" (IO-blockering), om detta värde är för litet leder det till ett stort antal "synkroniserings"-tider, vilket innebär att den övergripande klientförfrågan har en viss fördröjning, och fel på den fysiska servern leder till förlust av meddelanden utan fsync. |
| log.flush.scheduler.interval.ms | Long.MaxValue | Kontrollera om fsync-intervaller krävs |
| log.flush.interval.ms | Long.MaxValue | Detta tal används för att styra tidsintervallet för "fsync", om antalet meddelanden aldrig når antalet meddelanden som är fastbundna på disken, men tidsintervallet från den senaste disksynkroniseringen når tröskeln, utlöses även disksynkroniseringen. |
| log.delete.delay.ms | 60000 | Förvaringstiden efter att filen rensats i indexet behöver i allmänhet inte ändras |
| auto.create.topics.enable | true | Om man ska tillåta automatisk skapande av ämnen. Om det stämmer kommer det automatiskt att skapa ett ämne som inte existerar när produce eller fetch inte existerar. Annars behöver du använda kommandoraden för att skapa ett ämne |
| controller.socket.timeout.ms | 30000 | Tiden för socketen när partitionhanteringskontrollern gör en backup. |
| controller.message.queue.size | Int.MaxValue | Controller-till-mäklare-channles |
| default.replication.factor | 1 | Standardantalet säkerhetskopieringskopior avser endast automatiskt skapade ämnen |
| replica.lag.time.max.ms | 10000 | Om en följare inte skickar en hämtaförfrågan inom denna tid, kommer ledaren att ta bort följaren från ISR igen och betrakta följaren som hängd |
| replica.lag.max.messages | 4000 | Om en replika har fler än detta antal obackade kommer ledaren att ta bort följaren och betrakta följaren som hängd |
| replica.socket.timeout.ms | 30*1000 | ledartider för socket-nätverksförfrågningar vid säkerhetskopiering av data |
| replica.socket.receive.buffer.bytes | 64*1024 | Socket receive buffer när en nätverksförfrågan skickas till ledaren under säkerhetskopiering |
| replica.fetch.max.bytes | 1024*1024 | Maxvärdet för varje hämtning vid säkerhetskopieringstillfället |
| replica.fetch.min.bytes | 500 | Maximal väntetid för att data ska nå ledaren när ledaren gör en reservförfrågan |
| replica.fetch.min.bytes | 1 | Den minsta storleken på svaret efter varje hämtning när man backar |
| num.replica.fetchers | 1 | Antalet trådar som säkerhetskopierar data från ledaren |
| replica.high.watermark.checkpoint.interval.ms | 5000 | Varje replika kontrollerar hur ofta den högsta vattennivån härdas |
| fetch.purgatory.purge.interval.requests | 1000 | hämta begäran om rensningsintervallet |
| producer.purgatory.purge.interval.requests | 1000 | producenten begär ett rensningsintervall |
| zookeeper.session.timeout.ms | 6000 | Timeout för djurskötarpasset. |
| zookeeper.connection.timeout.ms | 6000 | Den maximala tiden klienten väntar på att etablera en kontakt med djurskötaren |
| zookeeper.sync.time.ms | 2000 | ZK-följaren ligger efter ZK-ledaren under lång tid |
| controlled.shutdown.enable | true | Om det är möjligt att kontrollera nedläggningen av mäklaren. Om möjligt kan mäklaren flytta alla ledare till andra mäklare innan avslut. Detta minskar otillgängligheten under avstängningsprocessen. |
| controlled.shutdown.max.omprövningar | 3 | Antalet kommandon som kan utföra en avstängning innan en ofullständig avstängning utförs. |
| controlled.shutdown.retry.backoff.ms | 5000 | Tillbakagång mellan nedstängningar |
| auto.leader.rebalance.enable | true | Om detta stämmer kommer kontrollanten automatiskt att balansera mäklarens ledarskap över partitionerna |
| ledare.obalans.per.mäklare.procent | 10 | Den maximala obalanskvoten som varje mäklare tillåter |
| ledare.obalans.check.interval.seconds | 300 | Kontrollera frekvensen av ledarobalans |
| offset.metadata.max.bytes | 4096 | Tillåter klienter att spara maximalt antal av sina offsets |
| max.connections.per.ip | Int.MaxValue | Det maximala antalet anslutningar per mäklare kan göras till varje IP-adress |
| max.connections.per.ip.overrides | | Maximal täckning av standardanslutningen per IP eller värdnamn |
| connections.max.idle.ms | 600000 | Tidsgräns för tomma anslutningar |
| logg.rulla.jitter. {ms,hours} | 0 | Det maximala antalet ryckningar abstraherat från logRollTimeMillis |
| num.recovery.threads.per.data.dir | 1 | Antalet trådar som varje datakatalog använder för att logga återställning |
| oren.ledare.val.enable | true | Anger om det är möjligt att använda icke-replika-inställningen i ISR som ledare |
| delete.topic.enable | false | Kan ta bort ämnen |
| offsets.topic.num.partitions | 50 | Antalet partitioner för offset-commit-ämnet. Eftersom det för närvarande inte stöds att ändra detta efter utrullning rekommenderar vi att man använder en högre inställning för produktion (t.ex. 100-200). |
| offsets.topic.retention.minutes | 1440 | Offsets som har funnits längre än denna tidsgräns markeras som väntande radering |
| offsets.retention.check.interval.ms | 600000 | Offset-managern kontrollerar frekvensen av föråldrade offsetar |
| offsets.topic.replication.factor | 3 | Antalet säkerhetskopior av ämnets offset. Det rekommenderas att sätta högre siffror för att garantera högre tillgänglighet |
| offset.topic.segment.bytes | 104857600 | Offset-ämnet. |
| offsets.load.buffer.size | 5242880 | Denna inställning är relaterad till batchstorleken och används vid läsning från offsetsegmentet. |
| offsets.commit.required.acks | -1 | Antalet bekräftelser måste sättas innan offset-commit är acceptabelt, och behöver generellt inte ändras |
| Egendom | Standard | Serverstandardegenskap | Beskrivning |
| Cleanup.policy | Ta bort | logg.cleanup.policy | Antingen "radera" eller "kompaktera"; Denna sträng visar hur man använder den gamla log-delen; Standardmetoden ("ta bort") kommer att kassera den gamla delen när deras återvinningstid eller storleksgräns har nåtts. "kompakt" kommer att komprimera loggarna |
| delete.retention.ms | 86400000 (24 timmar) | log.cleaner.delete.retention.ms | Skillnaden mellan log.retention.minutes är att den ena kontrollerar okomprimerad data och den andra kontrollerar komprimerad data. Denna konfiguration kan åsidosättas av pinningsparametrarna när ämnet skapas |
| flush.messages | Ingen | log.flush.interval.messages | Denna konfiguration specificerar ett tidsintervall för att tvinga fsync-loggar. Till exempel, om detta alternativ är inställt på 1, krävs fsync efter varje meddelande, och om det är satt till 5 krävs fsync för varje 5 meddelanden. Generellt rekommenderas det att du inte sätter detta värde. Inställningen av denna parameter kräver den nödvändiga avvägningen mellan "datatillförlitlighet" och "prestanda". Om detta värde är för stort kommer det att leda till lång tid att "fsynca" varje gång (IO-blockering), och om detta värde är för litet leder det till ett stort antal "fsync", vilket också innebär att det finns en viss fördröjning i den totala klientförfrågan. Fysisk serverfel gör att meddelanden går förlorade utan fsync. |
| flush.ms | Ingen | log.flush.interval.ms | Denna konfiguration används för att fastställa tidsintervallet mellan att tvinga fsync-loggar till disken; Till exempel, om det är inställt på 1000, krävs fsync var 1000 ms. Detta alternativ rekommenderas generellt inte |
| index.interval.bytes | 4096 | log.index.interval.bytes | Standardinställningen säkerställer att vi lägger till ett index i meddelandet var 4096:e byte, och fler index gör läsmeddelandet närmare, men indexstorleken ökar. Detta alternativ är generellt inte nödvändigt |
| max.message.bytes | 1000000 | max.message.bytes | Den maximala storleken på kafka-tilläggsmeddelandet. Observera att om du ökar denna storlek måste du också öka hämtastorleken på din konsument så att konsumenten kan hämta meddelanden till dessa maximala storlekar. |
| min.rengörbart.smutsigt.förhållande | 0.5 | min.rengörbart.smutsigt.förhållande | Denna konfiguration styr hur ofta stockkompressorn försöker rensa stockarna. Som standard undviks loggar med en komprimeringsgrad på mer än 50 %. Denna kvot undviker det största slöseriet med utrymme |
| min.insync.replicas | 1 | min.insync.replicas | När producenten är inställd på request.required.acks till -1, specificerar min.insync.replicas det minsta antalet repliker (varje repica-skriv måste lyckas), och om detta antal inte uppnås kommer producenten att skapa ett undantag. |
| retention.bytes | Ingen | log.retention.bytes | Om du använder "delete"-bevarandepolicyn syftar denna konfiguration på den maximala storlek som loggen kan uppnå innan den raderas. Som standard finns ingen storleksgräns utan endast en tidsgräns |
| retention.ms | 7 dagar | logg.retention.minutes | Om du använder "delete"-bevarandepolicyn avser denna konfiguration tiden då loggen sparades innan raderingsloggen. |
| segment.bytes | 1GB | log.segment.bytes | I Kafka lagras stockstockar i chunkar, och denna konfiguration avser storleken på stockstockar uppdelade i chunks |
| segment.index.bytes | 10MB | log.index.size.max.bytes | Denna konfiguration är ungefär lika stor som indexfilen som mappas mellan offsets och filplatser; Denna konfiguration behöver i allmänhet inte ändras |
| segment.ms | 7 dagar | logg.rull.timmar | Även om loggchunk-filen inte når den storlek som behöver tas bort eller komprimeras, kommer en ny log chunk-fil att tvingas fram när loggtiden når denna övre gräns |
| segment.jitter.ms | 0 | logg.rulla.jitter. {ms,hours} | Den maximala jittern att dra av från logRollTimeMillis. |
| Egendom | Standard | Beskrivning |
| group.id | | En sträng som unikt identifierar gruppen där konsumentprocessen befinner sig, och om samma grupp-ID är satt, betyder det att dessa processer tillhör samma konsumentgrupp |
| zookeeper.connect | | Ange strängen för Zookeeper-anslutningen, formatet är värdnamn:port, här är värden och porten både värd och port för Zookeeper-servern, för att undvika att förlora kontakten efter att en Zookeeper-maskin gått ner kan du ange flera värdnamn:portar med kommatecken som separation:
värdnamn1:port1,värdnamn2:port2,värdnamn3:port3
Du kan lägga till ZooKeepers chroot-väg i ZooKeeper-anslutningssträngen, som används för att lagra sin egen data, på ett sätt:
värdnamn1:port1,värdnamn2:port2,värdnamn3:port3/chroot/path |
| consumer.id | noll | Ingen installation krävs, och generellt genereras den automatiskt |
| socket.timeout.ms | 30*100 | Tidsgränser för nätverksförfrågningar. Den verkliga timeout-gränsen är max.fetch.wait+socket.timeout.ms |
| socket.receive.buffer.bytes | 64*1024 | socket används för att ta emot cachestorleken för nätverksförfrågningar |
| fetch.message.max.bytes | 1024*1024 | Det maximala antalet byte per hämta-meddelande per hämtaförfrågan. Dessa byte övervakas i minnet som används för varje partition, så denna inställning styr mängden minne som används av konsumenten. Hämtandet av begäran måste vara minst lika med den maximala meddelandestorlek som servern tillåter, annars är storleken på det meddelande som producenten kan skicka större än den som konsumenten kan konsumera. |
| num.consumer.fetchers | 1 | Antalet hämtartrådar som används för hämtadata |
| auto.commit.enable | true | Om det stämmer, kommer offsetet av meddelandet som konsumenten hämtar automatiskt att synkroniseras med djurvårdaren. Denna commit-offset kommer att användas av den nya konsumenten när processen läggs upp |
| auto.commit.interval.ms | 60*1000 | Frekvensen med vilken konsumenten skickar in offset till djurskötaren är i sekunder |
| queued.max.message.chunks | 2 | Det maximala antalet meddelanden som används för att cachelagras för konsumtion. Varje chunk måste vara samma som fetch.message.max.bytes |
| rebalance.max. omprövningar | 4 | När en ny konsument läggs till i en konsumentgrupp försöker samlingen av konsumenter ombalansera antalet partitioner som tilldelats varje konsument. Om konsumentens samling ändras misslyckas denna ombalansering och återaktiveras när allokeringen utförs |
| hämta.min.bytes | 1 | Det minsta antalet bytes som servern bör returnera vid varje hämtaförfrågan. Om inte tillräckligt med data returneras väntar förfrågan tills tillräckligt med data har returnerats. |
| fetch.wait.max.ms | 100 | Om det inte finns tillräckligt med data för att uppfylla fetch.min.bytes avser denna konfiguration den maximala tid servern blockerar innan den svarar på en fetch-förfrågan. |
| rebalance.backoff.ms | 2000 | Backoff innan jag försöker reblance igen |
| refresh.leader.backoff.ms | 200 | Det finns en tid att vänta innan man försöker avgöra om en partitions ledare har förlorat sitt ledarskap |
| auto.offset.reset | Största | Om det inte finns någon initierad offset i Zookeeper, om offset är ett svar på följande värde:
minsta: Automatisk återställning till minsta offset
största: Automatisk återställning till offset av största
Allt annat: Ger ett undantag för konsumenten |
| consumer.timeout.ms | -1 | Om inget meddelande är tillgängligt, även efter att ha väntat en viss tid, kastas ett timeout-undantag |
| exkludera.intern.ämnen | true | Om man ska exponera meddelanden från interna ämnen till konsumenter |
| parition.assignment.strategy | Utbredning | Välj policyn för att tilldela partitioner till konsumentflödet, valfritt intervall, roundrobin |
| client.id | Grupp-ID-värde | är en användarspecifik sträng som hjälper till att spåra anrop i varje förfrågan. Den bör logiskt bekräfta applikationen som genererade förfrågan |
| zookeeper.session.timeout.ms | 6000 | Tidsgränser för djurskötarsessioner. Om konsumenten inte skickar ett hjärtslagsmeddelande till djurvårdaren under denna tid anses det vara pålagt och en reblance genereras |
| zookeeper.connection.timeout.ms | 6000 | Maximal väntetid för en klient att etablera en Zookeeper-anslutning |
| zookeeper.sync.time.ms | 2000 | ZK-följare kan halka efter ZK-ledaren under maximal tid |
| offsets.storage | djurskötare | Platser som används för att förvara kompensationer: djurskötare eller kafka |
| offset.channel.backoff.ms | 1000 | Backoff-tiden för att återansluta till offset-kanalen eller försöka om fetch/commit-begäran av den misslyckade offseten |
| offsets.channel.socket.timeout.ms | 10000 | Socketens timeout-gräns för svaret på fetch/commit-förfrågan vid läsoffset. Denna tidsbegränsning används av consumerMetadata-begäran för att begära offset-hantering |
| offsets.commit.max. försök igen | 5 | Antalet gånger offset-commit försöktes om. Denna omprövning tillämpas endast på offset-commits mellan avstängningar. honom |
| dual.commit.enabled | true | Om du använder "kafka" som offsets.storage kan du commit offset till zookeeper två gånger (och en gång till kafka). Detta är ett måste när man migrerar från Zookeeper-baserad offsetlagring till Kafka-baserad offsetlagring. För varje given konsumentgrupp är det en säker rekommendation att stänga av detta alternativ när migreringen är klar |
| partition.assignment.strategy | Utbredning | Välj mellan "range"- och "roundrobin"-policyerna som policy för att tilldela partitioner till konsumentdataflöden; Den cirkulära partitionsallokatorn allokerar alla tillgängliga partitioner samt alla tillgängliga konsumenttrådar. Den kommer att tilldela partitionsloopen till konsumenttråden. Om alla konsumentinstanser prenumereras på en bestämd delas partitionerna upp i deterministiska distributioner. Round-robin-allokeringsstrategin är endast möjlig om följande villkor är uppfyllda: (1) Varje ämne har samma antal dataflöden per konsumentstyrka. (2) Samlingen av prenumererade ämnen bestäms för varje konsumentinstans i konsumentgruppen. |
| Egendom | Standard | Beskrivning |
| metadata.broker.list | | Tjäna bootstrapping. producer används endast för att hämta metadata (ämnen, partitioner, repliker). Socketanslutningen för att skicka den faktiska datan kommer att upprättas baserat på den returnerade metadatan. Formatet är:
värd1:port1,värd2:port2
Denna lista kan vara en underlista över mäklare eller en VIP som pekar på mäklare |
| begäran.krävs.acks | 0 | Denna konfiguration är ett bekräftelsevärde som anger när en produktionsförfrågan anses vara slutförd. Särskilt hur många andra mäklare måste ha lämnat in data till sina loggar och bekräftat denna information för sin ledare. Typiska värden inkluderar:
0: Indikerar att producenten aldrig väntar på bekräftelse från mäklaren (samma beteende som 0,7). Detta alternativ ger minst latens men samtidigt störst risk (eftersom data går förlorad när servern går ner).
1: Indikerar att ledarreplikan har mottagit databekräftelsen. Detta alternativ har låg latens och säkerställer att servern bekräftar att det tas emot.
-1: Producenten får bekräftelse på att alla synkroniserade repliker har mottagit data. Latensen är störst, men denna metod eliminerar inte helt risken för förlorade meddelanden, eftersom antalet synkroniserade repliker kan vara 1. Om du vill säkerställa att vissa repliker tar emot data bör du ställa in alternativet min.insync.replicas i ämnesnivåinställningarna. Läs designdokumentationen för en mer djupgående diskussion. |
| request.timeout.ms | 10000 | Mäklaren gör sitt bästa för att implementera request.required.acks-kravet, annars skickas ett fel till klienten |
| producer.type | Synk | Detta alternativ fastställer om meddelandet skickas asynkront i en bakgrundstråd. Korrekta värden:
(1) asynkron: Asynkron sändning
(2) synk: Synkroniserad sändning
Genom att sätta producenten till asynkron kan vi behandla förfrågningar i batchar (vilket är bra för högre genomströmning), men detta skapar också risken att klientmaskinen förlorar oskickad data |
| serializer.class | kafka.serializer.DefaultEncoder | Serialiseringskategorin för meddelandet. Standardkodaren anger en byte[] och returnerar samma byte[] |
| key.serializer.class | | Serialiseringsklass för nyckelord. Om detta inte ges är standarden att matcha meddelandet |
| partitioner.class | kafka.producer.DefaultPartitioner | partitionerklass för att dela meddelanden mellan delämnen. Standardpartitioneraren baseras på nyckelns hashtabell |
| compression.codec | ingen | Denna parameter kan ställa in codec för att komprimera data, vilket kan väljas som "ingen", "gzip", "snappy". |
| komprimerade.ämnen | noll | Denna parameter kan användas för att bestämma om vissa ämnen ska komprimeras. Om den komprimerade codec är en annan codec än NoCompressCodec, tillämpas dessa codecs på de specificerade ämnesdatana. Om listan över komprimerade ämnen är tom, applicera den specifika komprimerade kodeken på alla ämnen. Om den komprimerade codec är NoCompressionCodec är komprimeringen inte tillgänglig för alla ämnen. |
| message.send.max. försök | 3 | Denna parameter gör att producenten automatiskt försöker om misslyckade sändningsförfrågningar. Denna parameter fastställer antalet försök som är om. Observera: Att sätta ett icke-0-värde kommer att orsaka att vissa nätverksfel upprepas: orsakar en sändning och orsakar förlust av bekräftelse |
| retry.backoff.ms | 100 | Innan varje omförsök uppdaterar producenten metadata för det relevanta ämnet för att se om den nya ledaren tilldelas. Eftersom ledarvalet tar lite tid, specificerar detta alternativ hur länge producenten behöver vänta innan metadata uppdateras. |
| topic.metadata.refresh.interval.ms | 600*1000 | Producenten uppdaterar vanligtvis ämnets metadata i vissa felscenarier (partition saknas, ledare otillgänglig, etc.). Han går igenom en vanlig cykel. Om du sätter det till ett negativt värde kommer metadata bara att uppdateras om det misslyckas. Om den är satt till 0 uppdateras metadata efter varje meddelande som skickats (detta alternativ rekommenderas inte, systemet förbrukar för mycket). Viktigt: Uppdateringar sker först efter att meddelandet har skickats, så om producenten aldrig skickar meddelandet uppdateras metadata aldrig. |
| queue.buffering.max.ms | 5000 | Det maximala tidsintervallet då användaren cachar data när asynkront läge tillämpas. Till exempel, om meddelandet är inställt på 100, kommer meddelanden inom 100 ms att bearbetas i batcher. Detta förbättrar genomströmningen, men ökar latensen på grund av caching. |
| queue.buffering.max.messages | 10000 | När asynkront läge används måste det maximala antalet oskickade meddelanden som kan cachas till kön innan producenten blockeras eller data förloras |
| batch.num.messages | 200 | När du använder asynkront läge kan du batchbehandla så många meddelanden som möjligt. Eller så har antalet meddelanden nått detta online eller queue.buffer.max.ms har kommit, och producenten bearbetar det |
| send.buffer.bytes | 100*1024 | Socket skrivcachestorlek |
| client.id | “” | Detta klient-id är en användarspecifik sträng som ingår i varje förfrågan för att spåra anropet, och han bör logiskt kunna bekräfta att applikationen gjorde begäran. |
| Namn | Typ | Standard | Betydelse | Beskrivning |
| boostrap.servers | Lista | | Högt | Värd/portgrupp för att etablera en anslutning till kafka-klustret. Data kommer att laddas jämnt över alla servrar, oavsett vilken server som är avsedd för bootstrapping. Denna lista påverkar endast de initierade värdarna (som används för att upptäcka alla servrar). Detta listaformat:
host1:port1,host2:port2,...
Eftersom dessa servrar endast används för att initiera anslutningar för att upptäcka alla klustrets medlemskap (som kan ändras dynamiskt), behöver denna lista inte innehålla alla servrar (du kan vilja ha mer än en server, även om en server i detta fall kan vara nere). Om ingen server finns i denna lista kommer sändningsdata att misslyckas tills listan är tillgänglig. |
| ACKS | Sträng | 1 | Högt | Producenten behöver en signal från servern för att bekräfta mottagandet efter att ha mottagit datan, och denna konfiguration avser hur många sådana bekräftelsesignaler prokuudern behöver. Denna konfiguration representerar faktiskt tillgången till databackup. Följande inställningar är vanliga alternativ:
(1) acks=0: Satt till 0 betyder att producenten inte behöver vänta på någon bekräftelse av den mottagna informationen. Replikan kommer omedelbart att läggas till i socketbufferten och betraktas som skickad. Det finns ingen garanti för att servern framgångsrikt har tagit emot datan i detta fall, och återförsöket av konfigurationen kommer inte att fungera (eftersom klienten inte vet om det misslyckades) och offsetet av återkopplingen kommer alltid att sättas till -1.
(2) acks=1: Detta innebär att man åtminstone ska vänta på att ledaren ska skriva datan till den lokala loggen, men inte på att alla följare ska skriva framgångsrikt. I detta fall, om följaren inte lyckas säkerhetskopiera datan och ledaren lägger på igen, förloras meddelandet.
(3) acks=alla: Detta innebär att ledaren måste vänta tills alla säkerhetskopior framgångsrikt skriver loggar, och denna strategi säkerställer att data inte går förlorad så länge en backup överlever. Detta är den starkaste garantin.
(4) Andra inställningar, såsom acks=2, är också möjliga, vilket kräver ett givet antal acks, men denna strategi används generellt sällan. |
| buffer.minne | Lång | 33554432 | Högt | Producenten kan användas för att cachelagra minnesstorleken på datan. Om datan genereras snabbare än den skickas till mäklaren, kommer producenten att blockera eller kasta ett undantag, indikerat med "block.on.buffer.full".
Denna inställning är relaterad till det totala minne som producenten kan använda, men det är ingen hård gräns, eftersom inte allt minne som producenten använder används för caching. En del extra minne används för komprimering (om komprimering införs), och en del används för underhållsförfrågningar. |
| compression.type | Sträng | ingen | Högt | Producer är den typ av komprimering som används för att komprimera data. Standardinställningen är okomprimerad. De korrekta optionsvärdena är ingen, gzip, snappy.
Komprimering används bäst för batchbearbetning, ju fler meddelanden som bearbetas i batcher, desto bättre blir komprimeringsprestandan. |
| Omprövningar | int | 0 | Högt | Att sätta ett värde större än 0 gör att klienten skickar om all data när den datan misslyckas. Observera att dessa återförsök inte skiljer sig från de när klienten får ett skickafel. Tillåter återförsök att potentiellt ändra ordningen på datan, om båda meddelandeposterna skickas till samma partition misslyckas det första meddelandet, det andra meddelandet visas tidigare än det första meddelandet. |
| batch.size | int | 16384 | Medium | Producenten kommer att försöka batcha meddelandeposterna för att minska antalet förfrågningar. Detta kommer att förbättra prestandan mellan klient och server. Denna konfiguration styr standardantalet byte för batchbearbetningsmeddelanden.
Inga försök görs att bearbeta meddelandebytes större än detta byteantal.
Förfrågningar som skickas till mäklare innehåller flera batcher, som innehåller en förfrågan för varje partition.
Mindre batchvärden används mindre och kan minska genomströmningen (0 använder endast batchbearbetning). Större batchvärden slösar mer minnesutrymme, så du måste allokera minne för specifika batchvärden. |
| client.id | Sträng | | Medium | Denna sträng skickas till servern när en begäran görs. Syftet är att kunna spåra källan till förfrågningar för att tillåta vissa applikationer utanför IP/Port-listan att skicka information. Den här appen kan ställa in vilken sträng som helst eftersom den inte har någon annan funktion än att spela in och spåra |
| linger.ms | Lång | 0 | Medium | Producentgruppen kommer att aggregera alla meddelanden som anländer mellan förfrågan och sändningen, och registrera en separat batch av förfrågningar. Vanligtvis händer detta bara när posten genereras snabbare än sändningshastigheten. Men under vissa förhållanden vill klienten minska antalet förfrågningar, eller till och med till en måttlig belastning. Denna uppsättning görs genom att lägga till en liten fördröjning – det vill säga, istället för att skicka en post omedelbart, väntar producenten på en given fördröjningstid för att tillåta andra meddelandeposter att skickas, vilka kan batchas. Detta kan betraktas som en liknande algoritm som TCP Nagle. Denna inställning sätter en högre latensgräns för batching: när vi får batch.size för en partition skickas den omedelbart oavsett denna inställning, men om vi får ett meddelande med mycket mindre byteantal än denna inställning måste vi "dröja" en specifik tid för att få fler meddelanden. Denna inställning är standardinställning 0, alltså ingen fördröjning. Att sätta linger.ms=5, till exempel, minskar antalet förfrågningar, men ökar samtidigt fördröjningen med 5 ms. |
| max.request.size | int | 1028576 | Medium | Det maximala antalet bytes som begärs. Detta är också en effektiv täckning för maximal registrerad storlek. Notera: Servern har sin egen överskrivning av meddelandepoststorlekar, som skiljer sig från denna inställning. Denna inställning begränsar antalet förfrågningar som producenter kan skicka i bulk åt gången för att förhindra ett stort antal förfrågningar. |
| receive.buffer.bytes | int | 32768 | Medium | TCP receivecache-storlek, som används vid dataläsning |
| send.buffer.bytes | int | 131072 | Medium | TCP sändcachestorlek, som används vid datasändning |
| timeout.ms | int | 30000 | Medium | Detta konfigurationsalternativ styr den maximala tiden servern väntar på bekräftelse från följare. Om antalet bekräftade förfrågningar inte uppfylls inom denna tid returneras ett fel. Denna timeout-gräns mäts på serversidan och har ingen nätverkslatens inklusive förfrågningar |
| block.on.buffer.full | Booleskt | true | lågt | När vår minnescache tar slut måste vi sluta ta emot nya meddelandeposter eller kasta fel. Som standard är detta inställt på sant, men viss blockering kan vara oväntad, så det är bättre att ge ett felmeddelande direkt. Detta är fallet när posten är inställd på false: producenten kastar ett undantagsfel: BufferExhaustedException om posten har skickats och cachen är full |
| metadata.fetch.timeout.ms | Lång | 60000 | lågt | Det syftar på förstahandsdata för vissa element som vi har erhållit. Elementen inkluderar: ämne, värd, partitioner. Denna konfiguration avser den tid som krävs för att elementet ska slutföras framgångsrikt enligt hämtningen, annars skickas ett undantag till klienten. |
| metadata.max.age.ms | Lång | 300000 | lågt | Tid i mikrosekunder är intervallet då vi tvingar metadata att uppdateras. Även om vi inte ser några ledarskapsförändringar vid delningen. |
| metric.reporters | Lista | [] | lågt | En lista över klasser som används för att mäta mätvärden. Implementeringen av MetricReporter-gränssnittet kommer att möjliggöra tillägg av klasser som ändras när nya mätvärden genereras. JmxReporter kommer alltid att inkludera ett sätt att registrera JMX-statistik |
| metrics.num.samples | int | 2 | lågt | Antalet prover som används för att underhålla mätvärden |
| metrics.sample.window.ms | Lång | 30000 | lågt | Metrics-systemet håller ett konfigurerbart antal prover i en korrigerbar fönsterstorlek. Denna konfiguration konfigurerar till exempel fönsterstorleken. Vi kan behålla två prover under 30 sekunder. När ett fönster rullas ut suddar vi och skriver om det äldsta fönstret |
| recoonect.backoff.ms | Lång | 10 | lågt | När anslutningen bryts, väntetiden när vi återansluter igen. Detta undviker upprepade klientanslutningar |
| retry.backoff.ms | Lång | 100 | lågt | Väntetiden innan man försöker försöka igen en misslyckad förfrågan om grönsaker. Undvik att fastna i en skicka-fail dead loop.
|
Publicerad på 2021-06-24 11:47:12
|
|
|
Hyresvärd