kafka集羣參數配置

kafka集羣參數配置包括 Broker端參數、Topic級別的參數、JVM端參數 以及 操作系統級別的參數配置；
該篇用於介紹常用且不能使用默認值的一些參數配置，因爲有些配置的重要性並未在官方文檔中表現出來；從實際表現看，很多參數對系統的影響要比從文檔上看更加重要。

1.Broker 端參數

a.針對儲存信息的參數

• log.dirs: 指定了 Broker 需要使用的若干個文件目錄路徑; 該參數沒有默認值，必修由用戶親自指定；
• log.dir: 指定了Broker需要使用的單個文件目錄路徑；用於補充log.dirs參數用的；

以上兩個參數，通常只需要配置 `log.dirs`即可；配置多個路徑時使用逗號“,”分割；
如果有條件的話你最好保證這些目錄掛載到不同的物理磁盤上，主要好處有：
	1. 提升讀寫性能：比起單塊磁盤，多塊物理磁盤同時讀寫數據有更高的吞吐量。
	2. 能夠實現故障轉移：即 Failover。這是 Kafka 1.1 版本新引入的強大功能。
	   之前，只要 Kafka Broker 使用的任何一塊磁盤掛掉，整個 Broker 進程都會關閉。
	   但是自 1.1 開始，這種情況被修正：壞掉的磁盤上的數據會自動地轉移到其他正常的磁盤上，而且 Broker 還能正常工作。
	   這個改進正是我們捨棄 RAID 方案的基礎：沒有這種 Failover 的話，我們只能依靠 RAID 來提供保障。

b.kafka 與 zooKeeper相關的參數

ZooKeeper是一個分佈式協調框架，負責協調管理並保存 Kafka 集羣的所有元數據信息，比如集羣都有哪些 Broker 在運行、創建了哪些 Topic，每個 Topic 都有多少分區以及這些分區的 Leader 副本都在哪些機器上等信息。

• zookeeper.connect: Kafka使用的ZooKeeper集羣地址集合；可指定多個，之間用逗號分割。eg: zk1:2181,zk2:2181,zk3:2181

如果你有兩套 Kafka 集羣，假設分別叫它們 kafka1 和 kafka2，那麼兩套集羣的 `zookeeper.connect`參數可以這樣指定：
	zk1:2181,zk2:2181,zk3:2181/kafka1
	zk1:2181,zk2:2181,zk3:2181/kafka2
切記 chroot 只需要寫一次，而且是加到最後的。錯誤指定方式：
	zk1:2181/kafka1,zk2:2181/kafka2,zk3:2181/kafka3

c.針對Broker連接的參數

客戶端程序或其他 Broker 如何與該 Broker 進行通信的設置。有以下三個參數：

• listeners: 監聽器，用於告訴外部連接者要通過什麼協議訪問指定主機名和端口開放的 Kafka 服務。
• advertised.listeners：和 listeners 相比多了個 advertised。Advertised 的含義表示宣稱的、公佈的，就是說這組監聽器是 Broker 用於對外發布的。
• host.name/port：這兩個參數是過期參數，不需要指定值。

監聽器的概念: 從構成上來說，它是若干個逗號分隔的三元組，每個三元組的格式爲:
	<協議名稱，主機名，端口號>
這裏的協議名稱可能是標準的名字，比如 PLAINTEXT 表示明文傳輸、SSL 表示使用 SSL 或 TLS 加密傳輸等；也可能是你自己定義的協議名字，比如:
	CONTROLLER: //localhost:9092
一旦你自己定義了協議名稱，你必須還要指定 `listener.security.protocol.map` 參數告訴這個協議底層使用了哪種安全協議，比如指定:
	listener.security.protocol.map=CONTROLLER:PLAINTEXT
表示這個自定義協議底層使用明文不加密傳輸數據。
三元組種的主機名 --> 在IP地址和主機名之間，建議使用主機名，即 Broker 端和 Client 端應用配置中全部填寫主機名。 Broker 源代碼中也使用的是主機名，如果你在某些地方使用了 IP 地址進行連接，可能會發生無法連接的問題。

d.針對Topic管理的參數

• auto.create.topics.enable：是否允許自動創建 Topic。

該參數建議最好設置成 false，即不允許自動創建 Topic。
在線上環境裏面有很多名字稀奇古怪的 Topic，大概都是因爲該參數被設置成了 true 的緣故。
Topic 應該由運維嚴格把控，決不能允許自行創建任何 Topic。

• unclean.leader.election.enable：是否允許 Unclean Leader 選舉。

kafka中自由Leader副本對外提供服務；
該參數的運用場景主要是：
	那些保存數據比較多的副本均掛死的情況下，是否還要在落後進度較多的副本中競選出Leader
	false: 落後太多的副本不允許競爭Leader; 以上場景會使得當前分區不可用；
	true：允許競爭，這樣會導致部分數據丟失；
該參數在最新版本中默認爲false, 通常不需要修改；但在之前版本中默認值經過了多次修改；
所以最好顯示設置爲true或者false；

• auto.leader.rebalance.enable：是否允許定期進行 Leader 選舉。

true：表示允許 Kafka 定期地對一些 Topic 分區進行 Leader 重選舉;
它需要滿足一定的條件纔會發生。
嚴格來說它與上一個參數中 Leader 選舉的最大不同在於，它不是選 Leader，而是換 Leader！
比如 Leader A 一直表現得很好，但若 `auto.leader.rebalance.enable=true`，
那麼有可能一段時間後 Leader A 就要被強行卸任換成 Leader B。

e.針對數據留存的參數

• log.retention.{hour|minutes|ms}：三個參數用來控制一條消息數據被保存多長時間。從優先級上來說 ms 設置最高、minutes 次之、hour 最低。

雖然 ms 設置有最高的優先級，但是通常情況下我們還是設置 hour 級別的多一些

• log.retention.bytes ：這是指定 Broker 爲消息保存的總磁盤容量大小。

默認值爲-1, 表示不限容量
這個參數真正發揮作用的場景其實是在雲上構建多租戶的 Kafka 集羣：
	設想你要做一個雲上的 Kafka 服務，每個租戶只能使用 100GB 的磁盤空間，
	爲了避免有個“惡意”租戶使用過多的磁盤空間，設置這個參數就顯得至關重要；

• message.max.bytes：控制 Broker 能夠接收的最大消息大小。

默認值爲 1000012，不到 1MB。實際場景中突破 1MB 的消息是常見的；
因此在線上環境中設置一個比較大的值還是比較保險的做法。
畢竟它只是一個標尺而已，僅僅衡量 Broker 能夠處理的最大消息大小，
即使設置大一點也不會耗費什麼磁盤空間的。

2.Topic級別的參數

Topic級別參數優先級高於全局Broker參數； 每個Topic都能設置自己的參數值；

a.針對消息存儲的參數

• retention.ms：該Topic消息被保存的時長； 默認值爲7天； 一旦設置，會覆蓋Broker端的全局參數值。
• retention.bytes：該Topic預留的磁盤空間大小；默認值爲-1（不設限）；運用於多租戶場景。
• max.message.bytes： 決定Kefka Broker能夠正常接收該Topic的最大消息大小；

設置Topic級別參數的方法：
	1. 創建 Topic 時進行設置
		bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic transaction --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880
	2. 修改 Topic 時設置（推薦）
		bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760

3.JVM參數

Kafka不建議運行在 Java6 或 7的環境上；Java6 太舊；Kafka在2.0.0版本開始摒棄了對 Java7 的支持。
Kafka設置JVM參數的方法，設置環境變量：

• KAFKA_HEAP_OPTS：指定堆大小。
• KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 參數。

$> export KAFKA_HEAP_OPTS=--Xms6g  --Xmx6g
$> export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true
$> bin/kafka-server-start.sh config/server.properties

a.堆大小設置

據稱，將JVM堆大小設置爲 6GB。 這是一個業界比較公認的合理值；原因：Kafka Broker在與客戶端進行交互式會在JVM堆上創建大量的 ByteBuffer 實例，Heap Size不能太小；

b.垃圾回收（GC）設置

如果使用的 Java7，需要根據如下條件進行配置：

1. 如果 Broker 所在機器的 CPU 資源非常充裕，建議使用 CMS 收集器。啓動方法，指定：
	-XX:+UseCurrentMarkSweepGC
2. 否則使用吞吐量收集器。開啓方法是指定：
	-XX:+UseParallelGC

如果使用的 Java8， 可以指定爲G1收集器； G1收集器在沒有任何調優的情況下，比CMS更出色，主要體現在更少的 Full GC，需要調整的參數更少等；
如果使用的 Java9， 那麼不需要設置，其默認爲G1收集器；

4.操作系統參數

Kafka需要關注的OS參數：

• 文件描述符限制: ulimit -n

文件描述符系統資源並沒有想象的昂貴，通常將它設置成一個超大的值時合理的做法：
	ulimit -n 1000000
如果不設置的話，可能會看到 “Too many open files” 錯誤；

• 文件系統類型：指如 ext3、ext4或XFS這樣的日誌型文件系統； 性能：ZFS(嚐鮮) > XFS > ext4
• Swappiness：swap調優， swap建議設置爲一個較小的值；這樣能在Broker性能急劇下降時，有時間進一步調優和診斷；建議設置爲1；

小知識：當swap=0時，如果物理內存耗盡，那麼操作系統會觸發 OMM killer組件，隨機挑選一個進程kill掉，而用戶在此期間無法感知；

• 提交時間：Flush落盤時間；Kafka數據被寫入到操作系統的頁緩存（Page Cache）上就被認爲寫入成功，隨後操作系統根據 LRU 算法會定期（默認5秒）將頁緩存上的“髒”數據落盤到物理磁盤上；可以適當增加提交時間間隔；由於Kafka在軟件層面已經提供了多副本的冗餘機制，不用擔心出現數據丟失的情況；