以下都是最好顯示設置的參數：
1.log.dirs = /home/kafka1,/home/kafka2,/home/kafka3 指定了 Broker 需要使用的若干個文件目錄路徑。（還有一個log.dir參數用於補充log.dirs的單個路徑配置，但基本不用，配置log.dirs即可）
多路徑時，最好保證這些目錄掛載到不同的物理磁盤上，好處：
- 提升讀寫性能：比起單塊磁盤，多塊物理磁盤同時讀寫數據有更高的吞吐量。
- 能夠實現故障轉移：即 Failover。（Kafka 1.1 版本新引入的強大功能，以前，只要 Kafka Broker 使用的任何一塊磁盤掛掉了，整個 Broker 進程都會關閉。但是自 1.1 開始，這種情況被修正了，壞掉的磁盤上的數據會自動地轉移到其他正常的磁盤上，而且 Broker 還能正常工作。這個改進正是舍棄 RAID 方案的基礎：沒有這種 Failover 的話，我們只能依靠 RAID 來提供保障。）
Zookeeper相關參數：
2.zookeeper.connect = zk1:2181,zk2:2181,zk3:2181/kafka1 需在/etc/hosts 里面配置zk1,zk2,zk3，/kafka1是chroot，指定zk創建在這路徑下，否則就在zk根目錄創建（多個kafka注冊到同一個zk集群時，最好帶上chroot用以區分）
下面兩個與brokers相關的參數
3.listeners 告訴外部連接者要通過什么協議訪問指定主機名和端口開放的 Kafka 服務
4.advertised.listeners 配置的這組監聽器是 Broker 用於對外發布的
監聽器是三元組，<協議名稱，主機名，端口號>，協議名稱可能是標准的名字，比如 PLAINTEXT 表示明文傳輸、SSL 表示使用 SSL 或 TLS 加密傳輸等；也可能是你自己定義的協議名字，比如CONTROLLER: //localhost:9092。
定義了協議名稱，你必須還要指定listener.security.protocol.map參數告訴這個協議底層使用了哪種安全協議，比如指定listener.security.protocol.map=CONTROLLER:PLAINTEXT表示CONTROLLER這個自定義協議底層使用明文不加密傳輸數據。
三元組中最好全部使用主機名，即 Broker 端和 Client 端應用配置中全部填寫主機名。 Broker 源代碼中也使用的是主機名，如果你在某些地方使用了 IP 地址進行連接，可能會發生無法連接的問題。
Topic管理的參數：
5.auto.create.topics.enable = false 是否允許自動創建 Topic，建議是false，避免出現寫錯了topic名字自動創建了奇怪的topic。
6.unclean.leader.election.enable = false 是否允許 Unclean Leader 選舉，默認false，多副本中只有一個leader副本提供服務，有一種情況：假設那些保存數據比較多的副本都掛了怎么辦？我們還要不要進行 Leader 選舉了？設置成 false，那么就堅持之前的原則，堅決不能讓那些落后太多的副本競選 Leader。這樣做的后果是這個分區就不可用了，因為沒有 Leader 了。反之如果是 true，那么 Kafka 允許你從那些“跑得慢”的副本中選一個出來當 Leader。這樣做的后果是數據有可能就丟失了。
7.auto.leader.rebalance.enable = false 是否允許定期進行 Leader 選舉，建議false，因為更換leader的成本是很高的，原本向 A 發送請求的所有客戶端都要切換成向 B 發送請求，而且這種換 Leader 本質上沒有任何性能收益。
數據相關（Brokers級別）
8.log.retention.{hour|minutes|ms} 控制一條消息數據被保存多長時間。從優先級上來說 ms 設置最高、minutes 次之、hour 最低。一般設置log.retention.hour=168表示默認保存 7 天的數據，自動刪除 7 天前的數據。如果想把kafka當存儲用，那就要設置大。
9.log.retention.bytes 指定 Broker 為消息保存的總磁盤容量大小，默認-1，即保存多少數據都可以，真正發揮作用是在雲上構建多租戶的 Kafka 集群的場景，每個租戶只能使用 100GB 的磁盤空間，為了避免有個“惡意”租戶使用過多的磁盤空間。
10.message.max.bytes 控制 Broker 能夠接收的最大消息大小，默認的 1000012 太少了，還不到 1MB，建議設置大一些。
Topic級別參數（brokers是全局的參數），可在在創建topic的時候kafka-topics命令用--config后帶上該參數設置，也可以用kafka-configs腳本來調整：
11.retention.ms 規定了該 Topic 消息被保存的時長。默認是 7 天，即該 Topic 只保存最近 7 天的消息。一旦設置了這個值，它會覆蓋掉 Broker 端的全局參數值。
12.retention.bytes 規定了要為該 Topic 預留多大的磁盤空間。和全局參數作用相似，這個值通常在多租戶的 Kafka 集群中會有用武之地。當前默認值是 -1，表示可以無限使用磁盤空間。
13.max.message.bytes 它決定了 Kafka Broker 能夠正常接收該 Topic 的最大消息大小。
14.運行kafka 的JVM參數設置：
比較通用的設置：將 JVM 堆大小設置成 6GB ，業界相對公認的合理數值。
垃圾收集使用：
- 如果 Broker 所在機器的 CPU 資源非常充裕，建議使用 CMS 收集器。啟用方法是指定
-XX:+UseCurrentMarkSweepGC。 - 否則，使用吞吐量收集器。開啟方法是指定
-XX:+UseParallelGC
如果是java 8以上直接用G1.
如何設置？啟動broker前：
export KAFKA_HEAP_OPTS=--Xms6g --Xmx6gexport KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=truebin/kafka-server-start.sh config/server.properties
15.運行kafka的操作系統參數設置
主要有這幾個方面：
- 文件描述符限制
- 文件系統類型
- Swappiness
- 提交時間
文件描述符真的不昂貴，可以設置ulimit -n 1000000
文件系統XFS 的性能要強於 ext4，ZFS 顯示更好，但沒有實際測試過
swap 的調優，設置0可以禁掉以防止 Kafka 進程使用 swap 空間，一旦設置成 0，當物理內存耗盡時，操作系統會觸發 OOM killer 這個組件，它會隨機挑選一個進程然后 kill 掉，即根本不給用戶任何的預警。
所以設置一個較小值，如1，當開始使用 swap 空間時，至少能夠觀測到 Broker 性能開始出現急劇下降，從而給你進一步調優和診斷問題的時間。
提交時間，也是Flush 落盤時間，向 Kafka 發送數據並不是真要等數據被寫入磁盤才會認為成功，而是只要數據被寫入到操作系統的頁緩存（Page Cache）上就可以了，隨后操作系統根據 LRU 算法會定期將頁緩存上的“臟”數據落盤到物理磁盤上。
這個定期就是由提交時間來確定的，默認是 5 秒，可以適當調整大，來降低物理磁盤的寫操作， Kafka 在軟件層面已經提供了多副本的冗余機制，稍微拉大提交間隔去換取性能還是一個合理的做法。