【文章內(nèi)容簡介】 間上的浪費(fèi)，會被topic創(chuàng)建時(shí)的指定參數(shù)覆蓋1 day對于壓縮的日志保留的最長時(shí)間，也是客戶端消費(fèi)消息的最長時(shí)間，一個(gè)控制壓縮后的數(shù)據(jù)。會被topic創(chuàng)建時(shí)的指定參數(shù)覆蓋 10 * 1024 * 1024對于segment日志的索引文件大小限制，會被topic創(chuàng)建時(shí)的指定參數(shù)覆蓋4096當(dāng)執(zhí)行一個(gè)fetch操作后，需要一定的空間來掃描最近的offset大小，設(shè)置越大，代表掃描速度越快，但是也更好內(nèi)存，一般情況下不需要搭理這個(gè)參數(shù)log文件”sync”到磁盤之前累積的消息條數(shù),因?yàn)榇疟PIO操作是一個(gè)慢操作,但又是一個(gè)”數(shù)據(jù)可靠性的必要手段,所以此參數(shù)的設(shè)置,需要在數(shù)據(jù)可靠性與性能,將會導(dǎo)致每次fsync的時(shí)間較長(IO阻塞),如果此值過小,將會導(dǎo)致fsync的次數(shù)較多,將會導(dǎo)致沒有fsync的消息丟失.檢查是否需要固化到硬盤的時(shí)間間隔 = None僅僅通過interval來控制消息的磁盤寫入時(shí)機(jī),fsync的時(shí)間間隔,如果消息量始終沒有達(dá)到閥值,但是離上一次磁盤同步的時(shí)間間隔達(dá)到閥值,也將觸發(fā). 60000文件在索引中清除后保留的時(shí)間一般不需要去修改60000控制上次固化硬盤的時(shí)間點(diǎn)，以便于數(shù)據(jù)恢復(fù)一般不需要去修改60000the amount of time to wait before deleting a file from the filesystem.true是否允許自動(dòng)創(chuàng)建topic，若是false，就需要通過命令創(chuàng)建topic1自動(dòng)創(chuàng)建的topic默認(rèn) replication factor1每個(gè)topic的分區(qū)個(gè)數(shù)，若是在topic創(chuàng)建時(shí)候沒有指定的話會被topic創(chuàng)建時(shí)的指定參數(shù)覆蓋以下是kafka中Leader,replicas配置參數(shù) 30000partitionleader與replicas之間通訊時(shí),socket的超時(shí)時(shí)間partitionleader與replicas數(shù)據(jù)同步時(shí),消息的隊(duì)列尺寸10000replicas響應(yīng)partitionleader的最長等待時(shí)間，若是超過這個(gè)時(shí)間，就將replicas列入ISR(insync replicas)，并認(rèn)為它是死的，不會再加入管理中4000如果follower落后與leader太多,將會認(rèn)為此follower[或者說partitionrelicas]已經(jīng)失效通常,在follower與leader通訊時(shí),因?yàn)榫W(wǎng)絡(luò)延遲或者鏈接斷開,總會導(dǎo)致replicas中消息同步滯后如果消息之后太多,leader將認(rèn)為此follower網(wǎng)絡(luò)延遲較大或者消息吞吐能力有限,將會把此replicas遷移到其他follower中.在broker數(shù)量較少,或者網(wǎng)絡(luò)不足的環(huán)境中,建議提高此值.30 * 1000follower與leader之間的socket超時(shí)時(shí)間64 * 1024leader復(fù)制時(shí)候的socket緩存大小1024*1024replicas每次獲取數(shù)據(jù)的最大大小 500replicas同leader之間通信的最大等待時(shí)間，失敗了會重試1fetch的最小數(shù)據(jù)尺寸,如果leader中尚未同步的數(shù)據(jù)不足此值,將會阻塞,直到滿足條件1leader進(jìn)行復(fù)制的線程數(shù)，增大這個(gè)數(shù)值會增加follower的IO5000每個(gè)replica檢查是否將最高水位進(jìn)行固化的頻率1000The purge interval (in number of requests) of the fetch request purgatory.6000The purge interval (in number of requests) of the producer request purgatory.true是否允許控制器關(guān)閉broker ,若是設(shè)置為true,會關(guān)閉所有在這個(gè)broker上的leader，并轉(zhuǎn)移到其他broker3控制器關(guān)閉的嘗試次數(shù) 5000每次關(guān)閉嘗試的時(shí)間間隔tureIf this is enabled the controller will automatically try to balance leadership for partitions among the brokers by periodically returning leadership to the preferred replica for each partition if it is available. 10leader的不平衡比例，若是超過這個(gè)數(shù)值，會對分區(qū)進(jìn)行重新的平衡300檢查leader是否不平衡的時(shí)間間隔4096客戶端保留offset信息的最大空間大小nullzookeeper集群的地址，可以是多個(gè)，多個(gè)之間用逗號分割hostname1:port1,hostname2:port2,hostname3:port36000ZooKeeper的最大超時(shí)時(shí)間，就是心跳的間隔，若是沒有反映，那么認(rèn)為已經(jīng)死了，不易過大6000ZooKeeper的連接超時(shí)時(shí)間2000ZooKeeper集群中l(wèi)eader和follower之間的同步實(shí)際那The maximum number of connections that a broker allows from each ip address.Perip or hostname overrides to the default maximum number of connections.600000Idle connections timeout: the server socket processor threads close the connections that idle more than this..{ms,hours}0隨機(jī)的一個(gè)抖動(dòng)時(shí)間1The number of threads per data directory to be used for log recovery at startup and flushing at shutdowntrueIndicates whether to enable replicas not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss.falseEnable delete topic.50The number of partitions for the offset mit topic. Since changing this after deployment is currently unsupported, we remend using a higher setting for production1440存在時(shí)間超過這個(gè)時(shí)間限制的offsets都將被標(biāo)記為待刪除600000offset管理器檢查陳舊offsets的頻率3topic的offset的備份份數(shù)。建議設(shè)置更高的數(shù)字保證更高的可用性104857600offsets topic的segment大小5242880這項(xiàng)設(shè)置與批量尺寸相關(guān)，當(dāng)從offsets segment中讀取時(shí)使用。1在offset mit可以接受之前，需要設(shè)置確認(rèn)的數(shù)目，一般不需要更改. This is similar to the producer39。s acknowledgement setting. In general, the default should not be overridden.5000The offset mit will be delayed until this timeout or the required number of replicas have received the offset mit. This is similar to the producer request timeout.topiclevel的配置有關(guān)topics的配置既有全局的又有每個(gè)topic獨(dú)有的配置。如果沒有給定特定topic設(shè)置，則應(yīng)用默認(rèn)的全局設(shè)置。這些覆蓋會在每次創(chuàng)建topic發(fā)生。下面的例子：創(chuàng)建一個(gè)topic，命名為mytopic，自定義最大消息尺寸以及刷新比率為： bin/ zookeeper localhost:2181 create topic mytopic partitions 1 replicationfactor 1 config =64000 config =1需要?jiǎng)h除重寫時(shí)，可以按照以下來做： bin/ zookeeper localhost:2181 alter topic mytopic deleteConfig 以下是topiclevel的配置選項(xiàng)。server的默認(rèn)配置在Server Default Property列下給出了，設(shè)定這些默認(rèn)值不會改變原有的設(shè)置PropertyDefaultServer Default PropertyDescriptiondelete要么是”delete“要么是”pact“； 這個(gè)字符串指明了針對舊日志部分的利用方式；默認(rèn)方式（delete）將會丟棄舊的部分當(dāng)他們的回收時(shí)間或者尺寸限制到達(dá)時(shí)。”pact“將會進(jìn)行日志壓縮86400000 (24 hours)對于壓縮日志保留的最長時(shí)間，也是客戶端消費(fèi)消息的最長時(shí)間，一個(gè)控制壓縮后的數(shù)據(jù)。此項(xiàng)配置可以在topic創(chuàng)建時(shí)的置頂參數(shù)覆蓋None此項(xiàng)配置指定時(shí)間間隔：強(qiáng)制進(jìn)行fsync日志。例如，如果這個(gè)選項(xiàng)設(shè)置為1，那么每條消息之后都需要進(jìn)行fsync，如果設(shè)置為5，則每5條消息就需要進(jìn)行一次fsync。一般來說，建議你不要設(shè)置這個(gè)值。此參數(shù)的設(shè)置,需要在數(shù)據(jù)可靠性與性能,將會導(dǎo)致每次fsync的時(shí)間較長(IO阻塞),如果此值過小,將會導(dǎo)致fsync的次數(shù)較多,將會導(dǎo)致沒有fsync的消息丟失.None此項(xiàng)配置用來置頂強(qiáng)制進(jìn)行fsync日志到磁盤的時(shí)間間隔；例如，如果設(shè)置為1000，那么每1000ms就需要進(jìn)行一次fsync。一般不建議使用這個(gè)選項(xiàng)4096默認(rèn)設(shè)置保證了我們每4096個(gè)字節(jié)就對消息添加一個(gè)索引，更多的索引使得閱讀的消息更加靠近，但是索引規(guī)模卻會由此增大；一般不需要改變這個(gè)選項(xiàng)1000000kafka追加消息的最大尺寸。注意如果你增大這個(gè)尺寸，你也必須增大你consumer的fetch 尺寸，這樣consumer才能fetch到這些最大尺寸的消息。此項(xiàng)配置控制log壓縮器試圖進(jìn)行清除日志的頻率。默認(rèn)情況下，將避免清除壓縮率超過50%的日志。這個(gè)比率避免了最大的空間浪費(fèi)1，（必須確認(rèn)每一個(gè)repica的寫數(shù)據(jù)都是成功的），如果這個(gè)數(shù)目沒有達(dá)到，producer會產(chǎn)生異常。None如果使用“delete”的retention 策略，這項(xiàng)配置就是指在刪除日志之前，日志所能達(dá)到的最大尺寸。默認(rèn)情況下，沒有尺寸限制而只有時(shí)間限制7 days如果使用“delete”的retention策略，這項(xiàng)配置就是指刪除日志前日志保存的時(shí)間。1GBkafka中l(wèi)og日志是分成一塊塊存儲的，此配置是指log日志劃分成塊的大小10MB此配置是有關(guān)offsets和文件位置之間映射的索引文件的大??；一般不需要修改這個(gè)配置7 days即使log的分塊文件沒有達(dá)到需要?jiǎng)h除、壓縮的大小，一旦log 的時(shí)間達(dá)到這個(gè)上限，就會強(qiáng)制新建一個(gè)log分塊文件0.{ms,hours}The maximum jitter to subtract from logRollTime