Broker Configs
| Tulajdon | Alapértelmezett | Leírás | | broker.id | | Minden bróker egyedi, nem negatív egész számazonosítóval azonosítható; Ez az azonosító használható a bróker "neveként", és létezése lehetővé teszi a bróker számára, hogy a felhasználók összezavarása nélkül átmigráljon egy másik hosztra/portra. Bármilyen számot választhatsz azonosítóként, amennyiben az egyedi azonosító. | | log.dirs | /tmp/kafka-logs | Az út, ahol a Kafka adatokat tárol. Ez az út nem egyedi, lehet többszörös, és az utakat csak vesszóval kell elválasztani; Amikor új partíciót hoznak létre, azt az út alatt választják, amely a legkevesebb partíciót tartalmazza. | | Kikötő | 6667 | A szerver elfogadja azt a portot, amelyhez a kliens csatlakozik | | zookeeper.connect | nulla | A ZooKeeper kapcsolati lánc formátuma: hostname:port, ahol a hostname és port a ZooKeeper klaszterben lévő csomópont hosztoda és portja. Ahhoz, hogy csatlakozzon más ZooKeeper csomópontokhoz, amikor egy host leáll, több haszt is létrehozhatsz az alábbiak szerint:
hostname1:port1, hostname2:port2, hostname3:port3.
A ZooKeeper lehetővé teszi, hogy hozzáadj egy "chroot" útvonalat, hogy az összes kafka adatot a klaszterben egy adott út alatt tárold. Ha több Kafka klaszter vagy más alkalmazás ugyanazt a ZooKeeper klasztert használja, ezzel a módszerrel beállíthatod az adattároló útvonalat. Ez megvalósítható úgy, hogy a kapcsolati láncsort így formázzuk:
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path
Ez a beállítás az összes kafka klaszteradatot a /chroot/path útvonal alatt tárolja. Fontos megjegyezni, hogy a bróker indítása előtt létre kell hoznod ezt az útvonalat, és a fogyasztóknak ugyanazt a kapcsolati formátumot kell használniuk. | | message.max.bájt | 1000000 | Az üzenetek maximális mérete, amit egy szerver fogadhat. Fontos, hogy a fogyasztó és a gyártó beállításait ezzel a tulajdonsággal kapcsolatban szinkronizálják, különben a gyártó által közzétett üzenet túl nagy lesz a fogyasztó számára. | | num.network.threads | 3 | A szerver által használt hálózati szálak száma a hálózati kérések feldolgozására; Általában nem kell megváltoztatnod ezt az ingatlant. | | num.io.threads | 8 | A szerver által a kérések feldolgozásához használt I/O szálak száma; A szálak számának legalább annyinak kell lennie, mint a merevlemezek száma. | | background.threads | 4 | A háttérfeldolgozáshoz, például fájltörléshez használt szálak; Nem kell megváltoztatnod ezt a tulajdonságot. | | queued.max.requests | 500 | A maximális kérések száma, amelyeket egy I/O szál feldolgozásához sorba kell állítani, mielőtt egy hálózati szál abbahagyná az új kérések olvasását. | | host.name | nulla | a bróker gépneve; Ha a hosztnév már be van állítva, a bróker csak ehhez a címhez lesz kötve; Ha nincs beállítás, minden interfészhez kötődik, és egy példányt publikál a ZK-nak | | advertised.host.name | nulla | Ha beállított, akkor a bróker hostneveként elküldik a producernek, fogyasztóknak és más közvetítőknek | | advertised.port | nulla | Ezt a portot termelőknek, fogyasztóknak és más közvetítőknek adják, és kapcsolat kialakítására használják; Csak akkor kell beállítani, ha a tényleges port és a szervernek kötendő portja eltér. | | socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF Cache méret, amelyet a szerver használ socket-kapcsolatok létrehozásához | | socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF cache méret, amelyet a szerver használ socketekhez való csatlakozásra | | socket.request.max.bájt | 100 * 1024 * 1024 | A szerver által engedélyezett maximális kérésméret; Ez elkerüli a szervertúlcsordulásokat, amelyek kisebbek lehetnek, mint a Java halom mérete | | num.partitions | 1 | Ha a téma létrehozásakor nem megadják a partíciók számát, akkor ez lesz a téma alapértelmezett partícióinak száma. | | log.segment.bytes | 1014*1024*1024 | A témaosztó naplói sok fájlban tárolódnak egy adott könyvtárban, amely a partíció naplóit szegmensekre osztja; Ez az attribútum minden fájl maximális mérete; Amikor a dimenziók elérik ezt az értéket, új fájl jön létre. Ezt a beállítást felülírhatja az egyes témakör alapjai.
Kilátás A hiperlink bejelentkezés látható. | | log.roll.hours | 24 * 7 | Még ha a fájl nem is éri el a log.segment.bytes-t, új fájl keletkezik, amikor a fájlkészítési idő eléri ezt a tulajdonságot. Ezt a beállítást témaszintű beállítások is felülírhatják;
NézetA hiperlink bejelentkezés látható. | | log.cleanup.policy | Törlés | | | log.retention.minutes és log.retention.hours | 7 nap | Az az idő, amikor minden naplófájlt elmentettek, mielőtt törölték volna. Az alapértelmezett adatmegtakarítási idő minden témánál ugyanaz.
a log.retention.minutes és a log.retention.bytes is a naplófájlok törlésének beállítására szolgál, függetlenül attól, melyik tulajdonságot túlcsordulták.
Ez a tulajdonság beállítás felülírható, ha a téma gyakorlatilag be van állítva.
NézetA hiperlink bejelentkezés látható. | | log.retention.bytes | -1 | Az egyes fektívák által elmentett összes adatmennyiség minden témában; Fontos megjegyezni, hogy ez a felső határ egy partíciónként, tehát ezt a számot a partíciók számával megszorozva a témánként tárolt összes adatmennyiség. Továbbá megjegyzés: Ha mind a log.retention.hours, mind a log.retention.bytes be van állítva, ha bármelyik határt túllépik, egy szegmensfájl törlését eredményezi.
Fontos megjegyezni, hogy ezt a beállítást minden téma felülírhatja.
NézetA hiperlink bejelentkezés látható. | | log.retention.check.interval.ms | 5 perc | Ellenőrizze a naplószegmentált fájlok közötti intervallumot, hogy megállapítsa, megfelelnek-e a fájl attribútumok a törlési követelményeknek. | | log.cleaner.enable | false | Ha ezt a tulajdonságot hamisnak állítják, törlik, amikor a naplót maximális ideig vagy méretben tárolják. Ha igazra állítva állítják, akkor történik, amikor a mentési attribútum eléri a felső határtA hiperlink bejelentkezés látható.。 | | log.cleaner.threads | 1 | A log tömörítést végző szálak száma | | log.cleaner.io.max.bytes.per.másodperc | Egyik sem | A naplótisztító maximális I/O-száma, amit egy naplótömörítés során megtehet. Ez a beállítás korlátozza a tisztítót, hogy ne zavarja az aktív kérési szolgáltatásokat. | | log.cleaner.io.buffer.size | 500*1024*1024 | A Log Cleaner indexeli a naplókat a tisztítás során, és csökkenti a használt gyorsítótár méretét. A legjobb, ha nagyra állítod, hogy elegendő memóriát biztosítson. | | log.cleaner.io.buffer.load.factor | 512*1024 | Az I/O darab mérete, amely a fatörzs tisztításához szükséges. Nem kell ezt a beállítást megváltoztatnod. | | log.cleaner.io.buffer.load.factor | 0.9 | a naplótisztításnál használt hash tábla terhelési tényezője; Ezt az opciót nem kell megváltoztatnod. | | log.cleaner.backoff.ms | 15000 | Az időintervallum, amely alatt a naplót megtisztítják, elvégezzük | | log.cleaner.min.cleanable.ratio | 0.5 | Ez a konfiguráció szabályozza, hogy a rönnyalapító milyen gyakran próbálja megtisztítani a rönköket (feltételezettA hiperlink bejelentkezés látható.nyitva van). Alapértelmezés szerint kerüld a rönkök több mint 50%-át takarítani. Ez az arány a tartalék napló maximális elfoglalt helyéhez kötött (a naplók 50%-a 50%-ban tömörödik). A magasabb árfolyam kevesebb hulladékot és hatékonyabban takaríthat ki több helyet. Ez a beállítás felülírható minden témakörnyezetben.
NézetA hiperlink bejelentkezés látható.。 | | log.cleaner.delete.retention.ms | 1 nap | tárolási idő; A maximális idő a tömörített naplók tárolására; Ez egyben a kliens maximális ideje az üzenetek fogyasztására, és a log.retention.minutes közötti különbség az, hogy az egyik a tömörítetlen adatokat, a másik pedig a tömörített adatokat irányítja, amelyet a téma létrehozásakor megadott idő felülír. | | log.index.size.max.bájt | 10*1024*1024 | A maximális méret egy log szegmensre. Fontos megjegyezni, hogy ha a naplóméret eléri ezt az értéket, akkor új log szegmensre van szükség, még akkor is, ha a méret nem haladja meg a log.segment.bytes korlátot. | | log.index.interval.bytes | 4096 | Fetch végrehajtáskor a legközelebbi eltolódást kell beszkennelni egy bizonyos helygel, minél nagyobb a beállítás, annál jobb, általában használd az alapértelmezett értéket | | log.flush.interval.messages | Long.MaxValue | Naplófájlt "szinkronizáljanak" a lemezlel, mielőtt üzeneteket halmoztak volna fel. Mivel a lemez IO műveletek lassúak, de egyben az "adatmegbízhatóság" szükségessége is, ellenőrizd, szükséges-e a merevlemezre való kötés időintervallum. Ha ez az érték túl nagy, túl hosszú "szinkron" időt (IO blokkol) eredményez, ha túl kicsi, hosszú ideig "fsync" (IO blokkoláshoz), ha ez az érték túl kicsi, akkor sok "szinkron" időpontot eredményez, ami azt jelenti, hogy az összes kliens kérésnek van egy bizonyos késleltetése, és a fizikai szerver meghibásodása üzenetek elvesztéséhez vezet fsync nélkül. | | log.flush.scheduler.interval.ms | Long.MaxValue | Ellenőrizd, szükséges-e fsync intervallumok | | log.flush.interval.ms | Long.MaxValue | Ezt a számot használják a "fsync" időintervallumának szabályozására, ha az üzenetek száma soha nem éri el a lemezre szilárdult üzenetek számát, de az utolsó lemezszinkronizáció időintervalla eléri a küszöböt, akkor a lemezszinkronizáció is elindul. | | log.delete.delay.ms | 60000 | A fájl törlése utáni tárolási időt általában nem szükséges módosítani | | auto.create.topics.enable | true | Hogy engedélyezzék-e automatikusan témák létrehozását. Ha igaz, automatikusan létrehoz egy olyan témát, amely nem létezik, amikor a produce vagy fetch nem létezik. Ellenkező esetben a parancssorral kell létrehoznod egy témát | | controller.socket.timeout.ms | 30000 | A socket időkilépési ideje, amikor a partíciókezelő vezérlő biztonsági mentést végez. | | controller.message.queue.size | Int.MaxValue | controller-to-broker-channles | | default.replication.factor | 1 | A biztonsági mentések alapértelmezett száma csak automatikusan létrehozott témákra vonatkozik | | replica.lag.time.max.ms | 10000 | Ha egy követő ebben az időben nem küld behozási kérést, a vezető visszaveszi a követőt az ISR-ből, és felakasztottnak tekinti a követőt | | replica.lag.max.messages | 4000 | Ha egy másolatban ennél több van a lezárt számú felerősített, a vezető eltávolítja a követőt, és felakasztottnak tekinti a követőt | | replica.socket.timeout.ms | 30*1000 | Leader időlevonási idő socket hálózati kérésekhez adatmentéskor | | replica.socket.receive.buffer.bytes | 64*1024 | Socket fogadó puffer, amikor hálózati kérést küldenek a vezetőnek mentés közben | | replica.fetch.max.bájt | 1024*1024 | Az egyes lehívások maximális értéke a mentés idején | | replica.fetch.min.bytes | 500 | A maximális várakozási idő, amíg az adat eléri a vezetőt, amikor a vezető biztonsági mentést kér | | replica.fetch.min.bytes | 1 | A válasz legkisebb mérete minden lehajtás után visszamentéskor | | num.replica.fetchers | 1 | A szálak száma, amelyek az adatokat a vezetőtől tartják vissza | | replica.high.watermark.checkpoint.interval.ms | 5000 | Minden másolat ellenőrzi, hogy milyen gyakran származik meg a legmagasabb vízszint | | fetch.purgatory.purge.interval.requests | 1000 | Fetch kéri a tisztítási intervallumot | | producer.purgatory.purge.interval.requests | 1000 | A producer törlési intervallumot kér | | zookeeper.session.timeout.ms | 6000 | Állatkerti munkaidő. | | zookeeper.connection.timeout.ms | 6000 | Az a maximális idő, amíg az ügyfél kapcsolatot teremt a zookeeperrel | | zookeeper.sync.time.ms | 2000 | A zk követője a leghosszabb ideig lemarad a ZK vezetőtől | | controlled.shutdown.enable | true | Lehetséges-e ellenőrizni a bróker zárását. Ha lehetséges, a bróker minden vezetőt áthelyezhet más brókerekhez a zárás előtt. Ez csökkenti a leállás során elérhetetlen állapotot. | | controlled.shutdown.max.ismétlések | 3 | Azok a parancsok száma, amelyek sikeresen végrehajthatják a leállítást a befejezetlen leállítás előtt. | | controlled.shutdown.retry.backoff.ms | 5000 | Visszalépési idő a leállások között | | auto.leader.rebalance.enable | true | Ha ez igaz, a vezérlő automatikusan egyensúlyba hozza a brókerek vezetését a partíciók felett | | leader.egyenletlenség.bróker-százalék | 10 | Az egyes brókerek által engedélyezett maximális egyensúlyhiányarány | | leader.inbalance.check.interval.seconds | 300 | Ellenőrizd a vezető egyensúlyhiány gyakoriságát | | offset.metadata.max.bájt | 4096 | Lehetővé teszi az ügyfelek számára, hogy a maximális szám elmentsék az offsetjüket | | max.connections.per.ip | Int.MaxValue | Minden IP-címhez a maximális kapcsolat száma lehet egy brókerenként | | max.connections.per.ip.overrides | | Az alapértelmezett kapcsolat maximális lefedettsége IP-nként vagy hosztnévenként | | connections.max.idle.ms | 600000 | Időkorlát üres kapcsolatok esetén | | log.roll.jitter. {ms,hours} | 0 | A logRollTimeMillisből absztrakció alatt elvont maximális remegés száma | | num.recovery.threads.per.data.dir | 1 | Hány szálat használ minden adatkönyvtár a helyreállítás naplózására | | unclean.leader.election.enable | true | Jelzi, hogy lehetséges-e használni az ISR-ben a nem-replikák beállítást vezetőként | | delete.topic.enable | false | Képes törölni témákat | | offsets.topic.num.partitions | 50 | Az offset commit téma partícióinak száma. Mivel a telepítés utáni változtatás jelenleg nem támogatott, javasoljuk, hogy magasabb beállítást használjunk a termeléshez (pl. 100-200). | | offsets.topic.retention.minutes | 1440 | Azok az elvonások, amelyek hosszabb ideig léteznek ezen az időkorlátnál, törlésre várónak lesznek jelölve | | offsets.retention.check.interval.ms | 600000 | Az offset menedzser ellenőrzi az elavult eltolások gyakoriságát | | offsets.topic.replication.factor | 3 | A témák eloltásának tartalék másolatainak száma. Ajánlott magasabb számokat állítani, hogy garantáljuk a magasabb elérhetőséget | | offset.topic.segment.bytes | 104857600 | Eltérít témát. | | offsets.load.buffer.size | 5242880 | Ez a beállítás a kötet méretéhez kapcsolódik, és az offsets szegmensből olvasáskor használatos. | | offsets.commit.required.acks | -1 | A megerősítések számát be kell állítani, mielőtt az offset commit elfogadható legyen, és általában nem kell változtatni |
| Tulajdon | Alapértelmezett | Szerver alapértelmezett tulajdonsága | Leírás | | Cleanup.policy | Törlés | log.cleanup.policy | Vagy "delete", vagy "compact"; Ez a sorozat megmutatja, hogyan lehet használni a régi napló részt; Az alapértelmezett módszer ("törlés") akkor dobja el a régi alkatrészt, amikor elérik az újrahasznosítási időt vagy mérethatárt. "kompakt" összenyomja a rönkeket | | delete.retention.ms | 86400000 (24 órán) | log.cleaner.delete.retention.ms | A log.retention.minutes közötti különbség az, hogy az egyik a tömörítetlen adatokat irányítja, a másik pedig tömörített adatokat. Ezt a konfigurációt felülírhatják a rögzítési paraméterek a téma létrehozásakor | | flush.messages | Egyik sem | log.flush.interval.messages | Ez a konfiguráció időintervallumot határoz meg az fsync naplók kényszerítésére. Például, ha ez az opció 1-re van állítva, akkor minden üzenet után fsync szükséges, ha 5-re állítva, akkor minden 5 üzenethez fsync szükséges. Általánosságban ajánlott, hogy ne állítsd be ezt az értéket. Ennek a paraméternek a beállításához szükséges kompromisszum szükséges az "adatmegbízhatóság" és a "teljesítmény" között. Ha ez az érték túl nagy, minden alkalommal hosszú ideig "fsync" (IO blokkolás), és ha ez az érték túl kicsi, akkor nagy számú "fsync"-hez vezet, ami azt is jelenti, hogy az ügyfélkérés egészében bizonyos késleltetés van. Fizikai szerverhiba esetén az üzenetek elvesznek fsync nélkül. | | flush.ms | Egyik sem | log.flush.interval.ms | Ezt a konfigurációt használják arra, hogy rögzítsék az időintervallumot a fsync naplók kényszerítése között a lemezre; Például, ha 1000-re állítva van, akkor fsync minden 1000 ms-enként szükséges. Ez a lehetőség általában nem ajánlott | | index.interval.bytes | 4096 | log.index.interval.bytes | Az alapértelmezett beállítás biztosítja, hogy 4096 bájtonként indexet adjunk az üzenethez, és több index közelebb hozza az olvasott üzenetet, de az index mérete nő. Ez az opció általában nem kötelező | | max.message.bytes | 1000000 | max.message.bytes | A kafka append üzenet maximális mérete. Fontos megjegyezni, hogy ha ezt a méretet növeled, akkor a fogyasztó behozó méretét is növelned kell, hogy a fogyasztó üzeneteket a maximális méretre tudja hozni. | | min.tisztítható.piszkos.arány | 0.5 | min.tisztítható.piszkos.arány | Ez a konfiguráció szabályozza, hogy a log kompresszor milyen gyakran próbálja eltávolítani a rönkeket. Alapértelmezés szerint elkerüljük azokat a naplókat, amelyek tömörítési rátája több mint 50%-os. Ez az arány elkerüli a legnagyobb helypazarlást | | min.insync.replicas | 1 | min.insync.replicas | Amikor a producer request.required.acks -1-re van állítva, a min.insync.replicas megadja a minimális replikák számát (minden repica írásnak sikeresnek kell lennie), és ha ezt a számot nem érik el, a producer kivételt hoz létre. | | retention.bytes | Egyik sem | log.retention.bytes | Ha a "törlés" megőrzési szabályzatot használod, ez a konfiguráció arra a maximális méretre utal, amit a napló elérhet, mielőtt töröljük. Alapértelmezés szerint nincs méretkorlát, csak időkorlát | | retention.ms | 7 nap | log.retention.minutes | Ha a "törlés" megőrzési szabályzatot használod, ez a konfiguráció arra az időre utal, amikor a naplót a törlési napló előtt mentették el. | | segment.bytes | 1GB | log.segment.bytes | A Kafkában a naplók darabokban vannak tárolva, és ez a konfiguráció a log logok darabokra osztott méretére utal | | segment.index.bytes | 10MB | log.index.size.max.bájt | Ez a konfiguráció nagyjából akkora, mint az indexfájl, amelyet az eltérések és a fájl helyek között képeznek le; Ezt a konfigurációt általában nem kell módosítani | | segment.ms | 7 nap | log.roll.hours | Még ha a log chunk fájl nem is éri el a törlésre vagy tömörítésre szükséges méretet, amikor a naplóidő eléri ezt a felső határt, új log chunk fájlt kényszerítenek | | segment.jitter.ms | 0 | log.roll.jitter. {ms,hours} | A maximális jitter, amit le kell vonni a logRollTimeMillisből. |
Fogyasztói konfigurációk
| Tulajdon | Alapértelmezett | Leírás | | group.id | | Egy string, amely egyedien azonosítja azt a csoportot, amelyben a fogyasztói folyamat található, és ha ugyanaz a csoportazonosító van beállítva, akkor ezek a folyamatok ugyanahhoz a fogyasztói csoporthoz tartoznak | | zookeeper.connect | | Határozd meg a Zookeeper kapcsolat stringjét, a formátum: hostname:port, itt a host és port mind a Zookeeper szerver hoszteve, mind portja, hogy elkerülje a kapcsolat elvesztését, miután egy Zookeeper gép leáll, több hostname:port megadhat, vesszővel elkülönítve:
hostname1:port1,hostname2:port2,hostname3:port3
Hozzáadhatod a ZooKeeper chroot útvonalát a ZooKeeper kapcsolati láncsorhoz, amely saját adatai tárolására szolgál, így működik:
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path | | consumer.id | nulla | Nem szükséges beállítás, általában automatikusan generálódik | | socket.timeout.ms | 30*100 | Időtúllépési korlátok hálózati kérésekhez. A valódi időtúllépési határ max.fetch.wait+socket.timeout.ms | | socket.receive.buffer.bytes | 64*1024 | socket a hálózati kérések gyorsítótár méretének fogadására szolgál | | fetch.message.max.bájtok | 1024*1024 | A maximális bájtszám egy betöltési üzenetenként, egy betöltési kérésenként. Ezeket a bájtokat a partíciókhoz használt memóriában felügyeljük, így ez a beállítás szabályozza, hogy a fogyasztó mennyi memória használ. A bekeresési kérelmek méretének legalább annyinak kell lennie, mint a szerver által engedélyezett maximális üzenetméret, különben a gyártó által küldött üzenet mérete nagyobb, mint amit a fogyasztó fogyasztani tud. | | num.consumer.fetchers | 1 | A fetcher szálak száma, amelyeket a fetch adathoz használnak | | auto.commit.enable | true | Ha igaz, a fogyasztó által beérkezett üzenet eloszlása automatikusan szinkronizálódik az állatkerti gondossal. Ezt a commit offsetet az új felhasználó fogja használni, amikor a folyamat leáll | | auto.commit.interval.ms | 60*1000 | Az a gyakoriság, amellyel a fogyasztó az állatkerti gondosnak továbbítja az offsetet, másodpercekben van | | queued.max.message.chunks | 2 | A maximális számú üzenet, amelyet a gyorsítótárhoz használnak. Minden darabnak ugyanaznak kell lennie, mint a fetch.message.max.bájtnak | | rebalance.max.ismétlések | 4 | Amikor új fogyasztót adnak egy fogyasztói csoportba, a fogyasztók gyűjteménye megpróbálja újrakiegyenlíteni az egyes fogyasztók számára kijelölt partíciók számát. Ha a fogyasztói gyűjtemény megváltozik, ez az újraegyensúlyozás meghibásodik, és újra átrepencifikál, amikor az allokáció végrehajtódik | | fetch.min.bytes | 1 | A szervernek minden behíváshoz vissza kell térnie a minimális bájtszám. Ha nem érkezik elegendő adat, a kérés vár, amíg elegendő adat érkezik. | | fetch.wait.max.ms | 100 | Ha nincs elegendő adat a fetch.min.bytes kielégítéséhez, ez a konfiguráció azt jelenti, hogy a szerver legfeljebb blokkolja a fetch kérésre való válasz előtt. | | rebalance.backoff.ms | 2000 | Visszalépés ideje a Reblance újrapróbálkozása előtt | | refresh.leader.backoff.ms | 200 | Van egy visszalépési idő, hogy várj, mielőtt megpróbálják megállapítani, hogy egy felosztás vezetője elvesztette-e a vezetőségét | | auto.offset.reset | legnagyobb | Ha a zookeeperben nincs inicializált eltolás, ha az eltolás a következő értékre adott válasz:
Legkisebb: Automatikus visszaállító eltérés a legkisebb eltérésre
legnagyobb: Automatikus visszaállítás a legnagyobb eltolódásra
bármi más: kivételt dob a fogyasztóra | | consumer.timeout.ms | -1 | Ha nincs elérhető üzenet, még egy adott idő után is, időtúlzási kivétel kerül | | exclude.internal.topics | true | Hogy belső témákból érkező üzeneteket mutassanak-e a fogyasztóknak | | paritition.assignment.strategy | Terjedelmek | Válaszd ki a fogyasztói áramláshoz tartozó partíciók hozzárendelésére vonatkozó szabályzatot, opcionálisan tartományt, roundrobint | | client.id | Csoportazonosító érték | egy felhasználóspecifikus string, amely segít nyomon követni a hívásokat minden kérésben. Logikusan meg kell erősítenie azt az alkalmazást, amely a kérést generálta | | zookeeper.session.timeout.ms | 6000 | Időkorlátok az állatkerti foglalkozások esetén. Ha a fogyasztó ebben az időszakban nem küld szívverési üzenetet az állatkertésznek, azt letévesztettnek tekintik, és egy visszajelzés keletkezik | | zookeeper.connection.timeout.ms | 6000 | A maximális várakozási idő, amíg egy ügyfél létrehozza az állatkerti kapcsolatot | | zookeeper.sync.time.ms | 2000 | A ZK követői maximum ideig lemaradhatnak a ZK vezetőtől | | offsets.storage | Állatkertész | Helyek, ahol elfoglaltak: állatkertész vagy kafka | | offset.channel.backoff.ms | 1000 | Az offsets csatorna újracsatlakozásának vagy a sikertelen offset lekérésének újrapróbálásának visszalépési ideje | | offsets.channel.socket.timeout.ms | 10000 | A socket időtúli korlátja a fetch/commit request válaszra adott válaszhoz az offset olvasásakor. Ezt az időtúllépést a consumerMetadata kérés használja az offset kezelés kérésére | | offsets.commit.max.újrapróbálkozások | 5 | Az offset elköteleződés újrapróbálkozásának száma. Ez az újrapróbálás csak a leállítás közötti offset commit-ekre vonatkozik. őt | | dual.commit.enabled | true | Ha a "kafka"-t offset.storage-ként használod, kétszer is elkötelezheted az offsetet a zookeepernek (és egyszer a kafka-hoz). Ez elengedhetetlen, amikor állatkerti alapú offset tárolásról kafka-alapú offset tárolásra váltunk. Bármely fogyasztói csoport számára biztonságos ajánlott ezt az opciót kikapcsolni, amikor a migráció befejeződött | | partition.assignment.strategy | Terjedelmek | Válassz a "tartomány" és a "roundrobin" politikák között a fogyasztói adatfolyamokhoz való partíciók hozzárendeléséhez; A körkörös partíciós allokátor minden elérhető partíciót, valamint minden elérhető fogyasztói szálat is kioszt. A partíciós hurkot a fogyasztói szálhoz rendeli. Ha minden fogyasztói példány egy meghatározott példányhoz van kötve, a partíciók determinisztikus eloszlásokra vannak osztva. A körös elosztási stratégia csak akkor lehetséges, ha a következő feltételek teljesülnek: (1) Minden téma ugyanannyi adatfolyamot tartalmaz fogyasztói erősségre jutva. (2) Az előrendelt témák gyűjteményét minden fogyasztói példány esetében a fogyasztói csoportban határozzák meg. |
Producer konfigurációk
| Tulajdon | Alapértelmezett | Leírás | | metadata.broker.list | | Bootstrapping szolgálata. A producer csak metaadatok (topicok, partíciók, replikák) megszerzésére szolgál. A socket-kapcsolat az adatok tényleges küldéséhez a visszaküldött metaadat alapján jön létre. A formátum a következő:
host1:port1,host2:port2
Ez a lista lehet egy allista brókerekről, vagy egy VIP a brókerekre mutat | | request.required.acks | 0 | Ez a konfiguráció egy visszaigazolási érték, amely jelzi, mikor tekintenek egy producerek kérését teljesnek. Különösen az, hogy hány más bróker adta be az adatokat a naplóiba, és megerősítette ezt a vezetőjüknek. Tipikus értékek a következők:
0: Azt jelzi, hogy a producer soha nem vár a brókertől érkező megerősítésre (ugyanaz a viselkedés, mint a 0.7). Ez az opció a legkisebb késleltetést nyújtja, de ugyanakkor a legnagyobb kockázatot is (mert az adatok elvesznek, amikor a szerver leáll).
1: Jelzi, hogy a vezető replika megkapta az adat megerősítését. Ez az opció alacsony késleltetéssel rendelkezik, és biztosítja, hogy a szerver megerősítse, hogy megérkezett.
-1: A gyártó megerősítést kap, hogy minden szinkronizált replika megkapta az adatokat. A késleltetés a legnagyobb, azonban ez a módszer nem szünteti meg teljesen az üzenetek elvesztésének kockázatát, mivel a szinkronizált replikák száma akár 1 lehet. Ha biztosítani szeretnéd, hogy egyes replikák adatokat kapjanak, akkor a témaszintű beállításokban be kell állítanod a min.insync.replicas opciót. Olvasd el a tervezési dokumentációt a mélyebb vitához. | | request.timeout.ms | 10000 | A bróker igyekszik a request.required.acks követelményt megvalósítani, különben hiba érkezik az ügyfélnek | | producer.type | Sync | Ez az opció kitűzi, hogy az üzenet aszinkron módon érkezik-e háttérszálban. Helyes értékek:
(1) aszinkron: Aszinkron küldés
(2) szinkron: Szinkronizált küldés
Ha a producert aszinkronra állítjuk, csomagokban tudjuk feldolgozni a kéréseket (ami jó a nagyobb áteresztőképesség érdekében), de ez azt is feljelenti, hogy a kliens gép elveszíti az elküldött adatokat | | serializer.class | kafka.serializer.DefaultEncoder | Az üzenet serializációs kategóriája. Az alapértelmezett kódoló egy bájtot ír[] és ugyanazt a bájtot[] adja vissza[] | | key.serializer.class | | Serializációs osztály kulcsszavakhoz. Ha ez nem van megadva, az alapértelmezett az üzenet egyezése | | partitioner.class | kafka.producer.DefaultPartitioner | Partitioner class, amely az üzeneteket altémák között osztja. Az alapértelmezett partíciós rendszer a kulcs hash tábláján alapul | | compression.codec | egyik sem | Ez a paraméter beállíthatja az adatok tömörítésére szolgáló kódeket, amely "none", "gzip", "snappy" módokat választhat. | | Compressed.topics | nulla | Ez a paraméter arra is beállíthatja, hogy bizonyos témák tömörítettek-e. Ha a tömörített kódek nem a NoCompressCodec, akkor ezeket a kodekeket a megadott témaadatokra alkalmazzák. Ha a tömörített témák listája üres, alkalmazzuk a konkrét tömörített kódeket minden témára. Ha a tömörített kódek NoCompressionCodec, akkor a tömörítés nem minden témában elérhető. | | message.send.max.ismétlések | 3 | Ez a paraméter automatikusan újra próbálja a sikertelen küldési kérelmeket. Ez a paraméter kitűzi a próbálkozások számát. Megjegyzés: Ha nem 0 értéket állítunk, bizonyos hálózati hibák ismétlődnek: küldést és visszaigazolás elvesztését okoznak | | retry.backoff.ms | 100 | Minden újrapróbálkozás előtt a producer frissíti a releváns téma metaadatait, hogy lássa, az új vezető van-e kijelölve. Mivel a vezető kiválasztása kevés időt vesz igénybe, ez az opció meghatározza, mennyi időt kell várnia a termelőnek a metaadatok frissítéséhez. | | topic.metadata.refresh.interval.ms | 600*1000 | A producer általában frissíti a téma metaadatait bizonyos hiba esetén (partíció hiányzik, vezető nem elérhető stb.). Rendszeres cikluson megy keresztül. Ha negatív értékre állítod, a metaadat csak akkor frissül, ha meghibásodik. Ha 0-ra állítva, a metaadat minden üzenet elküldése után frissül (ez a lehetőség nem ajánlott, a rendszer túl sokat fogyaszt). Fontos: A frissítések csak az üzenet elküldése után történnek, tehát ha a gyártó soha nem küldi el az üzenetet, a metaadat soha nem frissül. | | queue.buffering.max.ms | 5000 | Az a maximális időintervallum, amikor a felhasználó adatokat gyorsítótároz, amikor asszinkron módot alkalmaznak. Például, ha az üzenet 100-ra van állítva, a 100 ms-en belüli üzeneteket csomagokban dolgozzák fel. Ez javítja az áteresztőképességet, de növeli a késleltetést a gyorsítótározás miatt. | | queue.buffering.max.üzenetek | 10000 | Aszinkron mód használatában a gyártó előtt a sorba gyorsatároló maximális el nem küldött üzenetek számát kell blokkolni, vagy adatokat kell elveszíteni | | batch.num.messages | 200 | Aszinkron módban a maximális számú üzenetet lehet csomagosan feldolgozni. Vagy az üzenetek száma érkezett ide online, vagy queue.buffer.max.ms megérkezett, és a producer feldolgozza azokat | | send.buffer.bytes | 100*1024 | socket írási cache mérete | | client.id | “” | Ez az ügyfélazonosító egy felhasználóspecifikus string, amely minden kéréshez csatlakozik a hívás nyomon követéséhez, és logikusan tudnia kell megerősítenie, hogy az alkalmazás kérelmezett-e. |
Producer konfigurációk
| Név | Típus | Alapértelmezett | Jelentőség | Leírás | | boostrap.servers | Lista | | Magas | A host/port csoport, hogy kapcsolatot teremtsen a kafka klaszterrel. Az adatok egyenletesen töltődnek be minden szerveren, függetlenül attól, melyik szerver van kijelölve bootstrappingre. Ez a lista csak az inicializált hosztokat érinti (amelyeket minden szerver felderítésére használnak). Ez a lista formátuma:
host1:port1,host2:port2,...
Mivel ezeket a szervereket csak a kapcsolatok inicializálására használják, hogy felfedezzék a klaszter összes tagságát (amelyek dinamikusan változhatnak), ennek a listának nem kell minden szervert tartalmaznia (lehet, hogy több szervert is szeretnél, bár ebben az esetben egy szerver leállhat). Ha nincs szerver ebben a listában, az adatküldés kudarcot vall, amíg a lista nem elérhető. | | acks | húr | 1 | Magas | A gyártónak szüksége van egy jelre a szervertől, hogy visszaigazolja a fogadtatást az adatok megérkezése után, és ez a konfiguráció arra utal, hogy a prokudernek hány ilyen visszaigazolási jelre van szüksége. Ez a konfiguráció valójában az adatmentések elérhetőségét jelenti. Az alábbi beállítások gyakoriak a választások:
(1) acks=0: 0-ra állítva azt jelenti, hogy a gyártónak nem kell várnia a kapott információk megerősítésére. A másolatot azonnal hozzáadják a socket pufferhez, és elküldve tekintik. Ebben az esetben nincs garancia arra, hogy a szerver sikeresen megkapta az adatokat, és a konfiguráció újrapróbálása nem fog működni (mert a kliens nem tudja, hogy meghibásodott-e), így a visszacsatolás eltolása mindig -1-re lesz állítva.
(2) acks=1: Ez azt jelenti, hogy legalább várjuk meg, amíg a vezető sikeresen megírja az adatokat a helyi naplóba, de nem arra, hogy minden követő sikeresen írjon. Ebben az esetben, ha a követő nem sikeresen menti le az adatokat, és a vezető ismét leteszi a telefont, az üzenet elveszik.
(3) acks=all: Ez azt jelenti, hogy a vezetőnek várnia kell minden biztonsági mentésre, hogy sikeresen naplót írjon, és ez a stratégia biztosítja, hogy az adatok ne veszjenek el, amíg egy biztonsági mentés megmarad. Ez a legerősebb garancia.
(4) Más beállítások, például acks=2 is lehetségesek, amelyekhez meghatározott számú ack szükséges, de ezt a stratégiát általában ritkán használják. | | buffer.memory | hosszú | 33554432 | Magas | A producer segítségével gyorsabőrbe helyezhető az adatok memória mérete. Ha az adatok gyorsabban generálódnak, mint ahogy a brókernek küldik, a gyártó tiltja vagy elküld egy kivételt, amelyet "block.on.buffer.full" jelzéssel jelöl.
Ez a beállítás összefügg a gyártó által használt teljes memóriával, de nem szigorú korlát, mivel nem minden memóriát használ gyorsítótárhoz. Néhány további memória tömörítéshez (ha tömörítést vezetnek be), és egy részét karbantartási kérésekre. | | compression.type | húr | egyik sem | Magas | a producer az a tömörítési típus, amelyet az adatok tömörítésére használnak. Az alapértelmezett tömörítés nélküli. A helyes opcióértékek: nincs, gzip, snappy.
A tömörítést leginkább köteges feldolgozásra használják, minél több üzenetet dolgoznak fel adagokban, annál jobb a tömörítési teljesítmény. | | Újrapróbálkozások | int | 0 | Magas | 0 feletti érték beállítása arra készteti az ügyfél, hogy az adatok meghibásodása után újra küldjön adatokat. Fontos megjegyezni, hogy ezek az újrapróbálkozások nem különböznek azoktól, amikor a kliens küldési hibát kap. Lehetővé teszi, hogy az újrapróbálkozások megváltoztassák az adatok sorrendjét, ha mindkét üzenet ugyanarra a partícióra kerül, az első üzenet megbukik, a második üzenet korábban jelenik meg, mint az első. | | batch.size | int | 16384 | Közepes | A producer megpróbálja az üzenetrekordokat csoportosan megszerezni, hogy csökkentse a kérések számát. Ez javítja a teljesítményt a kliens és szerver között. Ez a konfiguráció szabályozza a kötött feldolgozó üzenetek alapértelmezett számát.
Nem próbálnak feldolgozni az üzenet bájtjait, amelyek nagyobbak ennél a bájtszámnál.
A brókereknek küldött kérések több tételt tartalmaznak, amelyek minden partícióhoz egy kérést tartalmaznak.
A kisebb köteges értékek ritkábban vannak, és csökkenthetik az áteresztőképességet (0 csak köteges feldolgozást használ). A nagyobb köteg értékek több memóriateret pazarolnak, ezért konkrét csomagértékekhez kell memóriát osztanod le. | | client.id | húr | | Közepes | Ezt a stringet a szervernek küldik, amikor kérelmet tesznek. A cél az, hogy nyomon kövessék a kérések forrását, így egyes IP/port engedélyezett listán kívüli alkalmazások információt küldhessenek. Ez az alkalmazás bármilyen stringet tud beállítani, mert nincs funkcionális célja, csak a rögzítés és követés | | linger.ms | hosszú | 0 | Közepes | A producer csoport összegyűjti az üzeneteket, amelyek a kérés és a küldés között érkeznek, külön csomagot rögzítve. Ez általában csak akkor történik, ha a rekord gyorsabban generálódik, mint a küldési sebesség. Bizonyos feltételek mellett azonban az ügyfél csökkenteni akarja a kérések számát, vagy akár mérsékelt terhelést is. Ezt a beállítást egy kis késleltetéssel végzik – azaz a producer ahelyett, hogy azonnal elküldene egy rekordot, a producer megvárja egy adott késleltetési időt, hogy más üzenetrekordokat küldhessen, amelyeket be lehet kötni. Ez hasonló algoritmusnak tekinthető, mint a TCP Nagle. Ez a beállítás magasabb késleltetéshatárt állít fel a batching-hez: amint megkapjuk a partíció batch.size-ét, azonnal elküldi azt attól függetlenül, hogy ettől függetlenül elküldjük, de ha egy üzenetet kapunk, amelynek bájtszáma sokkal kisebb az adott beállításnál, akkor egy adott időt kell "elhúznunk", hogy több üzenetet kapjunk. Ez a beállítás alapértelmezettként 0-ra van, azaz nincs késleltetés. Például a linger.ms=5 beállítása csökkenti a kérések számát, ugyanakkor 5 ms-rel növeli a késleltetést. | | max.request.size | int | 1028576 | Közepes | A kért maximális bájtszám. Ez hatékony lefedettség a maximális rögzített méret esetén is. Megjegyzés: A szervernek saját üzenetrekordméretek felülírása van, amelyek eltérnek ettől a beállítástól. Ez a beállítás korlátozza, hogy a producerek egyszerre tömegesen küldhetnek kéréseket, hogy elkerülje a nagy számú kérést. | | receive.buffer.bytes | int | 32768 | Közepes | TCP receptioncache mérete, amelyet adatolvasáskor használnak | | send.buffer.bytes | int | 131072 | Közepes | TCP küldési gyorsítótár mérete, amelyet adatküldéskor használnak | | timeout.ms | int | 30000 | Közepes | Ez a konfigurációs opció szabályozza, mennyi ideig várja a szerver a követők megerősítését. Ha az adott időben nem teljesítik a megerősített kérések számát, hiba jelenik meg. Ezt az időtúllépési határt a szerver oldalon mõõdik, és nincs hálózati késleltetés, beleértve a kéréseket is. | | block.on.buffer.full | Boolean | true | alacsony | Amikor a memória gyorsítótárunk lefogy, abba kell hagynunk új üzenetrekordok fogadását, vagy hibákat kell küldenünk. Alapértelmezés szerint ez igaz, de némi blokkolás nem feltétlenül éri meg számítani, ezért jobb azonnal hibát adni. Ez akkor fordul elő, ha hamisra állítva: a producer kivétel hibát dob: BufferExhaustedException, ha a rekordot elküldték és a gyorsítótár tele van | | metadata.fetch.timeout.ms | hosszú | 60000 | alacsony | Ez arra utal, hogy egyes elemekről először szereztünk adatokat. Az elemek közé tartozik: téma, hosztex, partíciók. Ez a konfiguráció arra az időre utal, amely az elem sikeres befejezéséhez szükséges a fetch szerint, különben kivételt küldenek a kliensnek. | | metadata.max.age.ms | hosszú | 300000 | alacsony | Az idő mikroszekunduumokban az az időszak, amikor a metaadatokat frissítjük. Még ha nem is látunk választókerületi vezetőváltásokat. | | metric.riporterek | Lista | [] | alacsony | Egy lista a metrikák mérésére használt osztályokról. A MetricReporter interfész megvalósítása lehetővé teszi olyan osztályok hozzáadását, amelyek új metrikák generálódásával változnak. A JmxReporter mindig tartalmaz egy módot a JMX statisztikák regisztrálására | | metrics.num.samples | int | 2 | alacsony | A minták száma, amelyeket a mutatók fenntartására használnak | | metrics.sample.window.ms | hosszú | 30000 | alacsony | A Metrikák rendszer konfigurálható számú mintát tart fenn egy javítható ablakméretben. Ez a konfiguráció például az ablakméretet konfigurálja. Két mintát is megőrizhetünk 30 másodperces időtartamra. Amikor egy ablakot kinyitottak, törlesztjük és újraírjuk a legrégebbi ablakot | | recoonect.backoff.ms | hosszú | 10 | alacsony | Ha a kapcsolat meghibásodik, a visszakapcsolódás várakozási ideje lesz. Ez elkerüli az ismétlődő kliens-újrakapcsolódásokat | | retry.backoff.ms | hosszú | 100 | alacsony | A várakozási idő, mielőtt megpróbálnánk újrapróbálni egy sikertelen termelés kérést. Kerüld el, hogy elragadj egy "küldés-sikertelen" holtciklusba.
|
|
Közzétéve 2021. 06. 24. 11:47:12
|
|
|
Háziúr