| Eigendom | Verstek | Beschrijving |
| broker.id | | Elke broker kan worden geïdentificeerd met een unieke niet-negatieve gehele ID; Deze id kan worden gebruikt als de "naam" van de broker, en het bestaan ervan stelt de broker in staat om naar een andere host/port te migreren zonder consumenten te verwarren. Je kunt elk nummer kiezen dat je wilt als ID, zolang het ID uniek is. |
| log.dirs | /tmp/kafka-logs | Het pad waar Kafka data opslaat. Dit pad is niet uniek, het kan meervoudig zijn, en de paden hoeven alleen door komma's gescheiden te zijn; Telkens wanneer een nieuwe partitie wordt aangemaakt, wordt deze gekozen om dit te doen onder het pad dat het minste aantal partities bevat. |
| Haven | 6667 | Server accepteert de poort waarmee de client verbinding maakt |
| zookeeper.connect | nul | Het formaat van de ZooKeeper-verbindingsstring is: hostname:port, waarbij hostnaam en port respectievelijk de host en poort zijn van een knooppunt in de ZooKeeper-cluster. Om verbinding te maken met andere ZooKeeper-nodes wanneer een host uitvalt, kun je meerdere hosts als volgt aanmaken:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper stelt je in staat een "chroot"-pad toe te voegen om alle kafka-data in de cluster onder een specifiek pad op te slaan. Wanneer meerdere Kafka-clusters of andere applicaties dezelfde ZooKeeper-cluster gebruiken, kun je deze methode gebruiken om het data-opslagpad in te stellen. Dit kan worden geïmplementeerd door de verbindingsstring als volgt te formatteren:
hostnaam1:port1,hostnaam2:port2,hostnaam3:port3/chroot/path
Deze setup slaat alle kafka-clustergegevens op onder het /chroot/path-pad. Let op dat je voordat je de makelaar start, dit pad moet aanmaken en dat consumenten hetzelfde verbindingsformaat moeten gebruiken. |
| message.max.bytes | 1000000 | De maximale grootte van berichten die een server kan ontvangen. Het is belangrijk dat de instellingen van de consument en producent met betrekking tot deze eigenschap gesynchroniseerd zijn, anders is de boodschap die door de producent wordt gepubliceerd te groot voor de consument. |
| num.netwerk.threads | 3 | Het aantal netwerkthreads dat door de server wordt gebruikt om netwerkverzoeken te verwerken; Je hoeft deze woning meestal niet te veranderen. |
| num.io.threads | 8 | Het aantal I/O-threads dat door de server wordt gebruikt om verzoeken te verwerken; Het aantal threads moet minstens gelijk zijn aan het aantal harde schijven. |
| achtergrond.threads | 4 | Het aantal threads dat wordt gebruikt voor achtergrondverwerking, zoals het verwijderen van bestanden; Je hoeft dit eigendom niet te veranderen. |
| queued.max.verzoeken | 500 | Het maximale aantal verzoeken dat in de wachtrij kan worden gezet voor een I/O-thread om te verwerken voordat een netwerkthread stopt met het lezen van nieuwe verzoeken. |
| host.name | nul | Broker's hostname; Als de hostnaam al is ingesteld, is de broker alleen aan dit adres gebonden; Als er geen instelling is, zal het naar alle interfaces binden en één kopie publiceren naar de ZK |
| advertised.host.name | nul | Als deze is ingesteld, wordt deze gestuurd naar producenten, consumenten en andere makelaars als de hostnaam van de makelaar |
| adverteerd.port | nul | Deze poort wordt gegeven aan producenten, consumenten en andere tussenpersonen, en wordt gebruikt om een verbinding tot stand te brengen; Het hoeft alleen ingesteld te worden als de daadwerkelijke poort en de poort die de server moet binden verschillend zijn. |
| socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Cachegrootte, die de server gebruikt om socketverbindingen te maken |
| socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF cachegrootte, die door de server wordt gebruikt om verbinding te maken met sockets |
| socket.request.max.bytes | 100 * 1024 * 1024 | De maximale verzoekgrootte die door de server is toegestaan; Dit voorkomt serveroverloop, die kleiner moeten zijn dan de grootte van de Java-heap |
| num.partitions | 1 | Als het aantal partities niet wordt gegeven bij het aanmaken van een onderwerp, zal dit aantal het standaardaantal partities onder het onderwerp zijn. |
| log.segment.bytes | 1014*1024*1024 | De logs van de topicpartitie worden opgeslagen in veel bestanden in een bepaalde map, die de logs van de partitie in segmenten verdelen; Dit attribuut is de maximale grootte van elk bestand; Wanneer de dimensies deze waarde bereiken, wordt er een nieuw bestand aangemaakt. Deze instelling kan worden overschreven door de basis van elk onderwerp.
Uitzicht De hyperlink-login is zichtbaar. |
| log.roll.uren | 24 * 7 | Zelfs als het bestand log.segment.bytes niet bereikt, wordt er een nieuw bestand aangemaakt zodra de aanmaaktijd deze eigenschap bereikt. Deze instelling kan ook worden overschreven door onderwerpniveau-instellingen;
BekijkenDe hyperlink-login is zichtbaar. |
| log.cleanup.policy | verwijderen | |
| log.retention.minutes en log.retention.uren | 7 dagen | De tijd dat elk logbestand werd opgeslagen voordat het werd verwijderd. De standaard databesparende tijd is voor alle onderwerpen hetzelfde.
log.retention.minutes en log.retention.bytes worden beide gebruikt om het verwijderen van logbestanden in te stellen, ongeacht welke eigenschap is overstroomd.
Deze eigenschapsinstelling kan worden overschreven wanneer het onderwerp in feite is ingesteld.
BekijkenDe hyperlink-login is zichtbaar. |
| log.retention.bytes | -1 | De totale hoeveelheid data die door elke partitie onder elk onderwerp wordt opgeslagen; Let op dat dit de bovengrens per partitie is, dus dit getal vermenigvuldigd met het aantal partities is de totale hoeveelheid opgeslagen data per onderwerp. Let ook op: als zowel log.retention.hours als log.retention.bytes zijn ingesteld, zal het overschrijden van een van beide limieten ertoe leiden dat een segmentbestand wordt verwijderd.
Let op dat deze instelling door elk onderwerp kan worden overschreven.
BekijkenDe hyperlink-login is zichtbaar. |
| log.retention.check.interval.ms | 5 minuten | Controleer het interval tussen loggesegmenteerde bestanden om te bepalen of de bestandsattributen voldoen aan de verwijderingsvereisten. |
| log.cleaner.enable | false | Wanneer deze eigenschap op false wordt gezet, wordt deze verwijderd zodra het logboek voor een maximale tijd of grootte is opgeslagen. Als het op waar staat, gebeurt dit wanneer het save-attribuut de bovengrens bereiktDe hyperlink-login is zichtbaar.。 |
| log.cleaner.threads | 1 | Het aantal threads dat logcompressie uitvoert |
| log.cleaner.io.max.bytes.per.second | Geen | Het maximale aantal I/O's dat een log cleaner kan hebben bij het uitvoeren van een logverdichting. Deze instelling beperkt de cleaner om te voorkomen dat actieve verzoekservices worden verstoord. |
| log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indexeert logs tijdens het opruimproces en verkleint de grootte van de gebruikte cache. Het is het beste om het groot in te stellen om voldoende geheugen te bieden. |
| log.cleaner.io.buffer.load.factor | 512*1024 | De grootte van het I/O-stuk dat nodig is voor het reinigen van boomstammen. Je hoeft deze instelling niet te veranderen. |
| log.cleaner.io.buffer.load.factor | 0.9 | de belastingsfactor van de hashtabel die wordt gebruikt bij logreiniging; Je hoeft deze optie niet te veranderen. |
| log.cleaner.backoff.ms | 15000 | Het tijdsinterval waarin het logboek wordt opgeschoond wordt uitgevoerd |
| log.cleaner.min.cleanable.ratio | 0.5 | Deze configuratie bepaalt hoe vaak de logcompactor probeert de logs op te ruimen (verondersteldDe hyperlink-login is zichtbaar.is open). Vermijd standaard het schoonmaken van meer dan 50% van de stammen. Deze verhouding is gekoppeld aan de maximale ruimte die door het back-uplogboek wordt ingenomen (50% van de logs wordt bij 50% samengedrukt). Een hogere prijs betekent minder afval en meer ruimte kan efficiënter worden vrijgemaakt. Deze instelling kan in elke onderwerpinstelling worden overschreven.
BekijkenDe hyperlink-login is zichtbaar.。 |
| log.cleaner.delete.retention.ms | 1 dag | opslagtijd; De maximale tijd om gecomprimeerde logs bij te houden; Het is ook de maximale tijd die de client voor berichten kan consumeren, en het verschil tussen log.retention.minutes is dat de ene de niet-gecomprimeerde data beheert en de andere de gecomprimeerde data, die worden overschreven tegen de opgegeven tijd wanneer het onderwerp wordt aangemaakt. |
| log.index.size.max.bytes | 10*1024*1024 | De maximale grootte per logsegment. Let op dat als de loggrootte deze waarde bereikt, een nieuw logsegment moet worden gegenereerd, zelfs als de grootte de limiet van log.segment.bytes niet overschrijdt. |
| log.index.interval.bytes | 4096 | Bij het uitvoeren van een fetch moet je de dichtstbijzijnde offset scannen met een bepaalde hoeveelheid ruimte; hoe groter de instelling, hoe beter, meestal gebruik je de standaardwaarde |
| log.flush.interval.messages | Long.MaxValue | logbestand "synchroniseert" met de schijf voordat berichten worden verzameld. Omdat schijf-IO-operaties een trage operatie zijn, maar ook een noodzakelijke manier van "databetrouwbaarheid", controleer of het tijdsinterval om te herstellen op de harde schijf vereist is. Als deze waarde te groot is, leidt dit tot een te lange "sync"-tijd (IO-blokkering), als deze waarde te klein is, leidt dat tot een lange tijd van "fsync" (IO-blokkering), als deze waarde te klein is, leidt dit tot een groot aantal "sync"-tijden, wat betekent dat het totale clientverzoek een bepaalde vertraging heeft, en het falen van de fysieke server zal leiden tot het verlies van berichten zonder fsync. |
| log.flush.scheduler.interval.ms | Long.MaxValue | Controleer of fsync-intervallen nodig zijn |
| log.flush.interval.ms | Long.MaxValue | Dit getal wordt gebruikt om het tijdsinterval van "fsync" te regelen; als het aantal berichten nooit het aantal berichten bereikt dat aan de schijf is vastgezet, maar het tijdsinterval vanaf de laatste schijfsynchronisatie de drempel bereikt, wordt ook schijfsynchronisatie geactiveerd. |
| log.delete.delay.ms | 60000 | De bewaartijd nadat het bestand in de index is verwijderd, hoeft over het algemeen niet te worden aangepast |
| auto.create.topics.enable | true | Of het automatisch aanmaken van onderwerpen mogelijk moet worden. Als het waar is, zal het automatisch een topic aanmaken dat niet bestaat wanneer produce of fetch niet bestaat. Anders moet je de commandoregel gebruiken om een onderwerp aan te maken |
| controller.socket.timeout.ms | 30000 | De time-out tijd van de socket wanneer de partitiebeheercontroller een back-up maakt. |
| controller.message.queue.size | Int.MaxValue | Controller-naar-makelaar-channles |
| default.replication.factor | 1 | Het standaardaantal back-upkopieën verwijst alleen naar automatisch aangemaakte onderwerpen |
| replica.lag.time.max.ms | 10000 | Als een volger binnen deze tijd geen fetch-verzoek stuurt, verwijdert de leider de volger weer uit de ISR en beschouwt hij de volger als opgehangen |
| replica.lag.max.berichten | 4000 | Als een replica meer dan dit aantal ongeback-upte heeft, verwijdert de leider de volger en beschouwt hij de volger als opgehangen |
| replica.socket.timeout.ms | 30*1000 | Leider-timeout tijd voor socketnetwerkverzoeken bij het back-uppen van data |
| replica.socket.receive.buffer.bytes | 64*1024 | Socket ontvangsbuffer wanneer een netwerkverzoek naar de leider wordt gestuurd tijdens een back-up |
| replica.fetch.max.bytes | 1024*1024 | De maximale waarde van elke fetch op het moment van back-up |
| replica.fetch.min.bytes | 500 | De maximale wachttijd voor data om de leider te bereiken wanneer de leider een back-upverzoek doet |
| replica.fetch.min.bytes | 1 | De kleinste grootte van de respons na elke fetch bij het back-up |
| num.replica.fetchers | 1 | Het aantal threads dat data van de leider back-upt |
| replica.high.watermark.checkpoint.interval.ms | 5000 | Elke replica controleert hoe vaak het hoogste waterniveau wordt uitgehard |
| fetch.purgatory.purge.interval.requests | 1000 | fetch verzoek om het purge interval |
| producer.purgatory.purge.interval.requests | 1000 | Producer vraagt om een purge-interval |
| zookeeper.session.timeout.ms | 6000 | Time-out voor de Zookeeper-sessie. |
| zookeeper.connection.timeout.ms | 6000 | De maximale tijd die de cliënt wacht om een verbinding met de dierenverzorger op te bouwen |
| zookeeper.sync.time.ms | 2000 | ZK Follower blijft lange tijd achter op ZK Leader |
| controlled.shutdown.enable | true | Of het mogelijk is om de sluiting van de makelaar te controleren. Indien mogelijk kan de makelaar alle leiders naar andere makelaars verplaatsen vóór de overdracht. Dit vermindert de onbeschikbaarheid tijdens het afsluitproces. |
| controlled.shutdown.max. opnieuw proberen | 3 | Het aantal commando's dat een afsluiting succesvol kan uitvoeren voordat een onvolledige afsluiting wordt uitgevoerd. |
| controlled.shutdown.retry.backoff.ms | 5000 | Terugvaltijd tussen de shutdowns |
| auto.leader.rebalance.enable | true | Als dit waar is, zal de controller automatisch het leiderschap van de makelaars over de partities in evenwicht brengen |
| leider.onbalans.per.broker.percentage | 10 | De maximale onevenwichtsverhouding die door elke makelaar wordt toegestaan |
| leader.imbalance.check.interval.seconds | 300 | Controleer de frequentie van de leiderdisbalans |
| offset.metadata.max.bytes | 4096 | Stelt klanten in staat het maximale aantal van hun offsets op te slaan |
| max.connections.per.ip | Int.MaxValue | Het maximale aantal verbindingen per broker kan worden gemaakt naar elk IP-adres |
| max.connections.per.ip.overrides | | De maximale dekking van de standaardverbinding per IP of hostnaam |
| connections.max.idle.ms | 600000 | Timeout-limiet voor lege verbindingen |
| log.roll.jitter. {ms,uren} | 0 | Het maximale aantal schokken abstraht van logRollTimeMillis |
| num.recovery.threads.per.data.dir | 1 | Het aantal threads dat elke datamap gebruikt om het herstel te loggen |
| onrein.leider.verkiezing.enable | true | Geeft aan of het mogelijk is om de niet-replica's-instelling in ISR als leider te gebruiken |
| delete.topic.enable | false | Onderwerpen kunnen verwijderen |
| offsets.topic.num.partitions | 50 | Het aantal partities voor het offset commit-onderwerp. Omdat het wijzigen hiervan na implementatie momenteel niet wordt ondersteund, raden we aan om een hogere instelling voor productie te gebruiken (bijvoorbeeld 100-200). |
| offsets.topic.retention.minutes | 1440 | Offsets die langer dan deze tijdslimiet bestaan, worden als in behandeling genomen verwijderd worden gemarkeerd als in behandeling verwijdering |
| offsets.retention.check.interval.ms | 600000 | De offsetmanager controleert de frequentie van verouderde offsets |
| offsets.topic.replication.factor | 3 | Het aantal back-upkopieën van het onderwerp is offset. Het wordt aanbevolen om hogere nummers in te stellen om een hogere beschikbaarheid te garanderen |
| offset.topic.segment.bytes | 104857600 | Offsets topic. |
| offsets.load.buffer.size | 5242880 | Deze instelling is gerelateerd aan de batchgrootte en wordt gebruikt bij het lezen van het offsetsegment. |
| offsets.commit.required.acks | -1 | Het aantal bevestigingen moet worden ingesteld voordat de offsetcommit acceptabel is, en hoeft over het algemeen niet te worden gewijzigd |
| Eigendom | Verstek | Serverstandaardeigenschap | Beschrijving |
| Cleanup.Policy | verwijderen | log.cleanup.policy | Ofwel "verwijderen" of "compact"; Deze string geeft aan hoe het oude loggedeelte gebruikt moet worden; De standaardmethode ("verwijderen") zal het oude onderdeel weggooien zodra hun recyclingtijd of groottelimiet is bereikt. "compact" zal de logs comprimeren |
| delete.retention.ms | 864000000 (24 uur) | log.cleaner.delete.retention.ms | Het verschil tussen log.retention.minutes is dat de ene ongecomprimeerde data aanstuurt en de andere gecomprimeerde data. Deze configuratie kan worden overschreven door de pinningparameters wanneer het onderwerp wordt aangemaakt |
| flush.berichten | Geen | log.flush.interval.messages | Deze configuratie specificeert een tijdsinterval om fsync-logs te forceren. Als deze optie bijvoorbeeld op 1 staat, is fsync vereist na elk bericht, en als het op 5 staat, is fsync vereist voor elke 5 berichten. In het algemeen wordt aanbevolen deze waarde niet in te stellen. Het instellen van deze parameter vereist de noodzakelijke afweging tussen "databetrouwbaarheid" en "prestatie". Als deze waarde te groot is, zal het elke keer lang 'fsyncen' (IO-blokkering), en als deze waarde te klein is, leidt dit tot een groot aantal 'fsync', wat ook betekent dat er een bepaalde vertraging is in het totale clientverzoek. Fysieke serverstoring zorgt ervoor dat berichten verloren gaan zonder fsync. |
| flush.ms | Geen | log.flush.interval.ms | Deze configuratie wordt gebruikt om het tijdsinterval tussen het forceren van fsync-logs op de schijf vast te leggen; Als je bijvoorbeeld op 1000 staat, is fsync elke 1000 ms nodig. Deze optie wordt over het algemeen niet aanbevolen |
| index.interval.bytes | 4096 | log.index.interval.bytes | De standaardinstelling zorgt ervoor dat we elke 4096 bytes een index aan het bericht toevoegen, en meer indexen brengen het gelezen bericht dichterbij, maar de indexgrootte wordt vergroot. Deze optie is over het algemeen niet vereist |
| max.message.bytes | 1000000 | max.message.bytes | De maximale grootte van het kafka-appendbericht. Let op dat als je deze grootte vergroot, je ook de fetch-grootte van je consument moet vergroten zodat de consument berichten tot die maximale groottes kan ophalen. |
| min.schoonmaakbaar.vuil.verhouding | 0.5 | min.schoonmaakbaar.vuil.verhouding | Deze configuratie bepaalt hoe vaak de logcompressor probeert de logs te verwijderen. Standaard worden logs met een compressiesnelheid van meer dan 50% vermeden. Deze verhouding voorkomt de grootste verspilling van ruimte |
| min.insync.replicas | 1 | min.insync.replicas | Wanneer de producer is ingesteld op request.required.acks op -1, specificeert min.insync.replicas het minimale aantal replica's (elke repica-schrijf moet succesvol zijn), en als dit aantal niet wordt bereikt, zal de producer een uitzondering maken. |
| retention.bytes | Geen | log.retention.bytes | Als je het "delete"-retentiebeleid gebruikt, verwijst deze configuratie naar de maximale grootte die het logboek kan bereiken voordat het wordt verwijderd. Standaard is er geen groottelimiet, maar slechts een tijdslimiet |
| retention.ms | 7 dagen | log.retention.minutes | Als je het "delete"-retentiebeleid gebruikt, verwijst deze configuratie naar de tijd waarop het logboek werd opgeslagen vóór het verwijderingslogboek. |
| segment.bytes | 1GB | log.segment.bytes | In Kafka worden loglogs opgeslagen in chunks, en deze configuratie verwijst naar de grootte van loglogs die in chunks zijn verdeeld |
| segment.index.bytes | 10MB | log.index.size.max.bytes | Deze configuratie is ongeveer de grootte van het indexbestand dat tussen offsets en bestandslocaties wordt gemapt; Deze configuratie hoeft over het algemeen niet aangepast te worden |
| segment.ms | 7 dagen | log.roll.uren | Zelfs als het log chunk-bestand niet de grootte bereikt die verwijderd of gecomprimeerd moet worden, zal zodra de logtijd deze bovengrens bereikt, een nieuw log chunk bestand worden afgedwongen zodra de logtijd deze bovengrens bereikt |
| segment.jitter.ms | 0 | log.roll.jitter. {ms,uren} | De maximale jitter die van logRollTimeMillis moet worden afgetrokken. |
| Eigendom | Verstek | Beschrijving |
| group.id | | Een string die uniek de groep identificeert waarin het consumentenproces zich bevindt, en als dezelfde groeps-ID is ingesteld, betekent dit dat deze processen tot dezelfde consumentengroep behoren |
| zookeeper.connect | | Specificeer de string van de Zookeeper-verbinding, het formaat is hostname:port, hier zijn host en port zowel de host als de poort van de Zookeeper-server, om contact te voorkomen nadat een Zookeeper-machine uitvalt, kun je meerdere hostname:ports specificeren, met komma's als scheiding:
hostnaam1:poort1,hostnaam2:poort2,hostnaam3:poort3
Je kunt het chroot-pad van de ZooKeeper toevoegen aan de ZooKeeper-verbindingsstring, die wordt gebruikt om zijn eigen data op te slaan, op een bepaalde manier:
hostnaam1:port1,hostnaam2:port2,hostnaam3:port3/chroot/path |
| consumer.id | nul | Er is geen installatie nodig en het wordt over het algemeen automatisch gegenereerd |
| socket.timeout.ms | 30*100 | Time-out limieten voor netwerkverzoeken. De werkelijke timeoutlimiet is max.fetch.wait+socket.timeout.ms |
| socket.receive.buffer.bytes | 64*1024 | Socket wordt gebruikt om de cachegrootte van netwerkverzoeken te ontvangen |
| fetch.message.max.bytes | 1024*1024 | Het maximale aantal bytes per fetch-bericht per fetch-verzoek. Deze bytes worden gecontroleerd in het geheugen dat voor elke partitie wordt gebruikt, dus deze instelling bepaalt de hoeveelheid geheugen die de consument gebruikt. De fetch-verzoekgrootte moet minstens gelijk zijn aan de maximale berichtgrootte die door de server is toegestaan, anders is de grootte van het bericht dat de producent mag verzenden groter dan de grootte die de consument kan consumeren. |
| num.consumer.fetchers | 1 | Het aantal fetcher-threads dat wordt gebruikt voor fetch-data |
| auto.commit.enable | true | Als het waar is, wordt de offset van het bericht dat door de consument wordt opgehaald automatisch gesynchroniseerd met de zookeeper. Deze commit offset wordt gebruikt door de nieuwe consument wanneer het proces vastloopt |
| auto.commit.interval.ms | 60*1000 | De frequentie waarmee de consument offset naar de dierenverzorger stuurt, is in enkele seconden |
| queued.max.message.chunks | 2 | Het maximale aantal berichten dat wordt gebruikt om te cachen voor consumptie. Elke chunk moet hetzelfde zijn als fetch.message.max.bytes |
| rebalance.max. probeert het opnieuw | 4 | Wanneer een nieuwe consument aan een consumentengroep wordt toegevoegd, probeert de verzameling consumenten het aantal toegewezen partities per consument te herbalanceren. Als de verzameling van de consument verandert, faalt deze herbalancering en wordt opnieuw geïntentrificeerd wanneer de allocatie wordt uitgevoerd |
| fetch.min.bytes | 1 | Het minimale aantal bytes dat de server bij elk fetch-verzoek moet teruggeven. Als er niet genoeg data wordt teruggegeven, wacht het verzoek tot er genoeg data is teruggegeven. |
| fetch.wait.max.ms | 100 | Als er niet genoeg data is om fetch.min.bytes te vervullen, verwijst deze configuratie naar de maximale tijd die de server blokkeert voordat hij op een fetch-verzoek reageert. |
| rebalance.backoff.ms | 2000 | Tijd om terug te gaan voordat ik opnieuw reblance probeer |
| refresh.leader.backoff.ms | 200 | Er is een tijd om te wachten voordat je probeert te bepalen of de leider van een partitie zijn leiderschap heeft verloren |
| auto.offset.reset | Grootste | Als er geen geïnitialiseerde offset is in Zookeeper, als offset een reactie is op de volgende waarde:
kleinste: Auto reset offset naar kleinste offset
grootste: Auto reset offset naar de offset van grootste
Alles anders: Geeft een uitzondering voor de consument |
| consumer.timeout.ms | -1 | Als er geen bericht beschikbaar is, wordt er zelfs na een bepaalde tijd een timeout-uitzondering gegooid |
| exclude.internal.topics | true | Of berichten van interne onderwerpen aan consumenten worden blootgesteld |
| parition.assignment.strategy | Verspreiding | Selecteer het beleid voor het toewijzen van partities aan de consumentenstroom, optioneel range, roundrobin |
| client.id | groeps-ID-waarde | is een gebruikersspecifieke string die helpt bij het volgen van aanroepen in elk verzoek. Het zou logisch moeten bevestigen welke applicatie het verzoek heeft gegenereerd |
| zookeeper.session.timeout.ms | 6000 | Time-out limieten voor de sessies van dierenverzorgers. Als de consument tijdens deze periode geen hartslagbericht naar de dierenverzorger stuurt, wordt het als opgehangen beschouwd en wordt er een reblance gegenereerd |
| zookeeper.connection.timeout.ms | 6000 | De maximale wachttijd voor een klant om een Zookeeper-verbinding op te zetten |
| zookeeper.sync.time.ms | 2000 | ZK-volgers kunnen maximaal achter de ZK-leider blijven |
| offsets.storage | Dierenverzorger | Plaatsen waar offsets worden opgeslagen: dierenverzorger of kafka |
| offset.channel.backoff.ms | 1000 | De backoff-tijd voor het opnieuw verbinden met het offset-kanaal of het opnieuw proberen van het fetch/commit-verzoek van de mislukte offset |
| offsets.channel.socket.timeout.ms | 10000 | De socket-timeoutlimiet voor de reactie op het fetch/commit request-antwoord bij reading offset. Deze timeoutlimiet wordt gebruikt door het consumerMetadata-verzoek om offsetbeheer aan te vragen |
| offsets.commit.max.opnieuw pogingen | 5 | Het aantal keren dat de offset commit opnieuw werd geprobeerd. Deze herpoging wordt alleen toegepast op offset commits tussen het afsluiten. hem |
| dual.commit.enabled | true | Als je "kafka" gebruikt als offsets.storage, kun je twee keer offset naar zookeeper toezeggen (en één keer naar kafka). Dit is een must bij het migreren van Zookeeper-gebaseerde offsetopslag naar Kafka-gebaseerde offsetopslag. Voor elke consumentengroep is het een veilige aanbeveling om deze optie uit te schakelen zodra de migratie is voltooid |
| partition.assignment.strategy | Verspreiding | Kies tussen de "range"- en "roundrobin"-beleidsregels als beleid voor het toewijzen van partities aan consumentendatastromen; De circulaire partitie-allocatie wijst alle beschikbare partities toe evenals alle beschikbare consumententhreads. Het zal de partitielus toewijzen aan de consumerthread. Als alle consumenteninstanties zijn geabonneerd op een bepaalde, worden de partities verdeeld in deterministische distributies. De round-robin allocatiestrategie is alleen mogelijk als aan de volgende voorwaarden is voldaan: (1) Elk onderwerp heeft hetzelfde aantal datastromen per consumentsterkte. (2) De verzameling van geabonneerde onderwerpen wordt bepaald voor elke consumenteninstantie in de consumentengroep. |
| Eigendom | Verstek | Beschrijving |
| metadata.broker.list | | Dient bootstrapping. Producer wordt alleen gebruikt om metadata (topics, partitions, replica's) te verkrijgen. De socketverbinding om de daadwerkelijke data te verzenden wordt opgebouwd op basis van de teruggegeven metadatagegevens. Het format is:
host1:port1,host2:port2
Deze lijst kan een sublijst van makelaars zijn of een VIP die naar makelaars verwijst |
| verzoek.vereist.acks | 0 | Deze configuratie is een bevestigingswaarde die aangeeft wanneer een productieverzoek als voltooid wordt beschouwd. In het bijzonder, hoeveel andere makelaars moeten gegevens aan hun logboeken hebben toegevoegd en deze informatie aan hun leider hebben bevestigd. Typische waarden zijn onder andere:
0: Geeft aan dat de producent nooit wacht op bevestiging van de makelaar (hetzelfde gedrag als 0,7). Deze optie biedt de minste latentie, maar tegelijkertijd het grootste risico (omdat data verloren gaat als de server uitvalt).
1: Geeft aan dat de leiderreplica de gegevensbevestiging heeft ontvangen. Deze optie heeft een lage latentie en zorgt ervoor dat de server bevestigt dat het is ontvangen.
-1: De producent krijgt bevestiging dat alle gesynchroniseerde replica's data hebben ontvangen. De latentie is het grootst, maar deze methode elimineert het risico op verloren berichten niet volledig, omdat het aantal gesynchroniseerde replica's 1 kan zijn. Als je wilt garanderen dat sommige replica's data ontvangen, moet je de optie min.insync.replicas instellen in de topic-level instellingen. Lees de ontwerpdocumentatie voor een diepgaandere discussie. |
| request.timeout.ms | 10000 | De broker doet zijn best om de request.required.acks-eis te implementeren, anders wordt er een foutmelding naar de client gestuurd |
| producer.type | Synchronisatie | Deze optie bepaalt of het bericht asynchroon in een achtergronddraad wordt verzonden. Correcte waarden:
(1) asynchroon: asynchrone verzending
(2) synchronisatie: Gesynchroniseerd verzenden
Door de producer op asynchroon te zetten, kunnen we verzoeken in batches verwerken (wat goed is voor een hogere doorvoersnelheid), maar dit creëert ook de mogelijkheid dat de clientmachine onverzonden data verliest |
| serializer.class | kafka.serializer.DefaultEncoder | De serialisatiecategorie van het bericht. De standaardencoder voert één byte[] in en geeft dezelfde byte[] terug |
| key.serializer.class | | Serialisatieklasse voor trefwoorden. Als dit niet wordt gegeven, is de standaard het overeenkomen met het bericht |
| partitioner.class | kafka.producer.DefaultPartitioner | Partitionerklasse om berichten tussen subonderwerpen te verdelen. De standaard partitieer is gebaseerd op de hashtabel van de sleutel |
| compression.codec | geen | Deze parameter kan de codec instellen voor het comprimeren van data, die kan worden geselecteerd als "geen", "gzip", "snappy". |
| gecomprimeerde.topics | nul | Deze parameter kan worden gebruikt om in te stellen of bepaalde onderwerpen worden gecomprimeerd. Als de gecomprimeerde codec een andere codec is dan NoCompressCodec, worden deze codecs toegepast op de gegevens van de gespecificeerde onderwerpen. Als de lijst met gecomprimeerde onderwerpen leeg is, pas dan de specifieke gecomprimeerde codec toe op alle onderwerpen. Als de gecomprimeerde codec NoCompressionCodec is, is de compressie niet beschikbaar voor alle onderwerpen. |
| message.send.max.tries opnieuw | 3 | Deze parameter zorgt ervoor dat de producent automatisch opnieuw probeert mislukte verzendverzoeken te doen. Deze parameter bepaalt het aantal herpogingen. Opmerking: Het instellen van een waarde van niet-0 zorgt ervoor dat bepaalde netwerkfouten zich herhalen: dit veroorzaakt een verzending en een verlies van bevestiging |
| retry.backoff.ms | 100 | Voor elke herpoging werkt de producent de metadata van het betreffende onderwerp bij om te zien of de nieuwe leider is toegewezen. Omdat de selectie van de leider wat tijd kost, specificeert deze optie hoe lang de producent moet wachten voordat de metadata worden bijgewerkt. |
| topic.metadata.refresh.interval.ms | 600*1000 | De producent werkt doorgaans de metadata van het onderwerp bij in sommige faalscenario's (partitie ontbreekt, leider niet beschikbaar, enz.). Hij zal een regelmatige cyclus doorlopen. Als je het op een negatieve waarde zet, wordt de metadata alleen bijgewerkt als het faalt. Als deze op 0 staat, wordt de metadata bijgewerkt na elk verzonden bericht (deze optie wordt niet aanbevolen, het systeem verbruikt te veel). Belangrijk: Updates vinden pas plaats nadat het bericht is verzonden, dus als de producent het bericht nooit verstuurt, wordt de metadata nooit bijgewerkt. |
| queue.buffering.max.ms | 5000 | Het maximale tijdsinterval waarop de gebruiker gegevens cachet wanneer asynchroon modus wordt toegepast. Als het bericht bijvoorbeeld op 100 is gezet, worden berichten binnen 100 ms in batches verwerkt. Dit verbetert de doorvoersnelheid, maar verhoogt de latentie door caching. |
| queue.buffering.max.berichten | 10000 | Bij gebruik van asynchroon modus moet het maximale aantal niet-verzonden berichten dat in de wachtrij kan worden gecachet voordat de producent wordt geblokkeerd of data verloren gaat |
| batch.num.messages | 200 | Bij gebruik van asynchrone modus kun je het maximale aantal berichten batchverwerken. Of het aantal berichten is online bereikt of queue.buffer.max.ms is binnengekomen, en de producent verwerkt het |
| send.buffer.bytes | 100*1024 | Grootte van de schrijfcache van socket |
| client.id | “” | Deze client-id is een gebruikersspecifieke string die in elk verzoek wordt opgenomen om het gesprek te volgen, en hij zou logisch moeten kunnen bevestigen dat de applicatie het verzoek heeft gedaan. |
| Naam | Type | Verstek | Belang | Beschrijving |
| boostrap.servers | Lijst | | hoog | Host/poortgroep om een verbinding met de kafka-cluster te leggen. Data wordt gelijkmatig geladen over alle servers, ongeacht welke server is aangewezen voor bootstrapping. Deze lijst heeft alleen invloed op de geïnitialiseerde hosts (die wordt gebruikt om alle servers te ontdekken). Dit lijstformaat:
host1:port1,host2:port2,...
Aangezien deze servers alleen worden gebruikt om verbindingen te initialiseren om alle lidmaatschappen van de cluster te ontdekken (die dynamisch kunnen veranderen), hoeft deze lijst niet alle servers te bevatten (je wilt misschien meer dan één server, hoewel in dat geval één server offline kan zijn). Als er geen server in deze lijst verschijnt, zal het verzenden van gegevens falen totdat de lijst beschikbaar is. |
| AKKS | String | 1 | hoog | De producer heeft een signaal van de server nodig om ontvangst te bevestigen na ontvangst van de gegevens, en deze configuratie verwijst naar hoeveel dergelijke bevestigingssignalen de procuder nodig heeft. Deze configuratie vertegenwoordigt eigenlijk de beschikbaarheid van data-back-ups. De volgende instellingen zijn veelvoorkomende opties:
(1) acks=0: Gezet op 0 betekent dat de producent niet hoeft te wachten op bevestiging van de ontvangen informatie. De replica wordt onmiddellijk toegevoegd aan de socketbuffer en als verzonden beschouwd. Er is geen garantie dat de server de data in dit geval succesvol heeft ontvangen, en de herkansing van de configuratie zal niet werken (omdat de client niet weet of het is mislukt) en de offset van de feedback zal altijd op -1 worden gezet.
(2) acks=1: Dit betekent dat je ten minste moet wachten tot de leider de data succesvol naar het lokale logboek heeft geschreven, maar niet tot alle volgers succesvol zijn geschreven. In dit geval, als de volger de data niet succesvol back-uppt en de leider opnieuw ophangt, gaat het bericht verloren.
(3) acks=all: Dit betekent dat de leider moet wachten tot alle back-ups succesvol logs hebben geschreven, en deze strategie zorgt ervoor dat data niet verloren gaat zolang er één back-up overleeft. Dit is de sterkste garantie.
(4) Andere instellingen, zoals acks=2, zijn ook mogelijk, wat een bepaald aantal acks vereist, maar deze strategie wordt over het algemeen zelden gebruikt. |
| buffer.memory | lang | 33554432 | hoog | De producer kan worden gebruikt om de geheugengrootte van de data te cachen. Als de data sneller wordt gegenereerd dan ze naar de broker worden gestuurd, zal de producent een uitzondering blokkeren of gooien, aangeduid met "block.on.buffer.full".
Deze instelling is gerelateerd aan het totale geheugen dat de producent kan gebruiken, maar het is geen harde limiet, aangezien niet al het geheugen dat door de producent wordt gebruikt wordt gebruikt voor caching. Er wordt extra geheugen gebruikt voor compressie (als compressie wordt geïntroduceerd), en een deel wordt gebruikt voor onderhoudsverzoeken. |
| compression.type | String | geen | hoog | Producer is het type compressie dat wordt gebruikt om data te comprimeren. De standaard is ongecomprimeerd. De juiste optiewaarden zijn geen, gzip, snappy.
Compressie wordt het beste gebruikt voor batchverwerking; hoe meer berichten in batches worden verwerkt, hoe beter de compressieprestaties. |
| Herhaalde pogingen | int | 0 | hoog | Het instellen van een waarde groter dan 0 zorgt ervoor dat de client alle data opnieuw verzendt zodra die data faalt. Let op dat deze herpogingen niet verschillen van die wanneer de client een verzendfout ontvangt. Maakt opnieuw pogingen mogelijk om de volgorde van de gegevens te wijzigen; als beide berichtrecords naar dezelfde partitie worden gestuurd, faalt het eerste bericht, het tweede bericht verschijnt eerder dan het eerste bericht. |
| batch.size | int | 16384 | Gemiddeld | De producent zal proberen de berichtrecords te batchen om het aantal verzoeken te verminderen. Dit zal de prestaties tussen client en server verbeteren. Deze configuratie regelt het standaardaantal bytes aan batchverwerkingsberichten.
Er worden geen pogingen gedaan om berichtbytes groter dan dit byte-aantal te verwerken.
Verzoeken die naar brokers worden gestuurd, bevatten meerdere batches, die één verzoek voor elke partitie bevatten.
Kleinere batchwaarden worden minder gebruikt en kunnen de doorvoer verminderen (0 gebruikt alleen batchverwerking). Grotere batchwaarden verspillen meer geheugenruimte, dus je moet geheugen toewijzen aan specifieke batchwaarden. |
| client.id | String | | Gemiddeld | Deze string wordt naar de server gestuurd wanneer een verzoek wordt gedaan. Het doel is om de bron van verzoeken te kunnen traceren, zodat sommige applicaties buiten de IP/Port allowlist informatie kunnen verzenden. Deze app kan elke string instellen omdat deze geen functie heeft behalve opnemen en volgen |
| linger.ms | lang | 0 | Gemiddeld | De producergroep zal alle berichten die tussen het verzoek en het verzenden binnenkomen aggregeren, en registreert een aparte batch verzoeken. Meestal gebeurt dit alleen wanneer het record sneller wordt gegenereerd dan de verzendsnelheid. Onder bepaalde omstandigheden wil de klant echter het aantal verzoeken verminderen, of zelfs tot een matige belasting. Deze opstelling wordt gedaan door een kleine vertraging toe te voegen - d.w.z. in plaats van een record direct te verzenden, wacht de producer op een bepaalde vertragingstijd om andere berichtrecords te kunnen verzenden, die gebatched kunnen worden. Dit kan worden beschouwd als een vergelijkbaar algoritme met TCP Nagle. Deze instelling stelt een hogere latentiegrens voor batching: zodra we de batch.size van een partitie hebben, zal deze onmiddellijk worden verzonden ongeacht deze instelling, maar als we een bericht krijgen met een veel kleiner byte-aantal dan deze instelling, moeten we een specifieke tijd "blijven hangen" om meer berichten te ontvangen. Deze instelling staat standaard op 0, dus geen vertraging. Het instellen van linger.ms=5 zal bijvoorbeeld het aantal verzoeken verminderen, maar tegelijkertijd de vertraging met 5 ms verhogen. |
| max.request.size | int | 1028576 | Gemiddeld | Het maximale aantal aangevraagde bytes. Dit is ook een effectieve dekking voor de maximaal geregistreerde omvang. Opmerking: De server heeft zijn eigen overschrijving van de grootte van berichtrecords, die verschillen van deze instelling. Deze instelling beperkt het aantal verzoeken dat producenten in bulk tegelijk kunnen versturen om een groot aantal verzoeken te voorkomen. |
| receive.buffer.bytes | int | 32768 | Gemiddeld | TCP receivecache-grootte, die wordt gebruikt bij het lezen van data |
| send.buffer.bytes | int | 131072 | Gemiddeld | TCP zendcachegrootte, die wordt gebruikt bij het verzenden van data |
| timeout.ms | int | 30000 | Gemiddeld | Deze configuratie-optie regelt de maximale tijd die de server wacht op bevestiging van volgers. Als het aantal bevestigde verzoeken niet binnen deze tijd is vervuld, wordt een foutmelding teruggegeven. Deze timeoutlimiet wordt aan de serverzijde gemeten en kent geen netwerklatentie inclusief verzoeken |
| block.on.buffer.full | Booleans | true | Laag | Wanneer onze geheugencache leeg is, moeten we stoppen met het ontvangen van nieuwe berichtrecords of het geven van fouten. Standaard staat dit op waar, maar sommige blokkeringen zijn misschien niet de moeite waard om te verwachten, dus het is beter om meteen een foutmelding te geven. Dit is het geval wanneer het op false wordt gezet: de producer geeft een uitzonderingsfout: BufferExhaustedException als het record is verzonden en de cache vol is |
| metadata.fetch.timeout.ms | lang | 60000 | Laag | Het verwijst naar de eerste tijdsgegevens van sommige elementen die we hebben verkregen. Elementen zijn onder andere: onderwerp, host, partities. Deze configuratie verwijst naar de tijd die nodig is om het element succesvol te voltooien volgens de fetch, anders wordt er een uitzondering naar de client gestuurd. |
| metadata.max.age.ms | lang | 300000 | Laag | Tijd in microseconden is het interval waarop we de metadata verplichten bijgewerkt te worden. Zelfs als we geen leiderschapswisselingen bij de opdeling zien. |
| metric.reporters | Lijst | [] | Laag | Een lijst van klassen die worden gebruikt om metrics te meten. Het implementeren van de MetricReporter-interface maakt het mogelijk om klassen toe te voegen die veranderen naarmate nieuwe metrics worden gegenereerd. JmxReporter zal altijd een manier bevatten om JMX-statistieken te registreren |
| metrics.num.samples | int | 2 | Laag | Het aantal steekproeven dat wordt gebruikt om metrics te onderhouden |
| metrics.sample.window.ms | lang | 30000 | Laag | Het Metrics-systeem onderhoudt een configureerbaar aantal samples in een corrigeerbaar venstergrootte. Deze configuratie configureert bijvoorbeeld de venstergrootte. We kunnen twee monsters behouden gedurende de 30 seconden. Wanneer een raam wordt uitgerold, wissen en herschrijven we het oudste raam |
| recoonect.backoff.ms | lang | 10 | Laag | Wanneer de verbinding uitvalt, is de wachttijd wanneer we weer verbinding maken. Dit voorkomt herhaalde clientherverbindingen |
| retry.backoff.ms | lang | 100 | Laag | De wachttijd voordat je een mislukte aanvraag voor producten opnieuw probeert. Voorkom dat je vast komt te zitten in een send-fail dead loop.
|
Geplaatst op 24-06-2021 11:47:12
|
|
|
Huisbaas