配置說明的最后一部分；

##指定kafka集群的列表，以“,”分割，格式：“host:port,host:port”
##此列表用于producer（consumer）初始化連接使用，server列表可以為kafka集群的子集
##通過此servers列表，client端用于發現cluster的成員全拓撲以及獲取集群的meta信息。
##為了避免某個bootstrap失效而無法初始化client，建議此servers列表中server個數>3
##此servers為kafka brokers，而非zookeeper
bootstrap.servers=
##key、value序列化類，必須實現Serializer接口
##當key、value不是string時，需要指定
##如果指定了相應的Serializer，那么也要求consumer端對應配置相應的Deserializer
#key.serializer=
#value.serializer=
##標識producer，僅用于server端追蹤請求。默認值為""，通常不需要指定
##client.id=
##消息分區的算法類，默認為：
##org.apache.kafka.clients.producer.internals.DefaultPartitioner
##即根據key進行hash分區。
#partitioner.class=
?
##producer發送消息后，在確認請求完成之前需要partition leader收到的ack的數量。
##它用來控制已發送消息的持久性。默認值為：1
##acks=0 ：表示producer不需要等到broker任何ack。消息將會立即添加到socket buffer并認定為此消息已發送。
##這將不能保證broker最終一定能夠接收到消息并可靠的持久化，
##在此情況下，“retries”配置項也將不生效（即使發送是底層傳輸通道遇到error，且錯誤情況也不會對client可見）
##每個消息的反饋信息中offset值總為-1。
##這被認為是一種最高效的傳輸、確認機制，也是數據擔保能力最弱的機制。(當producer端進程退出即可能導致消息丟失)
##acks=1：表示當partition leader收到消息且寫入log文件后，即確認為消息請求已完成（向client端反饋ACK）。
##此時，leader不會等待任何replicas（ISR followers）同步完畢。
##這種情況下，當leader在ACK此消息之后失效，且此時followers尚未同步到此消息時，那么此消息將意味著丟失。
##這被認為是一種最通用的傳輸、確認機制，兼顧數據傳輸效率和數據擔保能力（當partition leader失效時可能導致消息丟失）
##acks=all：當leader接收到消息后，等待所有的ISR followers同步消息，直到所有的ISR都確認收到消息（且寫入log文件）以后，
##leader才會向producer反饋ACK，在此過程中producer將一直等待。（如果消息發送失敗，producer將會重試，直到超時）
##這被認為是一種擔保能力最強、但傳輸效率最低的機制。
##（除非broker磁盤刷新率較低，且只有leader在線，且在fsync期間物理失效，否則幾乎不會丟失數據）
acks=1
?
##單位字節，默認為：32M，建議值為：2097152 （即2M）
##producer端緩存亟待發送消息的內存最大值；
##如果消息發送的速度（調用send方法）比底層IO通道傳輸的速度高，那么在buffer溢出之前，
##producer的發送操作（send）將會阻塞或者拋出異常，直到buffer空閑。（取決于“block.on.buffer.full”）
##此值的設置，取決于producer與broker端的IO通訊效率，接近“網絡IO”的傳輸效率是最佳狀態；
##較大的值，意味著當buffer溢出后客戶端等待的時間更長；較小的值，意味著網絡IO傳輸效能較低。
buffer.memory=33554432
?
?
##當producer發送消息時，遇到底層IO異常時，重試發送的次數；默認為0，表示不重發。
##重發，可能會導致消息亂序的問題。
##（底層連接基于NIO，則允許發送多次請求，以及依次收到響應；而不是阻塞模式的request-response模式）
retries=1
##retry操作的backoff時間，即每次retry之前wait的時間
retry.backoff.ms=100
?
##producer會盡可能的將相同partiton的消息批量發送，以提高發送效率（ACK確認次數減少）
##批量發送，對client和broker都有較大的性能提升。
##此參數用于控制單次批量發送的最大數量量，單位：字節，如果設置為0則表示關閉批量發送。
##發送給broker的請求可以包含多個batches，每個batch對應一個partion（有多條消息組成）
##在發送消息時，總是創建batch.size大小的buffer用于保存消息；所以較大的值將會消耗更高的內存
batch.size=16384
?
##語義有點類似于TCP中的“Nagle”算法（封包傳輸機制）
##當我們開啟batch.size設置時，且buffer中的消息量達到batch.size時，消息將會立即批量發送；
##但是如果buffer中消息量不足batch.size時，則等待“linger.ms”時間后再發送，此期間寄希望獲得更多的消息，以達到批量發送的目的。
##此值默認為0，表示“不等待”（no delay）。
linger.ms=0
?
##當buffer溢出時、metadata不可用（即因為broker端leader選舉等，無法獲取最新的metadata），
##將會導致producer的send方法阻塞，此值用于控制阻塞的最長時間。
##用戶自定的serializers處理耗時、partitioner計算耗時，則不包含在內。
max.block.ms=60000
?
##單次請求所允許的最大數據量：用于限制每個請求所能包含的batches個數、消息的個數。
##當然也可以用來限制每個消息的最大尺寸，以避免發送“huge”的請求。
max.request.size=1048576
?
##用于控制client等待響應的最大時間
##當超時后，請求將會被重試；如果重試次數已達到閥值，則認為請求失敗。
request.timeout.ms=30000
?
##用于限定broker端leader等待followers反饋ACK以滿足“acks”配額要求的最大等待時間。
##此值不包含producer到broker的網絡傳輸耗時。
##當leader在限定時間內無法獲取滿足配額要求的acks時，將會返回error。（但已經執行的數據并不撤銷）
timeout.ms=30000
?
##在客戶端單個連接上允許“尚未ACK”的請求的最大個數，
##當此連接上“已發送”、“尚未確認”的請求個數達到此值時，client將會阻塞（max.block.ms）。
max.in.flight.requests.per.connection=5
?
##客戶端在發送實際消息之前，比如獲取broker端的meta信息：包括指定topic的parttions列表以及所位于的broker地址
##此值用于控制獲取metadata的超時時間
metadata.fetch.timeout.ms=60000
?
##因為broker集群的變遷，metadata會不斷變化，比如leader的遷移等。
##此值用于控制client端強制刷新（重新獲取）metadata的時間間隔。
##當client發送消息遇到異常時（比如partition leader不可用）也會嘗試立即刷新metadata。
metadata.max.age.ms=300000
?
##底層IO連接空閑的最大時間，單位：毫秒
##connections.max.idle.ms=540000
##底層IO連接通道，在重建連接時的backoff時間（即間歇等待的時間），以避免頻繁重建連接且失敗的情況。
reconnect.backoff.ms=50
?
##是否啟用壓縮機制，建議關閉
compression.type=none

??----------------------------------------------------------------------------------------------

深耕運維行業多年，擅長linux、容器云原生、運維自動化等方面。
承接各類運維環境部署、方案設計/實施、服務代運維工作，歡迎溝通交流！

（V： xiaoxiangbj2013 ） ！