【大數據實踐】Kafka生產者編程（5）——ProducerConfig詳解（下）

前言

上一篇文章【大數據實踐】Kafka生產者編程（4）——ProducerConfig詳解（上）中，對kafka producer的相關配置項進行了部分介紹，在本文章中，將繼續完成剩下配置項的介紹。

ProducerConfig類

buffer.memory

重要性：高
類型：Long
默認值：33554432字節，即32M

producer能夠用於緩存等待發送到服務端的消息記錄的緩衝區大小，當消息記錄發送到緩衝區的速度大於傳輸到server的速度，那麼等待發送的消息記錄將會放在緩衝區，緩衝區若是滿了，那麼producer會阻塞max.block.ms指定的毫秒數，超過該毫秒數時，將拋出異常。

注意：該緩衝區的大小設置與整個producer須要使用到的producer大致一致，可是要注意並非全部的緩衝區都是用來存放待發送的records的，好比還有一部分用於壓縮數據（當壓縮數據的選項開啓），還有一部分用於維護in-flight（正在發送）的請求列表。

retry.backoff.ms

重要性：低
類型：Long
默認值：100毫秒

當一個producer到指定的partition的請求request失敗時，在重連以前，須要等待的毫秒數。這是爲了不在某些失敗的場景下，過於密集地重複發送請求。

compression.type

重要性：高
類型：String
默認值："none"

producer對數據使用的壓縮類型，包括：

• none：無壓縮類型
• gzip
• snappy
• lz4

producer在壓縮數據時，是對全部batches的數據一塊兒進行壓縮，而不是一個batch一個batch壓縮，因此，一次壓縮的batches越多，壓縮率越高，壓縮效果越好。

metrics.sample.window.ms

重要性：低
類型：Long
默認值：30000毫秒，即30秒

計算度量樣本的時間窗口，度量用於kafka監控。

metrics.num.samples

重要性：低
類型：int
默認值：2

維護用於計算度量metrics的樣本數量。

metrics.recording.level

重要性：低
類型：String
默認值：info

用於metrics的最高紀錄等級。

metric.reporters

重要性：低
類型：List
默認值：Collections.emptyList()

被做爲metrics reporter的類的列表，這些類都實現了接口org.apache.kafka.common.metrics.MetricsReporter，所以當有新的metric生成時，這些reporters類均可以接收到通知。一般都會包含JmxReporter類，以用於註冊JMX統計。

JMX（Java Management Extensions）

kafka使用jmx調取kafka broker的內部數據，來監控一些敏感的數據。

JMX相關資料：

從零開始玩轉JMX(一)——簡介和Standard MBean
從零開始玩轉JMX(二)——Condition
從零開始玩轉JMX(三)——Model MBean
從零開始玩轉JMX(四)——Apache Commons Modeler & Dynamic MBean

max.in.flight.requests.per.connection

重要性：低
類型：int
默認值：5

在單個鏈接中，producer客戶端在阻塞以前，能夠容許未被確認的最大請求數，即當一個鏈接中未被確認的請求數超過了該設置，那麼該producer客戶端將會阻塞。注意：若是該值設置得比1大，當出現發送失敗的狀況，且retries配置項又開啓時，那麼存在消息被從新排序的風險。

retries

重要性：低
類型：int
默認值：0，表示不重試

當該值被設置成大於0時，客戶端會從新發送消息，而且記錄發送失敗的錯誤。注意，該重試配置項和客戶端因收到錯誤而重發是同樣的。當retries配置項大於0，且max.in.flight.requests.per.connection配置項的值大於1時，存在將重試記錄從新排序的風險，也就是說，消息記錄的順序可能會被打亂。緣由是：當兩個batch被髮送到同一個partition時，若是第一個失敗，而第二個成功，那麼第一個會被重試，此時第二個batch就排在前面了。

key.serializer

重要性：高
類型：Class
默認值：無

消息記錄key的序列化類。

value.serializer

重要性：高
類型：Class
默認值：無

消息記錄中value的序列化類。

connections.max.idle.ms

重要性：中
類型：Long
默認值：540000毫秒，即9分鐘

若是一個鏈接空閒時間超過該配置值，那麼該鏈接將會被關閉。

partitioner.class

重要性：中
類型：Class
默認值：無

計算消息記錄要分配到哪一個partitioner的類。在前面的文章【大數據實踐】Kafka生產者編程（3）——Interceptor & Partitioner中，對partitioner有詳細講解。

interceptor.classes

重要性：低
類型：List
默認值： Collections.emptyList()

攔截鏈，在前面的文章【大數據實踐】Kafka生產者編程（3）——Interceptor & Partitioner有詳細講解。

enable.idempotence

重要性：低
類型：Boolean
默認值：false

是否使用冪等性。若是設置爲true，表示producer將確保每一條消息都剛好有一份備份；若是設置爲false，則表示producer因發送數據到broker失敗重試使，可能往數據流中寫入多分重試的消息。

注意：若是使用idempotence，即enable.idempotence爲true，那麼要求配置項max.in.flight.requests.per.connection的值必須小於或等於5；配置項retries的值必須大於0；acks配置項必須設置爲all。若是這些值沒有被用戶明確地設置，那麼系統將自動選擇合適的值。若是設置的值不合適，那麼會拋出ConfigException異常。

transaction.timeout.ms

重要性：低
類型：Int
默認值：60000毫秒，即60秒

在主動停止（aborting）一個事務transaction以前，事務協調員（transaction coordinator）最多等待的最長時間——爲了讓producer更新事務狀態。若是該值大於kafka broker中設置的transaction.max.timeout.ms配置項的值，那麼producer 的請求將由於InvalidTransactionTimeout錯誤而失敗。

transactional.id

重要性：低
類型：String
默認值：null，表示transactions不能被使用

配置TransactionalId，用於事務的遞交（delivery）。該配置項能夠爲跨多個producer的session提供可靠性語義，由於它能夠保證在開始一個新的事務以前，使用相同事務ID（TransactionalId)的事務必定會完成。

注意：若是配置了transactional.id的值，那麼必須配置enable.idempotence爲true。在發佈環境中，事務要求一個kafka集羣必須有最少3個brokers（推薦設置）。在開發環境中，能夠經過調整broker的配置項transaction.state.log.replication.factor來進行調整，以方便開發。

小結

終於將producer的各個配置項過了一遍，一般咱們須要關注的大概都是重要性爲高的配置項。從上面的配置項中，咱們也瞭解到一些新的概念，好比度量（metrics），事務transactions等。這些概念可能會在接下來的文章中進行講解。