下面將以Kafka集群設計的各方面參數進行說明：
broker端口參數
topic級別參數
GC配置參數
JVM參數
OS參數

broker端參數
Kafka目前尚不支持動態參數修改，也就是說，如果修改了參數，需要重新啟動對應broker服務器。

• broker.id：kafka使用唯一的一個整數來標識broker。該參數默認值是-1，如果不指定，kafka會自動生成一個唯一值。
• log.dirs：非常重要的參數，kafka持久化消息的目錄，該參數可以設置多個目錄，用逗號分隔，這樣kafka會將負載均勻地分配到多個目錄下。如果每個目錄都在不同的磁盤上，那么還能提升整體寫消息的吞吐量。默認情況下是/tmp/kafka-logs。
• zookeeper.connect：此參數沒有默認值，必須指定，該參數可以是一個csv列表，如果使用一套zookeeper管理多個kafka集群，則zookeeper的chroot必須指定。
• listeners：broker監聽的csv列表，格式是[協議]://[主機名]:[端口],[協議]://[主機名]:[端口]。該參數用于客戶端連接broker使用。如果不指定，默認綁定網卡；如果主機名是0.0.0.0，則表示綁定所有網卡。Kafka當前支持的協議類型包括：PLAINTEXT、SSL以及SASL_SSL等。
• advertised.listeners：和listeners類似，該參數也是用于發布給client的監聽器，不過該參數主要用于IaaS環境，比如云上的機器通常都配有多塊網卡（私網網卡和公網網卡）。對于這種機器，用戶可以設置該參數綁定公網IP供外部client使用，然后配置上面的listeners來綁定私網IP供broker之間通訊。當然不配置也是可以的，但是云上的機器一般綁定的都是私網網卡，可能會出現客戶端無法訪問數據問題。
• unclean.leader.election.enable：是否開啟unclean leader選舉。何為unclean leader選舉？ISR中所有副本都有資格隨時成為新的leader，但若ISR變空而此時leader又宕機了，kafka會如何選舉新的leader呢？為了不影響kafka的服務，該參數默認為false，即表明如果發生這種情況，Kafka不允許從剩下存活的非ISR中選舉一個leader。因為如果允許，這樣做必然可以讓Kafka繼續提供服務，但會造成數據丟失，因此該參數默認值為false。
• delete.topic.enable：是否允許kafka刪除topic。默認情況下，Kafka集群允許用戶刪除topic及其數據。
• log.retention.{hours|minutes|ms}：這組參數控制了消息數據的存留時間。如果同時設置，優先選取ms的設置，minutes次之，hours最后。Kafka會根據日志文件的最后修改時間（last modified time）進行判斷。
• log.retention.bytes：上面的參數是時間維度，這個參數就是空間維度。它控制著Kafka集群需要為每個消息日志保存多大的數據。對于超過該參數的分區日志而言，Kafka會自動清理該分區的過期日志段文件。該參數默認值為-1，表示kafka永遠不會根據消息日志文件總大小來刪除日志。
• min.insync.replicas：該參數實際是和product的acks參數配合使用的。它指定了broker端必須成功響應client消息發送的最小副本數。如果broker段無法滿足，則client的消息并不會被認為是成功的。它與product的acks配置使用可以令kafka集群達到最高等級的消息持久化。
• num.network.threads：控制broker在后臺處理來自網絡請求的線程數，默認是3。該參數只是轉發請求（轉發給其他線程處理），并不會對其進行處理。在生產環節中，應該實時監控NetworkProcessorAvgIdlePercent JMX指標，如果該指標持續低于0.3，則應該增加該參數的值。
• num.io.threads：該參數控制broker實際處理網絡請求的線程數，默認是8。即Kafka創建8個線程，采用輪詢的方式監聽轉發過來的網絡請求并進行實時處理。如果RequestHandlerAvgIdlePercent指標持續低于0.3，則應該增加該參數的值。
• message.max.bytes：Kafka broker能夠接受的最大消息數，默認值是977KB。

topic級別參數
Topic級別參數是指覆蓋broker端全局參數。每個不同的topic都可以設置自己的參數值。通常topic級別參數可以在創建topic時，使用—config key=value進行配置，多個參數用逗號進行分隔

• delete.retention.ms：每個topic可以配置自己的日志留存時間以覆蓋全局默認值。
• max.message.bytes：覆蓋全局的message.max.bytes，即為每個topic指定不同的最大消息大小。
• retention.bytes：覆蓋全局的log.retention.bytes，每個topic設置不同的日志留存大小。
• retention.ms：日志文件保存的分鐘數。數據存儲的最大時間超過這個時間會根據cleanup.policy策略處理數據。
• cleanup.policy：過期或達到日志上限的清理策略（delete：刪除；compact：壓縮）默認值為delete。
• compression.type：指定給該topic的壓縮類型（uncompressed、snappy、lz4、gzip、producer），默認值為producer。
• file.delete.delay.ms：從文件系統中刪除前的等待時間（默認60000）。
• flush.message：在消息刷盤前，日志分區收集的消息數（默認值為MAX_VALUE）。
• flush.ms：消息在刷盤前，保存在內存中的最長時間，單位ms（默認值MAX_VALUE）。
• index.interval.bytes：當執行fetch操作后，需要一定的空間來掃描最近的offset大小。設置越大，掃描速度更快，但更耗內存，一般不用設置此參數（默認為4096）。
• min.cleanable.dirty.ratio：日志清理的頻率控制，越大清理越高效（默認值為0.5）。
• segment.bytes：topic文件是以segment文件進行存儲的，該參數控制segment文件的大小，默認值為1073741824（10G）。
• segment.index.bytes：對于segment索引文件的大小限制，默認為10M。

OS參數

• 文件描述符限制：Kafka會頻繁地創建并修改文件系統中的文件，這包括消息的日志文件、索引文件及各種元數據管理文件等。因此如果一個broker上面有很多topic的分區，那么這個broker勢必會打開很多個文件—大致約等于分區數 * （分區總大小/日志段大小） * 3。打開方式：ulimit -n 100000
• Socket緩存區大小：這里指的是OS級別的Socket緩沖區大小，而非Kafka自己提供的Socket緩存區參數。事實上，Kafka自己的參數將其設置為64KB，對于普通的內網環境是足夠的。如果是做遠距離的數據傳輸，那么建議將OS級別的Socket緩沖區調大，比如增加到128KB，甚至更大。
• 最好使用Ext4活XFS文件系統：其實Kafka操作的都是普通文件，并沒有依賴于特定的文件系統，但依然推薦Ext4活XFS文件系統，特別是XFS通常有更好的性能。
• 關閉swap：其實這是很多使用磁盤的應用程序的常規調優手段，具體命令為sysctl vm.swappiness = <一個較小的數>，即大幅度降低對swap空間的使用，以免極大地拉低性能。
• 設置更長的flush時間：Kafka依賴OS頁緩存的“刷盤”功能實現真正寫入無力磁盤，默認的刷盤間隔是5s。通常情況下，這個間隔時間太短了，適當增加該值可以在很大程度上提升OS物理寫入的性能。LinkedIn公司就將該值設置為2min以增加整體的物理寫入吞吐量。