Broker的一般配置

有很多參數在部署集群模式時需要引起重視，這些參數都是broker最基本的配置，很多參數都需要依據集群的broker情況而變化。

broker.id

每個kafka的broker都需要有一個整型的唯一標識，這個標識通過broker.id來設置。默認的情況下，這個數字是0，但是它可以設置成任何值。需要注意的是，需要保證集群中這個id是唯一的。這個值是可以任意填寫的，並且可以在必要的時候從broker集群中刪除。比較好的做法是使用主機名相關的標識來做為id，比如，你的主機名當中有數字相關的信息，如hosts1.example.com，host2.example.com，那麼這個數字就可以用來作為broker.id的值。

port

默認啟動kafka時，監聽的是TCP的9092端口，端口號可以被任意修改。如果端口號設置為小於1024，那麼kafka需要以root身份啟動。但是並不推薦以root身份啟動。

zookeeper.connect

這個參數指定了Zookeeper所在的地址，它存儲了broker的元信息。在前一章節的例子 中，Zookeeper是運行在本機的2181端口上，因此這個值被設置成localhost:2181。這個值可以通過分號設置多個值，每個值的格式都是hostname:port/path，其中每個部分的含義如下：

• hostname是zookeeper服務器的主機名或者ip地址

• port是服務器監聽連接的端口號

• /path是kafka在zookeeper上的根目錄。如果缺省，會使用根目錄。

如果設置了chroot，但是它又不存在，那麼broker會在啟動的時候直接創建。

PS：為什麼使用Chroot路徑

一個普遍認同的最佳實踐就是kafka集群使用chroot路徑，這樣zookeeper可以與其他應用共享使用，而不會有任何衝突。指定多個zookeeper服務器的地址也是比較好的做法，這樣當zookeeper集群中有節點失敗的時候，還可以正常連接其他的節點。

log.dirs

這個參數用於配置Kafka保存數據的位置，Kafka中所有的消息都會存在這個目錄下。可以通過逗號來指定多個目錄，kafka會根據最少被使用的原則選擇目錄分配新的parition。注意kafka在分配parition的時候選擇的規則不是按照磁盤的空間大小來定的，而是分配的parition的個數多小。

num.recovery.thread.per.data.dir

kafka可以配置一個線程池，線程池的使用場景如下：

• 當正常啟動的時候，開啟每個parition的文檔塊segment

• 當失敗後重啟時，檢查parition的文檔塊

• 當關閉kafka的時候，清除關閉文檔塊

默認，每個目錄只有一個線程。最好是設置多個線程數，這樣在服務器啟動或者關閉的時候，都可以並行的進行操作。尤其是當非正常停機後，重啟時，如果有大量的分區數，那麼啟動broker將會花費大量的時間。注意，這個參數是針對每個目錄的。比如，num.recovery.threads.per.data.dir設置為8，如果有3個log.dirs路徑，那麼一共會有24個線程。

auto.create.topics.enable

在下面場景中，按照默認的配置，如果還沒有創建topic，kafka會在broker上自動創建topic：

• 當producer向一個topic中寫入消息時

• 當cosumer開始從某個topic中讀取數據時

• 當任何的客戶端請求某個topic的信息時

在很多場景下，這都會引發莫名其妙的問題。尤其是沒有什麼辦法判斷某個topic是否存在，因為任何請求都會創建該topic。如果你想嚴格的控制topic的創建，那麼可以設置auto.create.topics.enable為false。

默認的主題配置Topic Defaults

kafka集群在創建topic的時候會設置一些默認的配置，這些參數包括分區的個數、消息的容錯機制，這些信息都可以通過管理員工具以topic為單位進行配置。kafka為我們提供的默認配置，基本也能滿足大多數的應用場景了。

PS：使用per.topic進行參數的覆蓋

在之前的版本中，可以通過log.retention.hours.per.topic，log.retention.bytes.per.topic, log.segment.bytes.per.topic等覆蓋默認的配置。現在的版本不能這麼用了，必須通過管理員工具進行設置。

num.partitions

這個參數用於配置新創建的topic有多少個分區，默認是1個。注意partition的個數只可以被增加，不能被減少。這就意味著如果想要減少主題的分區數，那麼就需要重新創建topic。

在第一章中介紹過，kafka通過分區來對topic進行擴展，因此需要使用分區的個數來做負載均衡，如果新增了broker，那麼就會引發重新負載分配。這並不意味著所有的主題的分區數都需要大於broker的數量，因為kafka是支持多個主題的，其他的主題會使用其餘的broker。需要注意的是，如果消息的吞吐量很高，那麼可以通過設置一個比較大的分區數，來分攤壓力。

log.retention.ms

這個參數用於配置kafka中消息保存的時間，也可以使用log.retention.hours，默認這個參數是168個小時，即一週。另外，還支持log.retention.minutes和log.retention.ms。這三個參數都會控制刪除過期數據的時間，推薦還是使用log.retention.ms。如果多個同時設置，那麼會選擇最小的那個。

PS：過期時間和最後修改時間

過期時間是通過每個log文件的最後修改時間來定的。在正常的集群操作中，這個時間其實就是log段文件關閉的時間，它代表了最後一條消息進入這個文件的時間。然而，如果通過管理員工具，在brokers之間移動了分區，那麼這個時候會被刷新，就不準確了。這就會導致本該過期刪除的文件，被繼續保留了。

log.retention.bytes

這個參數也是用來配置消息過期的，它會應用到每個分區，比如，你有一個主題，有8個分區，並且設置了log.retention.bytes為1G，那麼這個主題總共可以保留8G的數據。注意，所有的過期配置都會應用到patition粒度，而不是主題粒度。這也意味著，如果增加了主題的分區數，那麼主題所能保留的數據也就隨之增加了。

PS：通過大小和時間配置數據過期

如果設置了log.retention.bytes和log.retention.ms（或者其他過期時間的配置），只要滿足一個條件，消息就會被刪除。比如，設置log.retention.ms是86400000(一天)，並且log.retention.bytes是1000000000(1G),那麼只要修改時間大於一天或者數據量大於1G，這部分數據都會被刪除。

log.segment.bytes

這個參數用來控制log段文件的大小，而不是消息的大小。在kafka中，所有的消息都會進入broker，然後以追加的方式追加到分區當前最新的segment段文件中。一旦這個段文件到達了log.segment.bytes設置的大小，比如默認的1G，這個段文件就會被關閉，然後創建一個新的。一旦這個文件被關閉，就可以理解成這個文件已經過期了。這個參數設置的越小，那麼關閉文件創建文件的操作就會越頻繁，這樣也會造成大量的磁盤讀寫的開銷。

通過生產者發送過來的消息的情況可以判斷這個值的大小。比如，主題每天接收100M的消息，並且log.segment.bytes為默認設置，那麼10天后，這個段文件才會被填滿。由於段文件在沒有關閉的時候，是不能刪除的，log.retention.ms又是默認的設置，那麼這個消息將會在17天后，才過期刪除。因為10天后，段文件才關閉。再過7天，這個文件才算真正過期，才能被清除。

PS：根據時間戳追蹤offset

段文件的大小也會影響到消息消費offset的操作，因為讀取某一時間的offset時，kafka會尋找關閉時間晚於offset時間的那個段文件。然後返回offset所在的段文件的第一個消息的offset，然後按照偏移值查詢目標的消息。因此越小的段文件，通過時間戳消費offset的時候就會越精確。

log.segment.ms

這個參數也可以控制段文件關閉的時間，它定義了經過多長時間段文件會被關閉。跟log.retention.bytes和log.retention.ms類似，log.segment.ms和log.segment.bytes也不是互斥的。kafka會在任何一個條件滿足時，關閉段文件。默認情況下，是不會設置Log.segment.ms的，也就意味著只會通過段文件的大小來關閉文件。

PS：基於時間關閉段文件的磁盤性能需求

當時使用基於時間的段文件限制，對磁盤的要求會很高。這是因為，一般情況下如果段文件大小這個條件不滿足，會按照時間限制來關閉文件，此時如果分區數很多，主題很多，將會有大量的段文件同時關閉，同時創建。

message.max.bytes

這個參數用於限制生產者消息的大小，默認是1000000，也就是1M。生產者在發送消息給broker的時候，如果出錯，會嘗試重發；但是如果是因為大小的原因，那生產者是不會重發的。另外，broker上的消息可以進行壓縮，這個參數可以使壓縮後的大小，這樣能多存儲很多消息。

需要注意的是，允許發送更大的消息會對性能有很大影響。更大的消息，就意味著broker在處理網絡連接的時候需要更長的時間，它也會增加磁盤的寫操作壓力，影響IO吞吐量。

PS：配合消息大小的設置

消息大小的參數message.max.bytes一般都和消費者的參數fetch.message.max.bytes搭配使用。如果fetch.message.max.bytes小於message.max.bytes，那麼當消費者遇到很大的消息時，將會無法消費這些消息。同理，在配置cluster時replica.fetch.max.bytes也是一樣的道理。

更多IT資訊，技術交流盡在IT優就業：http://www.ujiuye.com?wt.bd=wt201701

QQ交流群，一鍵加群鏈接：http://www.ujiuye.com/zt/qqhdjlpt/?wt.bd=wt201701

免費在線視頻學習：http://xue.ujiuye.com/?wt.bd=wt201701