Broker Configs
| Nemovitosti | Výchozí | Popis | | broker.id | | Každý broker může být identifikován unikátním nezáporným celočíselným ID; Toto ID lze použít jako "jméno" brokera a jeho existence umožňuje brokerovi migrovat na jiný hostitel/port bez zmatení uživatelů. Můžete si vybrat jakékoli číslo jako ID, pokud je ID jedinečné. | | log.dirs | /tmp/kafka-logs | Cesta, kde Kafka ukládá data. Tato cesta není jedinečná, může být více a cesty je třeba oddělit pouze čárkami; Kdykoli je vytvořena nová partition, je zvolena tak, aby se prováděla pod cestou, která obsahuje nejmenší počet partitionů. | | Přístav | 6667 | Server přijímá port, ke kterému se klient připojuje | | zookeeper.connect | nula | Formát řetězce spojení ZooKeeper je: hostname:port, kde hostname a port jsou hostitel a port uzlu v clusteru ZooKeeper. Pro připojení k dalším uzlům ZooKeeperu, když hostitel přestane fungovat, můžete vytvořit více hostitelů následovně:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper umožňuje přidat "chroot" cestu pro ukládání všech kafka dat v clusteru pod konkrétní cestou. Když více Kafka clusterů nebo jiných aplikací používá stejný ZooKeeper cluster, můžete touto metodou nastavit cestu ukládání dat. To lze realizovat formátováním spojovacího řetězce takto:
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path
Toto nastavení ukládá všechna data z Kafka clusteru pod /chroot/path path. Všimněte si, že před zahájením makléře musíte tuto cestu vytvořit a spotřebitelé musí použít stejný formát připojení. | | message.max.bajtů | 1000000 | Maximální velikost zpráv, které může server přijímat. Je důležité, aby nastavení spotřebitele a výrobce ohledně této vlastnosti byla synchronizována, jinak je zpráva zveřejněná výrobcem příliš rozsáhlá pro spotřebitele. | | num.network.threads | 3 | Počet síťových vláken, která server používá ke zpracování síťových požadavků; Obvykle nemusíte měnit tuto nemovitost. | | num.io.threads | 8 | Počet I/O vláken používaných serverem k zpracování požadavků; Počet vláken by měl být alespoň roven počtu pevných disků. | | background.threads | 4 | Počet vláken používaných pro zpracování na pozadí, například pro mazání souborů; Nemusíte měnit tuto nemovitost. | | queued.max.requests | 500 | Maximální počet požadavků, které může být zařazen do fronty, aby I/O vlákno zpracovalo, než síťové vlákno přestane číst nové požadavky. | | host.name | nula | jméno hostitele makléře; Pokud je hostitelské jméno již nastavené, makléř bude vázán pouze na tuto adresu; Pokud žádné nastavení není, naváže se na všechna rozhraní a zveřejní jednu kopii do ZK | | advertised.host.name | nula | Pokud je nastaveno, je zasíláno producentům, spotřebitelům a dalším makléřům jako hostitelské jméno brokera | | advertised.port | nula | Tento port je poskytován producentům, spotřebitelům a dalším zprostředkovatelům a slouží k navázání spojení; Stačí to nastavit jen tehdy, pokud je skutečný port a port, který server potřebuje navázat, odlišné. | | socket.send.buffer.bytes | 100 * 1024 | SO_SNDBUFF velikost cache, kterou server používá k připojení socketů | | socket.receive.buffer.bytes | 100 * 1024 | SO_RCVBUFF velikost cache, kterou server využívá k připojení k socketům | | socket.request.max.bajtů | 100 * 1024 * 1024 | Maximální velikost požadavku povolenou serverem; Tím se vyhnete přetečení serveru, které by mělo být menší než velikost haldy v Javě | | num.partitions | 1 | Pokud při vytváření tématu není uveden počet oddílů, bude toto číslo výchozím počtem oddílů pod tématem. | | log.segment.bytes | 1014*1024*1024 | Logy rozdělení tématu jsou uloženy v mnoha souborech v určitém adresáři, který dělí logy rozdělení na segmenty; Tento atribut je maximální velikost každého souboru; Když dimenze dosáhnou této hodnoty, vytvoří se nový soubor. Toto nastavení lze přepsat základem každého tématu.
Zobrazit Přihlášení k hypertextovému odkazu je viditelné. | | log.roll.hours | 24 * 7 | I když soubor nedosáhne log.segment.bytes, nový soubor se vytvoří vždy, když čas vytvoření souboru dosáhne této vlastnosti. Toto nastavení lze také přepsat nastavením na úrovni tématu;
PohledPřihlášení k hypertextovému odkazu je viditelné. | | log.cleanup.policy | smazat | | | log.retention.minutes a log.retention.hours | 7 dní | Čas, kdy byl každý logovací soubor uložen před jeho smazáním. Výchozí doba ukládání dat je pro všechna témata stejná.
log.retention.minutes a log.retention.bytes se používají k nastavení mazání log souborů, bez ohledu na to, která vlastnost byla přetečena.
Toto nastavení vlastnosti lze přepsat, když je téma v podstatě dané.
PohledPřihlášení k hypertextovému odkazu je viditelné. | | log.retention.bytes | -1 | Celkové množství dat uložených každou partition pod daným tématem; Všimněte si, že toto je horní limit na jednu partition, takže toto číslo vynásobené počtem partitionů je celkové množství dat uložených na jedno téma. Také pozor: Pokud jsou nastaveny jak log.retention.hours, tak log.retention.bytes, překročení kteréhokoliv limitu způsobí smazání segmentového souboru.
Všimněte si, že toto nastavení lze přepsat jednotlivým tématem.
PohledPřihlášení k hypertextovému odkazu je viditelné. | | log.retention.check.interval.ms | 5 minut | Zkontrolujte interval mezi logem segmentovanými soubory, abyste zjistili, zda atributy souboru splňují požadavky na mazání. | | log.cleaner.enable | false | Pokud je tato vlastnost nastavena na false, bude smazána, jakmile je log uložen po maximální dobu nebo velikost. Pokud je nastaveno na true, stane se to, když atribut uloženého souboru dosáhne horní hranicePřihlášení k hypertextovému odkazu je viditelné.。 | | log.cleaner.threads | 1 | Počet vláken provádějících kompresi logů | | log.cleaner.io.max.bajtů.za.sekundu | Žádný | Maximální počet vstupů/výstupů, které může mít čistič logů při provádění kompaktace logů. Toto nastavení omezuje čističe, aby nezasahoval do aktivních služeb požadavků. | | log.cleaner.io.buffer.size | 500*1024*1024 | Log Cleaner indexuje logy během procesu čištění a snižuje velikost použité cache. Nejlepší je nastavit ho velkého, aby poskytl dostatek paměti. | | log.cleaner.io.buffer.load.factor | 512*1024 | Velikost I/O chunku potřebného pro čištění logů. Nemusíte toto nastavení měnit. | | log.cleaner.io.buffer.load.factor | 0.9 | load factor hashovací tabulky používané při čištění logů; Nemusíte tuto možnost měnit. | | log.cleaner.backoff.ms | 15000 | Provádí se časový interval, ve kterém je kláda vyčištěna | | log.cleaner.min.cleanable.ratio | 0.5 | Tato konfigurace určuje, jak často se kompaktor logů snaží logy vyčistit (předpokládá sePřihlášení k hypertextovému odkazu je viditelné.je otevřené). Ve výchozím nastavení se vyhněte čištění více než 50 % klád. Tento poměr je vázán na maximální prostor zabíraný záložním logem (50 % logů je komprimováno na 50 %). Vyšší sazba znamená méně odpadu a více prostoru lze efektivněji odklidit. Toto nastavení lze přepsat v každém tematickém nastavení.
PohledPřihlášení k hypertextovému odkazu je viditelné.。 | | log.cleaner.delete.retention.ms | 1 den | dobu skladování; Maximální doba potřebná k uchování stlačených klád; Je to také maximální doba, kterou klient zpracovává zprávy, a rozdíl mezi log.retention.minutes je v tom, že jeden ovládá nekomprimovaná data a druhý komprimovaná data, která budou přepsána do stanoveného času při vytvoření tématu. | | log.index.size.max.bajtů | 10*1024*1024 | Maximální velikost na jeden segment logu. Všimněte si, že pokud velikost logu dosáhne této hodnoty, je třeba vygenerovat nový segment logu, i když velikost nepřesahuje limit log.segment.bytes. | | log.index.interval.bytes | 4096 | Při načtení je potřeba prohledat nejbližší posun s určitým množstvím prostoru, čím větší nastavení, tím lépe, obecně používejte výchozí hodnotu | | log.flush.interval.messages | Long.MaxValue | Záznam se "synchronizuje" na disk před shromažďováním zpráv. Protože operace diskového IO jsou pomalá, ale zároveň nezbytným prostředkem "spolehlivosti dat", zkontrolujte, zda je potřeba časový interval pro vytvrzení na pevný disk. Pokud je tato hodnota příliš velká, povede to k příliš dlouhému "sync" času (IO blokování), pokud je tato hodnota příliš malá, povede to k dlouhému "fsync" (IO blokování), pokud je tato hodnota příliš malá, povede to k velkému počtu "sync" časů, což znamená, že celkový klientský požadavek má určité zpoždění a selhání fyzického serveru povede ke ztrátě zpráv bez fsync. | | log.flush.scheduler.interval.ms | Long.MaxValue | Zkontrolujte, zda jsou vyžadovány intervaly fsync | | log.flush.interval.ms | Long.MaxValue | Toto číslo se používá k řízení časového intervalu "fsync" – pokud počet zpráv nikdy nedosáhne počtu zpráv upevněných na disku, ale časový interval od poslední synchronizace disku dosáhne prahu, bude také spuštěna synchronizace disku. | | log.delete.delay.ms | 60000 | Doba uchovávání po vymazání souboru v indexu obvykle není třeba měnit | | auto.create.topics.enable | true | Zda povolit automatické vytváření témat. Pokud je to pravda, automaticky vytvoří téma, které neexistuje, když produce nebo fetch neexistují. Jinak musíte použít příkazovou řádku k vytvoření tématu | | controller.socket.timeout.ms | 30000 | Timeout čas socketu, kdy řadič správy partition provádí zálohu. | | controller.message.queue.size | Int.MaxValue | controller-to-broker-channles | | default.replication.factor | 1 | Výchozí počet záložních kopií se vztahuje pouze na automaticky vytvořená témata | | replica.lag.time.max.ms | 10000 | Pokud následovník neodešle požadavek na načtení v této době, vedoucí sledujícího odstraní z ISR a bude považován za zavěšeného | | replica.lag.max.zprávy | 4000 | Pokud má replika více než tento počet nezálohovaných, návazec odstraní následovník a považuje následovníka za zavěšeného | | replica.socket.timeout.ms | 30*1000 | Čas vypršení leaderů pro síťové požadavky socketu při zálohování dat | | replica.socket.receive.buffer.bytes | 64*1024 | Socket receive buffer při odesílání síťového požadavku leaderovi během zálohování | | replica.fetch.max.bajtů | 1024*1024 | Maximální hodnota každého načtení v době zálohování | | replica.fetch.min.bytes | 500 | Maximální čekací doba, než data dorazí k lídrovi, když vedoucí provede zálohovací požadavek | | replica.fetch.min.bytes | 1 | Nejmenší velikost odpovědi po každém načtení při zálohování | | num.replica.fetchers | 1 | Počet vláken, která zálohují data z leaderu | | replica.high.watermark.checkpoint.interval.ms | 5000 | Každá replika kontroluje, jak často se nejvyšší hladina vody vytvrzevá | | fetch.purgatory.purge.interval.requests | 1000 | fetch request purge interval | | producer.purgatory.purge.interval.requests | 1000 | Producent žádá o interval pročisty | | zookeeper.session.timeout.ms | 6000 | Časový limit seance ošetřovatele zoo. | | zookeeper.connection.timeout.ms | 6000 | Maximální doba, kterou klient čeká na navázání spojení se Zookeeperem | | zookeeper.sync.time.ms | 2000 | Následovník ZK zaostává za lídrem ZK po dlouhou dobu | | controlled.shutdown.enable | true | Zda je možné kontrolovat uzavření makléře. Pokud to bude možné, makléř bude schopen přesunout všechny lídry k jiným makléřům před uzavřením. To snižuje nedostupnost během procesu vypínání. | | controlled.shutdown.max.retries | 3 | Počet příkazů, které mohou úspěšně provést vypnutí před neúplným vypnutím. | | controlled.shutdown.retry.backoff.ms | 5000 | Doba zpětného odpojení mezi vypínáním | | auto.leader.rebalance.enable | true | Pokud je to pravda, kontrolor automaticky vyvažuje vedení brokerů nad oddíly | | leader.imbalance.per.broker.percentage | 10 | Maximální poměr nerovnováhy povolený každým makléřem | | leader.imbalance.check.interval.seconds | 300 | Zkontrolujte frekvenci nerovnováhy leaderů | | offset.metadata.max.bajtů | 4096 | Umožňuje klientům uložit maximální počet jejich offsetů | | max.connections.per.ip | Int.MaxValue | Maximální počet spojení na jednoho brokera může být navázán na každou IP adresu | | max.connections.per.ip.overrides | | Maximální pokrytí výchozího připojení na jednu IP nebo hostitelské jméno | | connections.max.idle.ms | 600000 | Časový limit pro prázdné připojení | | log.roll.jitter. {ms,hours} | 0 | Maximální počet jitterů abstrahovaný z logRollTimeMillis | | num.recovery.threads.per.data.dir | 1 | Počet vláken, která každý datový adresář používá k logování obnovy | | nečistý.vůdce.volba.povolit | true | Uvádí, zda je možné použít nastavení non-replicas v ISR jako leader | | delete.topic.enable | false | Schopnost mazat témata | | offsets.topic.num.partitions | 50 | Počet oddílů pro téma offsetového commitu. Protože změna této hodnoty po nasazení není aktuálně podporována, doporučujeme pro produkci použít vyšší nastavení (např. 100-200). | | offsets.topic.retention.minutes | 1440 | Offsety, které existovaly déle než tento časový limit, budou označeny jako čekající na smazání | | offsets.retention.check.interval.ms | 600000 | Správce offsetů kontroluje frekvenci starých offsetů | | offsets.topic.replication.factor | 3 | Počet záložních kopií offsetu tématu. Doporučuje se nastavit vyšší čísla, aby byla zajištěna vyšší dostupnost | | offset.topic.segment.bytes | 104857600 | Téma kompenzací. | | offsets.load.buffer.size | 5242880 | Toto nastavení souvisí s velikostí dávky a používá se při čtení z offsetového segmentu. | | offsets.commit.required.acks | -1 | Počet potvrzení musí být stanoven, než je offsetový commit přijatelný, a obecně není nutné jej měnit |
| Nemovitosti | Výchozí | Výchozí vlastnost serveru | Popis | | cleanup.policy | smazat | log.cleanup.policy | Buď "smazat" nebo "zkompaktovat"; Tento řetězec ukazuje, jak využít starou logaritmickou část; Výchozí metoda ("smazat") starý díl vyhodí, jakmile je dosaženo jejich doby recyklace nebo limitu velikosti. "kompaktní" stlačí klády | | delete.retention.ms | 86400000 (24 hodin) | log.cleaner.delete.retention.ms | Rozdíl mezi log.retention.minutes je v tom, že jeden ovládá nekomprimovaná data a druhý komprimovaná data. Tuto konfiguraci lze přepsat parametry připnutí při vytváření tématu | | flush.messages | Žádný | log.flush.interval.messages | Tato konfigurace specifikuje časový interval pro vynucení fsync logů. Například pokud je tato možnost nastavena na 1, je po každé zprávě vyžadován fsync, a pokud je nastaven na 5, fsync je vyžadován pro každých 5 zpráv. Obecně se doporučuje tuto hodnotu nenastavovat. Nastavení tohoto parametru vyžaduje nutný kompromis mezi "spolehlivostí dat" a "výkonem". Pokud je tato hodnota příliš velká, způsobí dlouhou dobu "fsync" pokaždé (IO blokování), a pokud je tato hodnota příliš malá, povede to k velkému počtu "fsync", což také znamená, že celkový klientský požadavek má určité zpoždění. Fyzické selhání serveru způsobí ztrátu zpráv bez fsync. | | flush.ms | Žádný | log.flush.interval.ms | Tato konfigurace slouží k připnutí časového intervalu mezi vynucením fsync logů na disk; Například pokud je nastaveno na 1000, pak je fsync vyžadován každých 1000 ms. Tato možnost se obecně nedoporučuje | | index.interval.bytes | 4096 | log.index.interval.bytes | Výchozí nastavení zajišťuje, že ke zprávě přidáváme index každých 4096 bajtů a více indexů přibližuje čtenou zprávu, ale velikost indexu se zvýší. Tato možnost obvykle není nutná | | max.message.bytes | 1000000 | max.message.bytes | Maximální velikost zprávy Kafka append. Všimněte si, že pokud tuto velikost zvětšíte, musíte také zvýšit velikost načítaní vašeho spotřebitele, aby mohl spotřebitel načítat zprávy na těchto maximálních velikostech. | | min.cleanable.dirty.ratio | 0.5 | min.cleanable.dirty.ratio | Tato konfigurace ovládá, jak často se stlačovač dřeva snaží dřevo vyčistit. Ve výchozím nastavení se vyhýbáme záznamům s mírou komprese vyšší než 50 %. Tento poměr zabraňuje největšímu plýtvání místem | | min.insync.replicas | 1 | min.insync.replicas | Když je producent nastaven na request.required.acks na -1, min.insync.replicas určí minimální počet replik (každý zápis v repice musí být úspěšný), a pokud tohoto čísla není dosaženo, producent vytvoří výjimku. | | retention.bytes | Žádný | log.retention.bytes | Pokud použijete politiku "delete" retention, tato konfigurace označuje maximální velikost, které může log dosáhnout před jeho smazáním. Ve výchozím nastavení neexistuje žádný limit velikosti, pouze časový limit | | retention.ms | 7 dní | log.retention.minutes | Pokud použijete politiku "delete" retention, tato konfigurace se vztahuje k době, kdy byl log uložen před záznamem o mazání. | | segment.bytes | 1GB | log.segment.bytes | V Kafkově jsou klády klády ukládány v částech a tato konfigurace označuje velikost klád dělených na části | | segment.index.bytes | 10MB | log.index.size.max.bajtů | Tato konfigurace je přibližně velikosti indexového souboru mapovaného mezi offsety a místa souboru; Tato konfigurace obvykle není třeba upravovat | | segment.ms | 7 dní | log.roll.hours | I když soubor log chunk nedosáhne velikosti, kterou je třeba smazat nebo komprimovat, jakmile log time dosáhne této horní hranice, bude nucen nový log chunk soubor | | segment.jitter.ms | 0 | log.roll.jitter. {ms,hours} | Maximální jitter pro odečtení od logRollTimeMillis. |
Konfigurace pro spotřebitele
| Nemovitosti | Výchozí | Popis | | group.id | | Řetězec, který jednoznačně identifikuje skupinu, ve které se nachází spotřebitelský proces, a pokud je nastaveno stejné ID skupiny, znamená to, že tyto procesy patří do stejné spotřebitelské skupiny | | zookeeper.connect | | Zadejte řetězec připojení Zookeeper, formát je hostname:port, zde jsou host i port jak hostitel, tak port serveru Zookeeper, abyste nepřišli o kontakt po výpadku stroje Zookeeper, můžete nastavit více hostname:ports, přičemž jako oddělení je uvedeno čárky:
Název hostitele1:Port1,Název hostitele2:Port2,Název hostitele3:Port3
Cestu chroot ZooKeeperu můžete přidat k řetězci připojení ZooKeeperu, který slouží k ukládání vlastních dat, a to tak:
hostname1:port1,hostname2:port2,hostname3:port3/chroot/path | | consumer.id | nula | Není potřeba žádné nastavení a obvykle se generuje automaticky | | socket.timeout.ms | 30*100 | Časové limity pro síťové požadavky. Skutečný limit časového limitu je max.fetch.wait+socket.timeout.ms | | socket.receive.buffer.bytes | 64*1024 | socket se používá k přijímání velikosti cache síťových požadavků | | fetch.message.max.bajtů | 1024*1024 | Maximální počet bajtů na jednu načítací zprávu na jeden požadavek na načítání. Tyto bajty budou dohledem v paměti používané pro každou partition, takže toto nastavení bude řídit množství paměti používané uživatelem. Velikost požadavku na načtení musí být alespoň rovna maximální velikosti zprávy povolené serverem, jinak je velikost zprávy, kterou může producent odeslat, větší než velikost, kterou může spotřebitel spotřebovat. | | num.consumer.fetchers | 1 | Počet načítacích vláken použitých pro načtení dat | | auto.commit.enable | true | Pokud je to pravda, posun zprávy načtené uživatelem bude automaticky synchronizován se zookeeperem. Tento commit offset použije nový spotřebitel, když se proces zasekne | | auto.commit.interval.ms | 60*1000 | Frekvence, s jakou spotřebitel odesílá offset ošetřovači v zookeeperovi, je v několika sekundách | | queued.max.message.chunks | 2 | Maximální počet zpráv použitých k ukládání do mezipaměti pro konzumaci. Každý blok musí být stejný jako fetch.message.max.bajt | | rebalance.max.retries | 4 | Když je do skupiny přidán nový spotřebitel, skupina se snaží vyrovnat počet oddílů přidělených každému spotřebiteli. Pokud se změní kolekce spotřebitelů, toto vyvažování selže a znovu se přidá při provádění alokace | | fetch.min.bytes | 1 | Minimální počet bajtů, které by měl server vrátit při každém načítacím požadavku. Pokud není vráceno dostatek dat, požadavek počká, dokud nebude vráceno dostatečné množství dat. | | fetch.wait.max.ms | 100 | Pokud není dostatek dat pro uspokojení fetch.min.bytes, tato konfigurace označuje maximální dobu, kterou server zablokuje před odpovědí na fetch požadavek. | | rebalance.backoff.ms | 2000 | Čas zpět před opětovným pokusem o Reblance | | refresh.leader.backoff.ms | 200 | Existuje čas na odstoupení, než se pokusíte zjistit, zda vůdce rozdělení ztratil své vedení | | auto.offset.reset | největší | Pokud v Zookeeperu není inicializovaný offset, pokud offset je reakcí na následující hodnotu:
nejmenší: Automatický reset offset na nejmenší offset
největší: Automatický reset offset na offset největšího
Cokoli jiného: Vyhodí výjimku pro spotřebitele | | consumer.timeout.ms | -1 | Pokud není žádná zpráva dostupná, i po určité době čekání, vyhodí se výjimka pro časový limit | | exclude.internal.topics | true | Zda zpřístupnit zprávy z interních témat spotřebitelům | | paritition.assignment.strategy | Rozsah | Vyberte politiku pro přiřazování oddílů spotřebitelskému toku, volitelně rozsah, roundrobin | | client.id | Hodnota ID skupiny | je uživatelsky specifický řetězec, který pomáhá sledovat volání v každém požadavku. Logicky by měl potvrdit aplikaci, která požadavek vygenerovala | | zookeeper.session.timeout.ms | 6000 | Časové limity pro sezení u ošetřovatele zoo. Pokud spotřebitel během této doby neodešle zprávu o srdečním tepu ošetřovateli zoo, považuje se za zavěšenou a vznikne reblance | | zookeeper.connection.timeout.ms | 6000 | Maximální čekací doba pro navázání spojení se Zookeeperem klientem | | zookeeper.sync.time.ms | 2000 | Následovníci ZK mohou za lídrem ZK zaostávat maximálně dlouho | | offsets.storage | Zookeeper | Místa používaná pro skladování offsetů: Zookeeper nebo Kafka | | offset.channel.backoff.ms | 1000 | Doba zpětného připojení k kanálu offsetů nebo opětovného pokusu o načtení/commit neúspěšného offsetu | | offsets.channel.socket.timeout.ms | 10000 | Limit vypršení socketu pro odpověď na odpověď na požadavek na načtení/commit při čtení offsetu. Tento časový limit využívá požadavek consumerMetadata k žádosti o správu offsetů | | offsets.commit.max.retries | 5 | Počet pokusů o offsetový commit byl znovu zkoušen. Tento pokus se používá pouze pro offsetové commity mezi vypnutími. On | | dual.commit.enabled | true | Pokud použijete "kafka" jako offsets.storage, můžete offset commitovat do zookeeperu dvakrát (a jednou do kafky). To je nezbytné při migraci z offsetového úložiště založeného na Zookeeperu na offsetové úložiště založené na Kafce. Pro jakoukoli skupinu spotřebitelů je bezpečné tuto možnost po dokončení migrace vypnout | | partition.assignment.strategy | Rozsah | Vyberte si mezi politikami "rozsah" a "roundrobin" jako politiku pro přiřazování oddílů spotřebitelským datovým tokům; Kruhový alokátor oddílů alokuje všechny dostupné oddíly i všechna dostupná spotřebitelská vlákna. Přiřadí smyčku oddílu ke spotřebitelskému vláknu. Pokud jsou všechny instance spotřebitelů přidány k determinovanému, rozdělení se rozdělí na deterministické distribuce. Strategie alokace round-robin je možná pouze tehdy, pokud jsou splněny následující podmínky: (1) Každé téma má stejný počet datových toků na počet spotřebitelů. (2) Výběr předplacených témat je určen pro každou spotřebitelskou instanci ve skupině spotřebitelů. |
Konfigurace producentů
| Nemovitosti | Výchozí | Popis | | metadata.broker.list | | Obsluhujte si vlastní vlastní péči. Producer se používá pouze k získání metadat (témata, oddíly, repliky). Připojení socketu pro odeslání skutečných dat bude navázáno na základě vrácených metadat. Formát je:
host1:port1,host2:port2
Tento seznam může být podseznamem makléřů nebo VIP odkazujícím na makléře | | request.required.acks | 0 | Tato konfigurace je hodnotou potvrzení, která ukazuje, kdy je požadavek na produkci považován za dokončený. Konkrétně kolik dalších makléřů muselo zadávat data do svých logů a potvrdit je svému vedoucímu. Typické hodnoty zahrnují:
0: Označuje, že producent nikdy nečeká na potvrzení od makléře (stejné chování jako u 0,7). Tato možnost poskytuje nejmenší latenci, ale zároveň největší riziko (protože data se ztratí, když server vypadne).
1: Označuje, že replika vedoucího obdržela potvrzení dat. Tato možnost má nízkou latenci a zajišťuje, že server potvrdí přijetí.
-1: Producent získá potvrzení, že všechny synchronizované repliky obdržely data. Latence je největší, ale tato metoda zcela neeliminuje riziko ztráty zpráv, protože počet synchronizovaných replik může být 1. Pokud chcete zajistit, že některé repliky přijímají data, měli byste v nastavení na úrovni tématu nastavit možnost min.insync.replicas. Přečtěte si návrhovou dokumentaci pro podrobnější diskusi. | | request.timeout.ms | 10000 | Broker se snaží co nejlépe implementovat požadavek request.required.acks, jinak bude klientovi odeslána chyba | | producer.type | synchronizace | Tato možnost určuje, zda je zpráva odeslána asynchronně v pozadí vlákna. Správné hodnoty:
(1) async: Asynchronní odesílání
(2) synchronizace: Synchronizované odesílání
Nastavením producenta na asynchronní režim můžeme zpracovávat požadavky v dávkách (což je dobré pro vyšší propustnost), ale zároveň to vytváří možnost, že klientský stroj přijde o neodeslaná data | | serializer.class | kafka.serializer.DefaultEncoder | Kategorie serializace zprávy. Výchozí enkodér zadá jeden bajt[] a vrátí stejný bajt[] | | key.serializer.class | | Třída serializace pro klíčová slova. Pokud to není uvedeno, výchozí je odpovídat zprávě | | partitioner.class | kafka.producer.DefaultPartitioner | třída partitioner pro rozdělení zpráv mezi podtémata. Výchozí partitioner je založen na hashovací tabulce klíče | | Compression.codec | žádný | Tento parametr může nastavit kodek pro kompresi dat, který lze zvolit jako "none", "gzip", "snappy". | | compressed.topics | nula | Tento parametr lze použít k nastavení, zda jsou určitá témata komprimována. Pokud je komprimovaný kodek jiný než NoCompressCodec, tyto kodeky se aplikují na specifikovaná témata. Pokud je seznam komprimovaných témat prázdný, aplikujte konkrétní komprimovaný kodek na všechna témata. Pokud je komprimovaný kodek NoCompressionCodec, komprese není dostupná pro všechna témata. | | message.send.max.retries | 3 | Tento parametr způsobí, že producent automaticky zkusí znovu neúspěšné požadavky na odeslání. Tento parametr určuje počet opakovaných pokusů. Poznámka: Nastavení hodnoty ne-0 způsobí opakování určitých síťových chyb: způsobí odesílání a ztrátu potvrzení | | retry.backoff.ms | 100 | Před každým opakovaným pokusem producent aktualizuje metadata příslušného tématu, aby zjistil, zda je nový vedoucí přiřazen. Protože výběr lídra trvá trochu času, tato možnost určuje, jak dlouho musí producent čekat před aktualizací metadat. | | topic.metadata.refresh.interval.ms | 600*1000 | Producent obvykle aktualizuje metadata tématu v některých scénářích selhání (chybějící oddíl, nedostupný leader atd.). Projde pravidelným cyklem. Pokud nastavíte zápornou hodnotu, metadata se aktualizují pouze v případě selhání. Pokud je nastaveno na 0, metadata se aktualizují po odeslání každé zprávy (tato možnost se nedoporučuje, systém spotřebovává příliš mnoho informací). Důležité: Aktualizace nastávají až po odeslání zprávy, takže pokud producent zprávu nikdy neodešle, metadata se nikdy neaktualizují. | | queue.buffering.max.ms | 5000 | Maximální časový interval, ve kterém uživatel ukládá data do mezipaměti při použití asynchronního režimu. Například pokud je zpráva nastavena na 100, zprávy do 100 ms budou zpracovány v dávkách. To zlepší propustnost, ale zvýší latenci kvůli cachování. | | queue.buffering.max.messages | 10000 | Při použití asynchronního režimu musí být maximální počet neodeslaných zpráv, které lze do fronty uložit do mezipaměti před producentem, zablokován nebo ztracena data | | batch.num.messages | 200 | Při použití asynchronního režimu můžete hromadně zpracovat maximální počet zpráv. Nebo počet zpráv dorazil online nebo queue.buffer.max.ms dorazil a producent to zpracuje | | send.buffer.bytes | 100*1024 | Velikost cache pro zápis socketu | | client.id | “” | Toto client id je uživatelsky specifický řetězec, který je zahrnut v každém požadavku na sledování hovoru, a logicky by měl být schopen potvrdit, že aplikace požadavek provedla. |
Konfigurace producentů
| Jméno | Typ | Výchozí | Význam | Popis | | boostrap.servers | Seznam | | vysoký | Host/port skupina pro navázání spojení s Kafka clusterem. Data budou načítána rovnoměrně napříč všemi servery, bez ohledu na to, který server je určen pro bootstrap. Tento seznam se týká pouze inicializovaných hostitelů (který se používá k objevení všech serverů). Tento formát seznamu:
host1:port1,host2:port2,...
Protože tyto servery slouží pouze k inicializaci spojení za účelem zjištění všech členství clusteru (které se mohou dynamicky měnit), nemusí tento seznam obsahovat všechny servery (možná budete chtít více než jeden server, i když v tomto případě může být jeden server nedostupný). Pokud se v tomto seznamu neobjeví žádný server, odesílání dat selže, dokud nebude seznam dostupný. | | ACKS | Struna | 1 | vysoký | Producent potřebuje signál od serveru k potvrzení přijetí dat po přijetí, a tato konfigurace se týká, kolik takových potvrzovacích signálů dodavatel potřebuje. Tato konfigurace ve skutečnosti představuje dostupnost datových záloh. Následující nastavení jsou běžné možnosti:
(1) acks=0: Nastaveno na 0 znamená, že producent nemusí čekat na potvrzení obdržených informací. Replika bude ihned přidána do socket bufferu a považována za odeslánou. V tomto případě není zaručeno, že server data úspěšně přijal, a opakování konfigurace nebude fungovat (protože klient neví, zda selhalo) a offset zpětné vazby bude vždy nastaven na -1.
(2) acks=1: To znamená, že alespoň počkat, až vedoucí úspěšně zapíše data do lokálního logu, ale ne na úspěšný zápis všech následovníků. V takovém případě, pokud follower data úspěšně nezálohuje a vedoucí opět zavěsí, zpráva se ztratí.
(3) acks=all: To znamená, že vedoucí musí počkat, až všechny zálohy úspěšně zapíšou logy, a tato strategie zajistí, že data nebudou ztracena, pokud jedna záloha přežije. To je nejsilnější záruka.
(4) Jsou možné i jiné nastavení, například acks=2, které vyžadují určitý počet acks, ale tato strategie se obecně používá jen zřídka. | | buffer.memory | dlouhý | 33554432 | vysoký | Producent může být použit k ukládání velikosti paměti dat. Pokud jsou data generována rychleji, než jsou odeslána brokerovi, producent zablokuje nebo vyhodí výjimku, označenou jako "block.on.buffer.full".
Toto nastavení bude souviset s celkovou pamětí, kterou může producent vydat, ale není to pevný limit, protože ne veškerá paměť použitá producentem je využita pro cache. Část další paměti se používá pro kompresi (pokud je komprese zavedena) a část pro požadavky na údržbu. | | komprese.typ | Struna | žádný | vysoký | Producer je typ komprese používaný k kompresi dat. Výchozí nastavení je nekomprimované. Správné hodnoty voleb jsou žádné, gzip, snappy.
Komprese je nejlepší pro dávkové zpracování, čím více zpráv je zpracováno v dávkách, tím lepší je výkon komprese. | | Opakované pokusy | int | 0 | vysoký | Nastavení hodnoty větší než 0 způsobí, že klient odešle jakákoli data znovu, jakmile tato data selžou. Všimněte si, že tyto opakované pokusy se neliší od těch, kdy klient obdrží chybu odeslání. Umožňuje opakované pokusy potenciálně změnit pořadí dat, pokud jsou oba záznamy zpráv odeslány na stejnou partci, první zpráva selže, druhá zpráva se objeví dříve než první. | | batch.size | int | 16384 | Středně | Producent se pokusí dávkovat záznamy zpráv, aby snížil počet požadavků. To zlepší výkon mezi klientem a serverem. Tato konfigurace řídí výchozí počet bajtů zpráv pro dávkové zpracování.
Nepokusí se zpracovat bajty zpráv větší než tento počet bajtů.
Požadavky zasílané brokerům budou obsahovat více dávek, které budou obsahovat jeden požadavek pro každou partition.
Menší hodnoty dávkování se používají méně a mohou snížit propustnost (0 používá pouze dávkové zpracování). Větší dávkové hodnoty zabírají více místa v paměti, takže musíte alokovat paměť na konkrétní dávkové hodnoty. | | client.id | Struna | | Středně | Tento řetězec je odeslán serveru při odeslání požadavku. Účelem je být schopen sledovat zdroj požadavků, aby některé aplikace mimo IP/Port povolený seznam mohly odesílat informace. Tato aplikace může nastavit jakýkoli řetězec, protože nemá žádný funkční účel kromě nahrávání a sledování | | linger.ms | dlouhý | 0 | Středně | Skupina producentů agreguje všechny zprávy, které dorazí mezi požadavek a odeslání, a zaznamenává samostatnou dávku požadavků. Obvykle se to děje pouze tehdy, když je záznam generován rychleji než je rychlost odesílání. Za určitých podmínek však klient bude chtít snížit počet požadavků, nebo dokonce na střední zátěž. Toto nastavení se provádí přidáním malého zpoždění – tj. místo okamžitého odeslání záznamu producent počká na určitou dobu zpoždění, aby mohl odesílat další záznamy zpráv, které lze batchovat. Tento algoritmus lze považovat za podobný TCP Nagle. Toto nastavení nastavuje vyšší latenci pro batch zpracování: jakmile získáme velikost batch.party party, odešle ji okamžitě bez ohledu na toto nastavení, ale pokud dostaneme zprávu s mnohem menším počtem bajtů než toto nastavení, musíme "setrvat" v určitém čase, abychom dostali více zpráv. Toto nastavení je výchozí nastaveno na 0, tedy bez zpoždění. Nastavení linger.ms=5 například sníží počet požadavků, ale zároveň prodlouží zpoždění o 5 ms. | | max.request.size | int | 1028576 | Středně | Maximální počet požadovaných bajtů. To je také efektivní pokrytí pro maximální zaznamenanou velikost. Poznámka: Server má vlastní přepsání velikosti záznamů zpráv, které se liší od tohoto nastavení. Toto nastavení omezuje počet požadavků, které mohou výrobci najednou posílat hromadně, aby se zabránilo velkému počtu požadavků. | | receive.buffer.bytes | int | 32768 | Středně | TCP velikost cache přijímající, která se používá při čtení dat | | send.buffer.bytes | int | 131072 | Středně | Velikost TCP cache pro odesílání, která se používá při odesílání dat | | timeout.ms | int | 30000 | Středně | Tato konfigurační možnost určuje maximální dobu, po kterou server čeká na potvrzení od sledujících. Pokud není v tomto čase splněn počet potvrzených požadavků, vrátí se chyba. Tento časový limit se měří na straně serveru a nemá síťovou latenci včetně požadavků | | block.on.buffer.full | Booleovský | true | nízké | Když nám dojde paměťová cache, musíme přestat přijímat nové záznamy zpráv nebo vyhazovat chyby. Ve výchozím nastavení je to nastaveno na true, ale některé blokování nemusí být očekávané, takže je lepší hodit chybu hned. To je případ nastaveného na false: producent vyhodí chybu výjimky: BufferExhaustedException, pokud byl záznam odeslán a cache je plná | | metadata.fetch.timeout.ms | dlouhý | 60000 | nízké | Odkazuje na data o prvním čase některých prvků, která jsme získali. Prvky zahrnují: téma, hostitel, partitiony. Tato konfigurace označuje dobu potřebnou k úspěšnému dokončení prvku podle fetch, jinak bude klientovi zaslána výjimka. | | metadata.max.age.ms | dlouhý | 300000 | nízké | Čas v mikrosekundách je interval, ve kterém vynucujeme aktualizaci metadat. I když neuvidíme žádné změny vedení rozdělení. | | metric.reporters | Seznam | [] | nízké | Seznam tříd používaných k měření metrik. Implementace rozhraní MetricReporter umožní přidávání tříd, které se mění při generování nových metrik. JmxReporter vždy bude obsahovat možnost registrovat statistiky JMX | | metrics.num.samples | int | 2 | nízké | Počet vzorků použitých k udržení metrik | | metrics.sample.window.ms | dlouhý | 30000 | nízké | Systém metrik udržuje konfigurovatelný počet vzorků v korigovatelné velikosti okna. Tato konfigurace například konfiguruje velikost okna. Můžeme uchovávat dva vzorky po dobu 30 sekund. Když se okno rozroluje, vymažeme a přepseme to nejstarší okno | | recoonect.backoff.ms | dlouhý | 10 | nízké | Když spojení selže, čekací doba při opětovném připojení. Tím se zabrání opakovaným opětovným připojením klientů | | retry.backoff.ms | dlouhý | 100 | nízké | Čekací doba před pokusem o opakování neúspěšné žádosti o ovoce. Vyhněte se slepému odeslávání a neúspěchu.
|
|
Zveřejněno 24.06.2021 11:47:12
|
|
|
Pronajímatel