Broker Configs
| Lastnina | Privzeto | Opis | | broker.id | | Vsakega posrednika je mogoče identificirati z edinstvenim nenegativnim celoštevilskim ID-jem; Ta ID se lahko uporabi kot "ime" posrednika, njegova prisotnost pa posredniku omogoča migracijo na drug gostitelj/port brez zmede potrošnikov. Lahko izberete katerokoli številko kot ID, dokler je osebna izkaznica edinstvena. | | log.dirs | /tmp/kafka-logs | Pot, kjer Kafka shranjuje podatke. Ta pot ni edinstvena, lahko je večkratna, poti pa je treba ločiti le z vejicami; Kadarkoli se ustvari nova particija, se izbere, da se to stori pod potjo, ki vsebuje najmanjše število particij. | | Pristanišče | 6667 | Strežnik sprejme vrata, na katera se odjemalec poveže | | zookeeper.connect | Null | Format povezave ZooKeeper je: ime gostitelja:port, kjer sta ime gostitelja in port gostitelj in port vozlišča v gruči ZooKeeper. Da bi se lahko povezali z drugimi vozlišči ZooKeeperja, ko kateri od gostiteljev odpove, lahko ustvarite več gostiteljev na naslednji način:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper vam omogoča, da dodate pot "chroot" za shranjevanje vseh kafka podatkov v gruči pod določeno potjo. Ko več Kafka grozdov ali drugih aplikacij uporablja isti ZooKeeper grozd, lahko s to metodo nastavite pot shranjevanja podatkov. To je mogoče izvesti tako, da povezovalni niz oblikujemo takole:
ime gostitelja1:port1,ime gostitelja2:port2,ime gostitelja3:port3/chroot/path
Ta nastavitev shranjuje vse podatke kafka gručev pod /chroot/path path. Upoštevajte, da morate pred začetkom posrednika ustvariti to pot, potrošniki pa morajo uporabljati enak format povezave. | | message.max.bajtov | 1000000 | Največja velikost sporočil, ki jih lahko strežnik prejme. Pomembno je, da so nastavitve potrošnika in proizvajalca glede te lastnosti usklajene, sicer je sporočilo, ki ga objavi proizvajalec, preobsežno za potrošnika. | | num.network.threads | 3 | Število omrežnih niti, ki jih strežnik uporablja za obdelavo omrežnih zahtev; Na splošno ni treba spreminjati te lastnine. | | num.io.threads | 8 | Število vhodno/izhodnih niti, ki jih strežnik uporablja za obdelavo zahtev; Število niti naj bo vsaj enako številu trdih diskov. | | ozadje.teme | 4 | Število niti, uporabljenih za obdelavo v ozadju, kot je brisanje datotek; Ni vam treba spreminjati te nepremičnine. | | queued.max.requests | 500 | Največje število zahtevkov, ki jih lahko obdela vhodno-izhodna nit, preden omrežna nit preneha brati nove zahteve. | | host.name | Null | gostiteljsko ime posrednika; Če je ime gostitelja že nastavljeno, bo posrednik vezan samo na ta naslov; Če ni nastavitve, se poveže z vsemi vmesniki in objavi eno kopijo na ZK | | advertised.host.name | Null | Če je nastavljen, se pošlje proizvajalcem, potrošnikom in drugim posrednikom kot gostiteljsko ime posrednika | | advertised.port | Null | To pristanišče je na voljo proizvajalcem, potrošnikom in drugim posrednikom ter se uporablja za vzpostavitev povezave; Nastavitev je potrebna le, če sta dejanski port in port, ki ga mora strežnik povezati, različna. | | socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Velikost predpomnilnika, ki jo strežnik uporablja za povezave med vtičnicami | | socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF velikost predpomnilnika, ki jo strežnik uporablja za povezovanje z vtičnicami | | socket.request.max.bajtov | 100 * 1024 * 1024 | Največja dovoljena velikost zahteve, ki jo dovoli strežnik; S tem se boste izognili prelivom strežnika, ki bi morali biti manjši od velikosti Java kupa | | num.partitions | 1 | Če število particij ni navedeno pri ustvarjanju teme, bo to privzeto število particij pod temo. | | log.segment.bytes | 1014*1024*1024 | Dnevniki particije teme so shranjeni v številnih datotekah v določeni mapi, ki razdelijo loge particije na segmente; Ta atribut je največja velikost vsake datoteke; Ko dimenzije dosežejo to vrednost, se ustvari nova datoteka. To okolje je mogoče preglasiti z osnovo vsake teme.
Pogled Prijava do hiperpovezave je vidna. | | log.roll.hours | 24 * 7 | Tudi če datoteka ne doseže log.segment.bytes, se nova datoteka ustvari vsakič, ko čas ustvarjanja datoteke doseže to lastnost. To nastavitev je mogoče tudi preglasiti z nastavitvami na ravni tem;
PogledPrijava do hiperpovezave je vidna. | | log.cleanup.policy | Izbriši | | | log.retention.minutes in log.retention.hours | 7 dni | Čas, ko je bila vsaka datoteka dnevnika shranjena pred izbrisom. Privzeti čas shranjevanja podatkov je enak za vse teme.
log.retention.minutes in log.retention.bytes se uporabljata za nastavitev brisanja log datotek, ne glede na to, katera lastnost je bila presežena.
To nastavitev lastnosti je mogoče preklicati, ko je tema v bistvu že določena.
PogledPrijava do hiperpovezave je vidna. | | log.retention.bytes | -1 | Skupna količina podatkov, shranjenih na vsaki particiji pod vsako temo; Upoštevajte, da je to zgornja meja na particijo, zato je to število, pomnoženo s številom particij, skupna količina shranjenih podatkov na temo. Prav tako upoštevajte: če sta nastavljeni tako log.retention.hours kot log.retention.bytes, bo prekoračitev katerega koli od omejitev povzročila izbris segmentne datoteke.
Upoštevajte, da lahko to nastavitev preglasi vsaka tema.
PogledPrijava do hiperpovezave je vidna. | | log.retention.check.interval.ms | 5 minut | Preverite interval med datotekami, segmentiranimi v dnevnik, da ugotovite, ali atributi datotek izpolnjujejo zahteve za brisanje. | | log.cleaner.enable | false | Ko je ta lastnost nastavljena na napačno, bo izbrisana, ko je dnevnik shranjen za največje število časa ali velikosti. Če je nastavljeno na true, se bo zgodilo, ko atribut shranjevanja doseže zgornjo mejoPrijava do hiperpovezave je vidna.。 | | log.cleaner.threads | 1 | Število niti, ki izvajajo stiskanje logaristov | | log.cleaner.io.max.bajtov.na sekundo | Nobena | Največje število vhodno-izhodnih podatkov, ki jih lahko ima čistilec hlodov pri izvajanju zgoščevanja hlodov. Ta nastavitev omejuje čistilca, da ne moti aktivnih storitev zahtev. | | log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indeksira dnevnike med postopkom čiščenja in zmanjšuje velikost uporabljenega predpomnilnika. Najbolje je, da jo nastavite veliko, da zagotovite dovolj pomnilnika. | | log.cleaner.io.buffer.load.factor | 512*1024 | Velikost I/O kosa, potrebnega za čiščenje dnevnikov. Te nastavitve ni treba spreminjati. | | log.cleaner.io.buffer.load.factor | 0.9 | faktor obremenitve zgoščevalne tabele, uporabljene pri čiščenju dnevnikov; Te možnosti ni treba spreminjati. | | log.cleaner.backoff.ms | 15000 | Izvaja se časovni interval, v katerem se hlod očisti | | log.cleaner.min.cleanable.ratio | 0.5 | Ta konfiguracija nadzoruje, kako pogosto stiskalnik hlodov poskuša očistiti hlode (predpostavljenoPrijava do hiperpovezave je vidna.je odprt). Privzeto se izogibajte čiščenju več kot 50 % hlodov. To razmerje je povezano z največjim prostorom, ki ga porabi varnostni dnevnik (50 % dnevnikov je stisnjenih na 50 %). Višja stopnja pomeni manj odpadkov in več prostora, ki ga je mogoče učinkovito odstraniti. To nastavitev je mogoče preglasiti v vsakem tematskem okolju.
PogledPrijava do hiperpovezave je vidna.。 | | log.cleaner.delete.retention.ms | 1 dan | čas shranjevanja; Najdaljši čas za shranjevanje stisnjenih hlodov; To je tudi največji čas, ki ga odjemalec potrebuje za uporabo sporočil, razlika med log.retention.minutes pa je v tem, da eden nadzoruje nestisnjene podatke, drugi pa stisnjene podatke, ki jih prepiše določen čas ob ustvarjanju teme. | | log.index.size.max.bajtov | 10*1024*1024 | Največja velikost na segment loga. Upoštevajte, da če velikost loga doseže to vrednost, je treba generirati nov segment loga, tudi če velikost ne presega omejitve log.segment.bytes. | | log.index.interval.bytes | 4096 | Pri izvajanju pridobivanja morate skenirati najbližji odmik z določeno količino prostora, večja kot je nastavitev, bolje je, običajno uporabite privzeto vrednost | | log.flush.interval.messages | Long.MaxValue | Sinhroniziraj datoteko dnevnika na disk pred zbiranjem sporočil. Ker so diskovne IO operacije počasne, a hkrati nujno sredstvo za "zanesljivost podatkov", preverite, ali je potreben časovni interval za utrjevanje na trdi disk. Če je ta vrednost prevelika, bo to povzročilo predolgo "sinhronizacijo" (IO blokiranje), če je ta vrednost premajhna, bo to povzročilo dolgo obdobje "fsync" (IO blokiranje), če je ta vrednost premajhna, bo povzročilo veliko število "sync" časov, kar pomeni, da ima celotna zahteva odjemalca določeno zamudo, okvara fizičnega strežnika pa bo povzročila izgubo sporočil brez fsync. | | log.flush.scheduler.interval.ms | Long.MaxValue | Preverite, ali so intervali fsync obvezni | | log.flush.interval.ms | Long.MaxValue | Ta številka se uporablja za nadzor časovnega intervala "fsync"; če število sporočil nikoli ne doseže števila sporočil, ki so utrjena na disku, vendar časovni interval od zadnje sinhronizacije diska doseže prag, se sproži tudi sinhronizacija diska. | | log.delete.delay.ms | 60000 | Čas shranjevanja po tem, ko je datoteka izbrisana v indeksu, običajno ni treba spreminjati | | auto.create.topics.enable | true | Ali dovoliti samodejno ustvarjanje tem. Če je to res, bo samodejno ustvaril temo, ki ne obstaja, kadar produkcija ali pridobivanje ne obstajata. V nasprotnem primeru morate uporabiti ukazno vrstico za ustvarjanje teme | | controller.socket.timeout.ms | 30000 | Čas izteka vtičnice, ko krmilnik za upravljanje particij izvede varnostno kopijo. | | controller.message.queue.size | Int.MaxValue | controller-to-broker-channles | | default.replication.factor | 1 | Privzeto število varnostnih kopij se nanaša le na samodejno ustvarjene teme | | replica.lag.time.max.ms | 10000 | Če sledilec v tem času ne pošlje zahteve za priklic, bo vodja sledilca odstranil iz ISR in ga šteje za obešenega | | replica.lag.max.messages | 4000 | Če ima replika več kot to število brez varnostne kopije, bo vodilec odstranil sledilca in ga štel za obešenega | | replica.socket.timeout.ms | 30*1000 | Čas časovne omejitve vodje za zahteve socket omrežja pri varnostnem kopiranju podatkov | | replica.socket.receive.buffer.bytes | 64*1024 | Socket prejme medpomnilnik ob pošiljanju omrežne zahteve vodji med varnostnim kopiranjem | | replica.fetch.max.bajtov | 1024*1024 | Največja vrednost vsakega pridobivanja ob času varnostnega kopiranja | | replica.fetch.min.bytes | 500 | Največja čakalna doba, da podatki dosežejo vodjo, ko vodja odda zahtevo za varnostno kopijo | | replica.fetch.min.bytes | 1 | Najmanjša velikost odgovora po vsakem pridobivanju pri varnostnem kopiranju | | num.replica.fetchers | 1 | Število niti, ki varnostno kopirajo podatke iz vodje | | replica.high.watermark.checkpoint.interval.ms | 5000 | Vsaka replika preverja, kako pogosto se najvišji nivo vode utrjuje | | fetch.purgatory.purge.interval.requests | 1000 | fetch request the purge interval | | producer.purgatory.purge.interval.requests | 1000 | proizvajalec zahteva interval čiščenja | | zookeeper.session.timeout.ms | 6000 | Premor za sejo z oskrbnikom živalskega vrta. | | zookeeper.connection.timeout.ms | 6000 | Najdaljši čas, ki ga odjemalec čaka, da vzpostavi povezavo z Zookeeperjem | | zookeeper.sync.time.ms | 2000 | ZK sledilec najdlje časa zaostaja za vodjo ZK | | controlled.shutdown.enable | true | Ali je mogoče nadzorovati zaprtje posrednika. Če je mogoče, bo posrednik lahko vse vodje preusmeril k drugim posrednikom pred zaključkom nakupa. To zmanjša nedosegljivost med izklopom. | | controlled.shutdown.max.ponovni poskusi | 3 | Število ukazov, ki lahko uspešno izvedejo izklop pred nepopolnim izklopom. | | controlled.shutdown.retry.backoff.ms | 5000 | Čas za izklop med izklopi | | auto.leader.rebalance.enable | true | Če to drži, bo kontrolor samodejno uravnotežil vodstvo posrednikov nad particijami | | leader.imbalance.per.broker.percentage | 10 | Največje razmerje neravnovesja, ki ga dovoljuje vsak posrednik | | leader.imbalance.check.interval.seconds | 300 | Preverite pogostost neravnovesja vodil | | offset.metadata.max.bajtov | 4096 | Omogoča odjemalcem, da shranijo največje število svojih odmikov | | max.connections.per.ip | Int.MaxValue | Največje število povezav na posrednika je mogoče vzpostaviti na vsak IP naslov | | max.connections.per.ip.overrides | | Največja pokritost privzete povezave na IP ali ime gostitelja | | connections.max.idle.ms | 600000 | Omejitev časovne omejitve za prazne priključke | | Zapis.Rol.Jitter. {ms,hours} | 0 | Največje število tresljajev, abstriranih iz logRollTimeMillis | | num.recovery.threads.per.data.dir | 1 | Število niti, ki jih vsaka podatkovna mapa uporablja za beleženje okrevanja | | unclean.leader.election.enable | true | Označuje, ali je mogoče uporabiti nastavitev nereplik v ISR kot vodjo | | delete.topic.enable | false | Možnost brisanja tem | | offsets.topic.num.partitions | 50 | Število particij za temo commita z zamikom. Ker sprememba tega po uvedbi trenutno ni podprta, priporočamo uporabo višje nastavitve za produkcijo (npr. 100-200). | | offsets.topic.retention.minutes | 1440 | Premiki, ki so obstajali dlje od te časovne omejitve, bodo označeni kot čakajoči izbris | | offsets.retention.check.interval.ms | 600000 | Upravljalnik premikov preverja pogostost zastarelih premikov | | offsets.topic.replication.factor | 3 | Število varnostnih kopij offseta teme. Priporočljivo je nastaviti višje številke, da se zagotovi večja razpoložljivost | | offset.topic.segment.bytes | 104857600 | Temo za izravnave. | | offsets.load.buffer.size | 5242880 | Ta nastavitev je povezana z velikostjo serije in se uporablja pri branju iz segmenta zamikov. | | offsets.commit.required.acks | -1 | Število potrditve je treba nastaviti, preden je commit offseta sprejemljiv in ga na splošno ni treba spreminjati |
| Lastnina | Privzeto | Privzeta lastnost strežnika | Opis | | cleanup.policy | Izbriši | log.cleanup.policy | Bodisi "izbriši" ali "stisni"; Ta niz kaže, kako uporabiti stari log del; Privzeta metoda ("delete") bo stari del zavrgla, ko je dosežen čas recikliranja ali omejitev velikosti. "Compact" bo stisnil loge | | delete.retention.ms | 86400000 (24 ur) | log.cleaner.delete.retention.ms | Razlika med log.retention.minutes je v tem, da eden nadzoruje nestisnjene podatke, drugi pa stisnjene podatke. To konfiguracijo je mogoče preglasiti s parametri pripenjanja ob ustvarjanju teme | | flush.messages | Nobena | log.flush.interval.messages | Ta konfiguracija določa časovni interval za prisilitev fsync logov. Na primer, če je ta možnost nastavljena na 1, je po vsakem sporočilu potrebna fsync, če pa na 5, je fsync potrebna za vsakih 5 sporočil. Na splošno je priporočljivo, da te vrednosti ne nastavljate. Nastavitev tega parametra zahteva potreben kompromis med "zanesljivostjo podatkov" in "zmogljivostjo". Če je ta vrednost prevelika, bo povzročila dolgo časa za "fsync" vsakič (IO blocking), če pa je ta vrednost premajhna, bo povzročila veliko število "fsync", kar pomeni tudi določeno zakasnitev v celotni zahtevi odjemalca. Fizična okvara strežnika povzroči, da se sporočila izgubijo brez fsync. | | flush.ms | Nobena | log.flush.interval.ms | Ta konfiguracija se uporablja za pripenjanje časovnega intervala med prisilnim fsync logom na disk; Na primer, če je nastavljen na 1000, je fsync obvezen vsakih 1000 ms. Ta možnost na splošno ni priporočljiva | | index.interval.bytes | 4096 | log.index.interval.bytes | Privzeta nastavitev zagotavlja, da sporočilo dodamo indeks vsakih 4096 bajtov, več indeksov pa približa branje sporočilu, vendar se velikost indeksa poveča. Ta možnost običajno ni potrebna | | max.message.bytes | 1000000 | max.message.bytes | Največja velikost kafka dodanega sporočila. Upoštevajte, da če povečate to velikost, morate povečati tudi velikost pridobivanja vašega potrošnika, da lahko uporabnik pridobi sporočila do teh največjih velikosti. | | min.cleanable.dirty.ratio | 0.5 | min.cleanable.dirty.ratio | Ta konfiguracija nadzoruje, kako pogosto kompresor hlodov poskuša očistiti hlode. Privzeto se bodo izognili hlodom s stopnjo stiskanja nad 50 %. To razmerje preprečuje največjo izgubo prostora | | min.insync.replicas | 1 | min.insync.replicas | Ko je producent nastavljen na request.required.acks na -1, min.insync.replicas določi minimalno število replik (vsak zapis v repici mora biti uspešen), in če tega števila ne dosežemo, proizvajalec ustvari izjemo. | | retention.bytes | Nobena | log.retention.bytes | Če uporabljate politiko zadrževanja "izbriši", se ta konfiguracija nanaša na največjo velikost, ki jo lahko dnevnik doseže, preden je izbrisan. Privzeto ni omejitve velikosti, ampak le časovna omejitev | | retention.ms | 7 dni | log.retention.minutes | Če uporabljate politiko shranjevanja "izbriši", se ta konfiguracija nanaša na čas, ko je bil dnevnik shranjen pred zapisom izbrisa. | | segment.bytes | 1GB | log.segment.bytes | Pri Kafki so hlodi shranjeni v kosih, ta konfiguracija pa se nanaša na velikost hlodov, razdeljenih na dele | | segment.index.bytes | 10MB | log.index.size.max.bajtov | Ta konfiguracija je približno velikosti indeksne datoteke, ki je preslikana med premiki in lokacije datotek; Te konfiguracije običajno ni treba spreminjati | | segment.ms | 7 dni | log.roll.hours | Tudi če datoteka log chunk ne doseže velikosti, ki jo je treba izbrisati ali stisniti, bo ob dosegu zgornje meje log čas prisiljen ustvariti novo datoteko log chunk | | segment.jitter.ms | 0 | Zapis.Rol.Jitter. {ms,hours} | Največje tresljaje za odštevanje od logRollTimeMillis. |
Potrošniške konfiguracije
| Lastnina | Privzeto | Opis | | group.id | | Niz, ki enolično identificira skupino, v kateri se nahaja potrošniški proces, in če je nastavljen isti ID skupine, to pomeni, da ti procesi pripadajo isti skupini uporabnikov | | zookeeper.connect | | Določite niz povezave Zookeeper, format je ime gostitelja:port, tukaj sta gostitelj in port tako gostitelj kot port strežnika Zookeeper, da ne izgubite stika po izpadu Zookeeper računalnika, lahko določite več imen gostitelja:portov, pri čemer uporabite vejico kot ločevanje:
ime gostitelja1:port1,ime gostitelja2:port2,ime gostitelja3:port3
Pot ZooKeeperja lahko dodate v ZooKeeperjev povezovalni niz, ki se uporablja za shranjevanje lastnih podatkov, na način:
ime gostitelja1:port1,ime gostitelja2:port2,ime gostitelja3:port3/chroot/path | | consumer.id | Null | Nastavitev ni potrebna in se običajno generira samodejno | | socket.timeout.ms | 30*100 | Časovne omejitve za omrežne zahteve. Prava omejitev časovne omejitve je max.fetch.wait+socket.timeout.ms | | socket.receive.buffer.bytes | 64*1024 | Socket se uporablja za sprejem velikosti predpomnilnika omrežnih zahtev | | fetch.message.max.bajtov | 1024*1024 | Največje število bajtov na sporočilo za priklic na zahtevo za priklic. Ti bajti bodo nadzorovani v pomnilniku, ki se uporablja za vsako particijo, zato bo ta nastavitev nadzorovala količino pomnilnika, ki ga uporablja uporabnik. Velikost zahteve za pridobivanje mora biti vsaj enaka največji dovoljeni velikosti sporočila, ki jo dovoli strežnik, sicer je velikost sporočila, ki ga lahko proizvajalec pošlje, večja od velikosti, ki jo lahko uporabnik porabi. | | num.consumer.fetchers | 1 | Število retcher niti, uporabljenih za pridobivanje podatkov | | auto.commit.enable | true | Če je to res, se odmik sporočila, ki ga uporabnik pridobi, samodejno sinhronizira s Zookeeperjem. Ta zamik commita bo uporabil novi uporabnik, ko se proces zatakne | | auto.commit.interval.ms | 60*1000 | Frekvenca, s katero potrošnik pošilja offset oskrbniku živalskega vrta, je v nekaj sekundah | | queued.max.message.chunks | 2 | Največje število sporočil, ki se uporabljajo za predpomnjenje za uporabo. Vsak del mora biti enak fetch.message.max.bajtom | | rebalance.max.ponovni poskusi | 4 | Ko se v skupino potrošnikov doda nov potrošnik, skupina potrošnikov poskuša uravnotežiti število particij, dodeljenih vsakemu potrošniku. Če se pobiranje potrošnikov spremeni, to uravnoteženje ne uspe in se ponovno vključi med izvajanjem dodelitve | | fetch.min.bytes | 1 | Minimalno število bajtov, ki jih mora strežnik vrniti z vsako zahtevo za pridobivanje podatkov. Če ni vrnjenih dovolj podatkov, zahteva počaka, da je dovolj podatkov vrnjenih. | | fetch.wait.max.ms | 100 | Če ni dovolj podatkov za izpolnitev fetch.min.bytes, se ta konfiguracija nanaša na največje število časa, ki ga strežnik blokira, preden odgovori na zahtevo za priklic. | | rebalance.backoff.ms | 2000 | Čas za odhod pred ponovnim poskusom reblance | | refresh.leader.backoff.ms | 200 | Obstaja čas za čakanje, preden poskušamo ugotoviti, ali je vodja delitve izgubil vodstvo | | auto.offset.reset | največji | Če v Zookeeperju ni inicializiranega zamika, če je zamik odziv na naslednjo vrednost:
najmanjši: Samodejno ponastavitev zamika na najmanjši zamik
največje: Samodejni ponastavitev, zamik na največje
Vse ostalo: Potrošniku vrže izjemo | | consumer.timeout.ms | -1 | Če sporočilo ni na voljo, tudi po določenem času čakanja, se sproži izjema časovne omejitve | | izključuj.internal.topics | true | Ali naj sporočila notranjih tem razkrijejo potrošnikom | | paritition.assignment.strategy | Območje | Izberite politiko za dodeljevanje particij potrošniškemu toku, po želji obseg, roundrobin | | client.id | Vrednost ID skupine | je uporabniško specifičen niz, ki pomaga slediti klicem v vsaki zahtevi. Logično bi moral potrditi aplikacijo, ki je generirala zahtevo | | zookeeper.session.timeout.ms | 6000 | Časovne omejitve za seje z oskrbnikom živalskega vrta. Če potrošnik v tem času ne pošlje sporočila o srčnem utripu oskrbniku živalskega vrta, se šteje, da je sporočilo prekinjeno in se ustvari reblance | | zookeeper.connection.timeout.ms | 6000 | Največja čakalna doba, da stranka vzpostavi povezavo z Zookeeperjem | | zookeeper.sync.time.ms | 2000 | Privrženci ZK lahko zaostajajo za vodjo ZK največ časa | | offsets.storage | Oskrbnik živalskega vrta | Prostori za shranjevanje offsetov: Zookeeper ali Kafka | | offset.channel.backoff.ms | 1000 | Čas ponovnega povezovanja s kanalom offsetov ali ponovnega poskusa zahteve za pridobivanje ali potrjevanje neuspešnega offseta | | offsets.channel.socket.timeout.ms | 10000 | Omejitev časovne omejitve vtičnice za odziv na odgovor po zahtevi za pridobivanje ali potrditve ob branju zamika. To časovno omejitev uporablja zahteva consumerMetadata za zahtevo za upravljanje offsetov | | offsets.commit.max.ponovni poskusi | 5 | Število ponovitev commita offseta. Ta ponovni poskus se uporablja le za offset commit-e med izklopom. njega | | dual.commit.enabled | true | Če uporabiš "kafka" kot offsets.storage, lahko offset potrdiš v Zookeeperju dvakrat (in enkrat v Kafka). To je nujno pri migraciji iz offset pomnilnika, ki temelji na Zookeeperju, na Kafka-osnovo offsetnega shranjevanja. Za katerokoli skupino potrošnikov je varno priporočilo, da to možnost izklopijo, ko je migracija končana | | partition.assignment.strategy | Območje | Izberite med politikama "range" in "roundrobin" kot politiko za dodeljevanje particij potrošniškim podatkovnim tokovom; Krožni dodeljevalnik particij dodeli vse razpoložljive particije kot tudi vse razpoložljive potrošniške niti. Particijsko zanko bo dodelil potrošniški niti. Če so vse potrošniške instance naročene na določeno, se particije razdelijo na deterministične porazdelitve. Strategija razporejanja po krožnem sistemu je mogoča le, če so izpolnjeni naslednji pogoji: (1) Vsaka tema ima enako število podatkovnih tokov na število uporabnikov. (2) Zbirka naročenih tem je določena za vsak primer potrošnika v skupini potrošnikov. |
Konfiguracije proizvajalcev
| Lastnina | Privzeto | Opis | | metadata.broker.list | | Postrežite samostojno. Producer se uporablja le za pridobivanje metapodatkov (teme, particije, replike). Povezava z vtičnico za pošiljanje dejanskih podatkov bo vzpostavljena na podlagi vrnjenih metapodatkov. Format je:
gostitelj1:port1,gostitelj2:port2
Ta seznam je lahko podseznam posrednikov ali VIP oseba, ki kaže na posrednike | | request.required.acks | 0 | Ta konfiguracija je potrditvena vrednost, ki označuje, kdaj se zahteva za produce šteje za dokončano. Zlasti, koliko drugih posrednikov je moralo podatke vključiti v svoje dnevnike in te informacije potrditi svojemu vodji. Tipične vrednosti vključujejo:
0: Pomeni, da proizvajalec nikoli ne čaka na potrditev posrednika (enako vedenje kot pri 0,7). Ta možnost zagotavlja najmanjšo zakasnitev, a hkrati največje tveganje (ker se podatki izgubijo, ko strežnik preneha delovati).
1: Označuje, da je replika vodje prejela potrditev podatkov. Ta možnost ima nizko zakasnitev in zagotavlja, da strežnik potrdi, da je bila prejeta.
-1: Producent dobi potrditev, da so vse sinhronizirane replike prejele podatke. Zakasnitev je največja, vendar ta metoda ne odpravi popolnoma tveganja izgube sporočil, saj je število sinhroniziranih replik lahko 1. Če želite zagotoviti, da nekatere replike prejmejo podatke, nastavite možnost min.insync.replicas v nastavitvah na ravni teme. Preberite oblikovalsko dokumentacijo za bolj poglobljeno razpravo. | | request.timeout.ms | 10000 | Posrednik se trudi po najboljših močeh implementirati zahtevo request.required.acks, sicer bo napaka poslana stranki | | producer.type | sinhronizacija | Ta možnost določa, ali je sporočilo poslano asinhrono v ozadni niti. Pravilne vrednosti:
(1) asinhron: asinhrono pošiljanje
(2) sinhronizacija: Sinhronizirano pošiljanje
Z nastavitvijo producenta na asinhrono lahko zahteve obdelujemo v serijah (kar je dobro za večjo prepustnost), vendar to hkrati ustvarja možnost, da odjemalski stroj izgubi neposlane podatke | | serializer.class | kafka.serializer.DefaultEncoder | Kategorija serializacije sporočila. Privzeti kodirnik vnese en bajt[] in vrne isti bajt[] | | key.serializer.class | | Razred serializacije za ključne besede. Če to ni podano, je privzeto tako, da se sporočilo ujema | | partitioner.class | kafka.producer.DefaultPartitioner | razred partitioner za razdelitev sporočil med podtemami. Privzeti razdeljevalnik temelji na hash tabeli ključa | | compression.codec | Nobena | Ta parameter lahko nastavi kodek za stiskanje podatkov, ki ga je mogoče izbrati kot "none", "gzip", "snappy". | | compressed.topics | Null | Ta parameter lahko uporabimo za določitev, ali so določene teme stisnjene. Če je stisnjen kodek kodek, ki ni NoCompressCodec, se ti kodeki uporabijo na podatkih določenih tem. Če je seznam stisnjenih tem prazen, uporabite specifičen stisnjen kodek za vse teme. Če je stisnjen kodek NoCompressionCodec, stiskanje ni na voljo za vse teme. | | message.send.max.retries | 3 | Ta parameter povzroči, da proizvajalec samodejno ponovno poskusi neuspešne zahteve za pošiljanje. Ta parameter določa število ponovitev. Opomba: Nastavitev vrednosti, ki ni 0, povzroči ponavljanje določenih omrežnih napak: povzroči pošiljanje in izgubo potrditve | | retry.backoff.ms | 100 | Pred vsakim ponovnim poskusom producent posodobi metapodatke ustrezne teme, da preveri, ali je novi vodja dodeljen. Ker izbira vodje traja nekaj časa, ta možnost določa, koliko časa mora producent čakati, preden posodobi metapodatke. | | topic.metadata.refresh.interval.ms | 600*1000 | Producent običajno posodablja metapodatke teme v nekaterih scenarijih neuspeha (manjka particija, vodnik ni na voljo itd.). Imel bo reden cikel. Če nastavite na negativno vrednost, se metapodatki posodobijo le, če ne uspe. Če je nastavljena na 0, se metapodatki posodobijo po vsakem sporočilu (ta možnost ni priporočljiva, saj sistem porabi preveč). Pomembno: Posodobitve se zgodijo šele po pošiljanju sporočila, zato če producent sporočila nikoli ne pošlje, metapodatki niso posodobljeni. | | queue.buffering.max.ms | 5000 | Največji časovni interval, v katerem uporabnik shranjuje podatke, ko je uporabljen asinhroni način. Na primer, če je sporočilo nastavljeno na 100, se sporočila v 100 ms obdelujejo v serijah. To bo izboljšalo prepustnost, a povečalo zakasnitev zaradi predpomnjenja. | | queue.buffering.max.messages | 10000 | Pri uporabi asinhronega načina je treba blokirati največje število neposlanih sporočil, ki jih je mogoče shraniti v čakalno vrsto pred producentom ali izgubiti podatke | | batch.num.messages | 200 | Pri asinhronem načinu lahko skupinsko obdelate največje število sporočil. Ali pa je število sporočil prispelo na spletu ali queue.buffer.max.ms prispelo in producent jih bo obdelal | | send.buffer.bytes | 100*1024 | Velikost predpomnilnika za pisanje v vtičnici | | client.id | “” | Ta ID odjemalca je uporabniško specifičen niz, ki je vključen v vsako zahtevo za sledenje klicu, in logično bi moral lahko potrditi, da je aplikacija opravila zahtevo. |
Konfiguracije proizvajalcev
| Ime | Vrsta | Privzeto | Pomen | Opis | | boostrap.servers | Seznam | | visoko | Host/port skupina za vzpostavitev povezave s Kafka grozdom. Podatki se bodo enakomerno naložili na vse strežnike, ne glede na to, kateri strežnik je namenjen zagonu. Ta seznam vpliva le na inicializirane gostitelje (ki se uporabljajo za odkrivanje vseh strežnikov). Ta format seznama:
host1:port1,host2:port2,...
Ker se ti strežniki uporabljajo le za inicializacijo povezav in odkrivanje vseh članov gruče (ki se lahko dinamično spreminjajo), ta seznam ne potrebuje vsebovati vseh strežnikov (morda želite več kot en strežnik, čeprav je v tem primeru lahko en strežnik nedosegljiv). Če se na tem seznamu ne pojavi noben strežnik, pošiljanje podatkov ne bo uspelo, dokler seznam ni na voljo. | | Acks | Struna | 1 | visoko | Proizvajalec potrebuje signal strežnika za potrditev sprejema po prejemu podatkov, ta konfiguracija pa se nanaša na to, koliko takšnih potrditvenih signalov izvajalec potrebuje. Ta konfiguracija dejansko predstavlja razpoložljivost varnostnih kopij podatkov. Naslednje nastavitve so pogoste možnosti:
(1) acks=0: Nastavljeno na 0 pomeni, da producentu ni treba čakati na potrditev prejetih informacij. Replika bo takoj dodana v predpomnilnik vtičnice in obravnavana kot poslana. V tem primeru ni zagotovila, da je strežnik uspešno prejel podatke, ponovni poskus konfiguracije ne bo deloval (ker odjemalec ne ve, ali je spodletelo), zamik povratne informacije pa bo vedno nastavljen na -1.
(2) acks=1: To pomeni, da vsaj počakamo, da vodja uspešno zapiše podatke v lokalni dnevnik, ne pa, da vsi sledilci uspešno zapišejo. V tem primeru, če sledilec ne uspe varnostno kopirati podatkov in vodja ponovno prekine klic, bo sporočilo izgubljeno.
(3) acks=all: To pomeni, da mora vodja počakati, da vse varnostne kopije uspešno zapišejo dnevnike, ta strategija pa bo zagotovila, da podatki ne bodo izgubljeni, dokler ena varnostna kopija preživi. To je najmočnejša garancija.
(4) Možne so tudi druge nastavitve, kot je acks=2, ki zahtevajo določeno število acks, vendar se ta strategija običajno redko uporablja. | | buffer.memory | dolgo | 33554432 | visoko | Producent se lahko uporabi za predpomnjenje velikosti pomnilnika podatkov. Če so podatki ustvarjeni hitreje, kot so poslani posredniku, bo proizvajalec blokiral ali vrgel izjemo, označeno z "block.on.buffer.full".
Ta nastavitev bo povezana s skupnim pomnilnikom, ki ga lahko proizvajalec uporabi, vendar ni stroga meja, saj ni ves pomnilnik, ki ga proizvajalec uporablja za predpomnjenje. Nekaj dodatnega pomnilnika se uporablja za stiskanje (če je stiskanje uvedeno), del pa za zahteve za vzdrževanje. | | kompresija.tip | Struna | Nobena | visoko | Producent je vrsta kompresije, ki se uporablja za stiskanje podatkov. Privzeto je nekompresirano. Pravilne vrednosti možnosti so none, gzip, snappy.
Stiskanje je najbolje za serijsko obdelavo; več sporočil kot je obdelanih v serijah, boljša je zmogljivost stiskanja. | | Ponovni poskusi | int | 0 | visoko | Nastavitev vrednosti večje od 0 bo povzročila, da odjemalec ponovno pošlje vse podatke, ko ti podatki odpovejo. Upoštevajte, da se ti ponovni poskusi ne razlikujejo od tistih, ko odjemalec prejme napako pošiljanja. Omogoča morebitno spremembo zaporedja podatkov, če sta oba zapisa sporočila poslana na isto particijo, prvo sporočilo ne uspe, drugo sporočilo pa se pojavi prej kot prvo. | | batch.size | int | 16384 | Srednja | Proizvajalec bo poskušal združiti zapise sporočil v skupinah, da zmanjša število zahtev. To bo izboljšalo zmogljivost med odjemalcem in strežnikom. Ta konfiguracija nadzoruje privzeto število bajtov sporočil za serijsko obdelavo.
Ni poskusov obdelave bajtov sporočil, večjih od tega števila bajtov.
Zahteve, poslane posrednikom, bodo vsebovale več serij, ki bodo vsebovale eno zahtevo za vsako particijo.
Manjše vrednosti za serije se uporabljajo manj in lahko zmanjšajo prepustnost (0 bo uporabljalo samo serijsko obdelavo). Večje serijske vrednosti zapravljajo več pomnilniškega prostora, zato morate pomnilnik razporediti za določene vrednosti serij. | | client.id | Struna | | Srednja | Ta niz se strežniku pošlje, ko je oddana zahteva. Namen je slediti viru zahtev, da se nekaterim aplikacijam zunaj IP/seznama dovoljenj za vrata omogoči pošiljanje informacij. Ta aplikacija lahko nastavi katerikoli niz, ker nima drugega funkcionalnega namena kot snemanje in sledenje | | linger.ms | dolgo | 0 | Srednja | Skupina producentov bo združila vsa sporočila, ki prispejo med zahtevo in pošiljanjem, ter zabeležila ločen sklop zahtev. Običajno se to zgodi le, če je zapis ustvarjen hitreje od hitrosti pošiljanja. Vendar pa bo pod določenimi pogoji naročnik želel zmanjšati število zahtev ali celo na zmerno obremenitev. Ta nastavitev se izvede z dodajanjem majhne zakasnitve – torej namesto takojšnjega pošiljanja zapisa producent počaka določen čas zamika, da lahko pošljejo druge zapise sporočil, ki jih je mogoče združiti v skupine. To lahko štejemo za podoben algoritem kot TCP Nagle. Ta nastavitev določa višjo mejo zakasnitve za skupinsko skupino: ko dobimo velikost particije v seriji, jo bo takoj poslala ne glede na to nastavitev, če pa prejmemo sporočilo z veliko manjšim številom bajtov kot ta nastavitev, moramo "zadržati" določen čas, da dobimo več sporočil. Ta nastavitev je privzeto na 0, torej brez zamika. Nastavitev linger.ms=5, na primer, zmanjša število zahtev, hkrati pa poveča zakasnitev za 5 ms. | | max.request.size | int | 1028576 | Srednja | Največje število zahtevanih bajtov. To je tudi učinkovita pokritost za največjo zabeleženo velikost. Opomba: Strežnik ima svojo lastno preglasitev velikosti zapisov sporočil, ki se razlikujejo od te nastavitve. Ta nastavitev omejuje število zahtevkov, ki jih lahko proizvajalci pošljejo v večjem številu hkrati, da preprečijo veliko število zahtev. | | receive.buffer.bytes | int | 32768 | Srednja | Velikost TCP sprejemnega predpomnilnika, ki se uporablja pri branju podatkov | | send.buffer.bytes | int | 131072 | Srednja | Velikost TCP predpomnilnika za pošiljanje, ki se uporablja pri pošiljanju podatkov | | timeout.ms | int | 30000 | Srednja | Ta konfiguracijska možnost nadzoruje najdaljši čas, ki ga strežnik čaka na potrditev s strani spremljevalcev. Če število potrjenih zahtevkov ni izpolnjeno v tem času, se vrne napaka. Ta časovna omejitev se meri na strežniški strani in nima omrežne zakasnitve, vključno z zahtevami | | block.on.buffer.full | Boolean | true | nizko | Ko nam zmanjka pomnilniškega predpomnilnika, moramo prenehati prejemati nove zapise sporočil ali vržeti napake. Privzeto je to nastavljeno na true, vendar morda ni vredno pričakovati blokade, zato je bolje, da takoj vržete napako. To je primer, ko je nastavljen na false: proizvajalec sproži napako z izjemo: BufferExhaustedException, če je bil zapis poslan in je predpomnilnik poln | | metadata.fetch.timeout.ms | dolgo | 60000 | nizko | Nanaša se na podatke o prvem času nekaterih elementov, ki smo jih pridobili. Elementi vključujejo: temo, gostitelja, particije. Ta konfiguracija se nanaša na čas, potreben za uspešno dokončanje elementa glede na fetch, sicer bo odjemalcu poslana izjema. | | metadata.max.age.ms | dolgo | 300000 | nizko | Čas v mikrosekundah je interval, v katerem prisilimo posodobitev metapodatkov. Tudi če ne vidimo nobenih sprememb vodstva pri delitvi. | | metric.reporters | Seznam | [] | nizko | Seznam razredov, ki se uporabljajo za merjenje metrik. Implementacija vmesnika MetricReporter bo omogočila dodajanje razredov, ki se spreminjajo, ko se generirajo nove metrike. JMXReporter bo vedno vključil način za registracijo statistike JMX | | metrics.num.samples | int | 2 | nizko | Število vzorcev, uporabljenih za vzdrževanje metrik | | metrics.sample.window.ms | dolgo | 30000 | nizko | Sistem Metrics vzdržuje nastavljivo število vzorcev v popravljivi velikosti okna. Ta konfiguracija na primer konfigurira velikost okna. Morda bomo ohranili dva vzorca v obdobju 30 sekund. Ko se okno razširi, izbrišemo in prepišemo najstarejše okno | | recoonect.backoff.ms | dolgo | 10 | nizko | Ko povezava odpove, čas čakanja, ko se ponovno povežemo. S tem se izognete ponavljajočim se ponovnim povezavam s strankami | | retry.backoff.ms | dolgo | 100 | nizko | Čakalni čas pred ponovnim poskusom neuspešne zahteve za sadje in zelenjavo. Izogibajte se zastoju v mrtvem krogu pošiljanja in neuspeha.
|
|
Objavljeno na 24. 06. 2021 11:47:12
|
|
|
Najemodajalec