生產者
生產者有大量的配置參數;大多數都在ApacheKafka文檔中有記錄，許多都有合理的默認值，所以沒有理由去修改每一個參數。但是，一些參數對生產者的記憶使用，性能和可靠性有重大影響。我們會在這裏回顧一下。
acks
該ACK的參數控制許多分區副本必須如何接收記錄之前，生產者可以考慮寫成功。這個選項對郵件丟失的可能性有很大的影響。acks 參數有三個允許的值：
If acks = 0 ，
生產者在假設消息發送成功之前不會等待代理的回覆。這意味着如果出了問題，
經紀人沒有收到消息，生產者不知道，消息將會丟失。但是，由於生產者不等待服務器的任何響應，所以它可以以網絡支持的速度發送消息，所以這個設置可以用來實現非常高的吞吐量。
If ack = 1 ，生產者將接收來自代理中的領導者副本接收到的消息的時刻的成功響應。如果消息不能寫入領導（例如，如果領導崩潰，並且還沒有選出新領導），則生產者將收到錯誤響應並且可以重試發送消息，避免潛在的數據丟失。如果領導人崩潰，並且沒有這個消息的副本被選爲新領導者（通過不潔的領導者選舉），消息仍然可能會丟失。在這種情況下，吞吐量取決於我們是同步還是異步發送消息。如果我們的客戶端代碼等待來自服務器的回覆（通過調用發送消息時返回的Future 對象的get（）方法），顯然會顯着增加延遲（至少通過網絡往返）。如果客戶端使用回調，則潛伏時間將被隱藏，但是吞吐量將受到正在進行的消息數量的限制（即在從服務器接收回復之前生產者將發送多少消息）。
If acks = all ，則一旦所有同步副本收到消息，生產者都將收到來自代理的成功響應。這是最安全的模式，因爲您可以確保多個經紀人都有消息，即使發生崩潰，消息也能存活（有關第5章的更多信息）。然而，我們在acks = 1 案例中討論的延遲會更高，因爲我們將等待不止一個經紀人接收信息。
buffer.memory
這將設置生產者將用於緩衝等待發送給代理的消息的內存量。如果應用程序發送的消息比發送給服務器的消息快，那麼生產者可能會用盡空間，並且額外的send（）調用將根據block.on.buffer.full 參數阻塞或拋出異常（替換爲0.9.0.0版本中的 max.block.ms ，允許阻塞一段時間，然後拋出一個異常）。
compression.type
默認情況下，消息是未壓縮發送的。該參數可以被設置爲活潑的，gzip的，或LZ4 ，在這種情況下相應的壓縮算法將被用來將它發送到代理之前對數據進行壓縮。敏捷的壓縮技術是Google發明的，它可以提供良好的壓縮比，CPU佔用率低，性能好，所以建議在兼顧性能和帶寬的情況下。Gzip壓縮通常會使用更多的CPU和時間，但會產生更好的壓縮比，所以建議在網絡帶寬更受限制的情況下使用。通過啓用壓縮功能，可以減少網絡利用率和存儲量，這往往是向Kafka發送消息時的瓶頸。
retries
當生產者從服務器收到錯誤消息時，錯誤可能是暫時的（例如，缺少分區的領導）。在這種情況下，retries 參數的值將控制生產者在放棄並通知客戶端問題之前將重試發送消息的次數。默認情況下，生產者將在重試之間等待100ms，但是您可以使用retry.backoff.ms 參數來控制此操作。我們建議測試從崩潰的代理恢復需要多長時間（即，直到所有分區獲得新的領導者的時間），並設置它們之間的重試次數和延遲時間，以使重試的總時間長於時間需要Kafka集羣從崩潰中恢復，否則生產者會放棄過早。不是所有的錯誤都會被生產者重新嘗試。有些錯誤不是暫時的，不會導致重試（例如，“消息太大”的錯誤）。一般來說，因爲生產者爲你處理重試，在你自己的應用程序邏輯中處理重試沒有意義。您將需要集中精力處理不可恢復的錯誤或重試嘗試耗盡的情況。
batch.size
當多個記錄發送到同一個分區時，生產者將把它們批處理在一起。此參數控制將用於每個批次的內存字節數（不是消息！）。批次滿時，批量中的所有消息都將被髮送。但是，這並不意味着生產者會等待批次變滿。製片人將發送半滿批次，甚至批量，只有一條消息。因此，批量設置過大不會導致郵件發送延遲; 它只會使用更多的內存批量。設置批量太小會增加一些開銷，因爲生產者需要更頻繁地發送消息。
linger.ms
linger.ms 控制發送當前批次之前等待附加消息的時間。KafkaProducer 在當前批次已滿或達到 linger.ms 限制時發送一批消息。默認情況下，即使批處理中只有一條消息，生產者也會在發送者線程可用時立即發送消息。通過將linger.ms設置爲高於0，我們指示生產者等待幾毫秒，然後將其添加到批處理中，然後再發送給代理。這增加了延遲，但也增加了吞吐量（因爲我們一次發送更多消息，每條消息的開銷更少）。
client.id
這可以是任何字符串，並且由經紀人用來識別從客戶端發送的消息。它用於日誌記錄和指標以及配額。
max.in.flight.requests.per.connection
這將控制生產者在沒有收到響應的情況下將發送到服務器的消息數量。將此設置爲最高會增加內存使用量，同時提高吞吐量，但將其設置得過高可能會降低吞吐量，因爲批量降低效率。將其設置爲1將保證消息將按照發送順序寫入代理，即使發生重試也是如此。
timeout.ms，request.timeout.ms和metadata.fetch.timeout.ms
這些參數控制生產者在發送數據（request.timeout.ms ）和請求元數據（如正在寫入的分區的當前領導）（metadata.fetch.timeout.ms ）時等待服務器答覆的時間。。如果達到超時沒有回覆，生產者將重試發送或響應錯誤（通過異常或發送回調）。timeout.ms 控制代理等待同步副本確認消息以滿足確認配置的時間 - 如果沒有必要的確認，代理將返回錯誤。
max.block.ms
此參數控制調用send（）時以及通過partitionsFor（）顯式請求元數據時生產者將阻塞的時間。這些方法在生產者的發送緩衝區已滿或元數據不可用時阻塞。當達到 max.block.ms 時，會引發超時異常。
max.request.size
此設置控制生產者發送的產品請求的大小。它既限制了可發送的最大消息的大小，也限制了生產者可以在一個請求中發送的消息的數量。例如，默認的最大請求大小爲1 MB，則可以發送的最大消息爲1 MB，或者生產者可以將1,000個大小爲1 K的消息分批發送到一個請求中。另外，代理對它將接受的最大消息的大小有限制（message.max.bytes ）。使這些配置匹配通常是一個好主意，所以生產者不會嘗試發送將被代理拒絕的大小的消息。
receive.buffer.bytes and send.buffer.byteu
這些是在寫入和讀取數據時由套接字使用的TCP發送和接收緩衝區的大小。如果這些設置爲-1，則將使用OS默認值。當生產者或消費者與不同的數據中心中的經紀人進行通信時，增加這些數據是個好主意，因爲這些網絡鏈路通常具有更高的延遲和更低的帶寬。
消費者
ApacheKafka文檔中記錄了所有用戶配置。大多數參數都有合理的默認值，不需要修改，但有些參數會影響消費者的性能和可用性。
fetch.min.bytes
此屬性允許用戶指定在獲取記錄時從代理接收的最小數據量。如果代理收到來自消費者的記錄請求，但新記錄的字節數少於min.fetch.bytes ，則代理將等待更多消息可用，然後再將記錄發回消費者。這減少了消費者和經紀人的負擔，因爲在話題沒有太多新活動（或者對於一天中的較低活動時間）的情況下，他們必須處理較少的來回消息。如果消費者在沒有太多數據可用的情況下使用太多的CPU，則需要將此參數設置爲高於默認值，或者在擁有大量消費者時減少代理的負載。
fetch.max.wait.ms
通過設置fetch.min.bytes ，您可以告訴Kafka等到有足夠的數據發送給用戶之後再發送。fetch.max.wait.ms 讓你控制等待多久。默認情況下，Kafka將等待500毫秒。如果沒有足夠的數據流向Kafka主題以滿足返回的最小數據量，則會導致高達500 ms的額外延遲。如果您想限制潛在的延遲（通常是由於SLA控制應用程序的最大延遲），則可以將fetch.max.wait.ms 設置爲較低的值。如果將fetch.max.wait.ms設置爲100
ms，並將fetch.min.bytes設置爲1 MB，則Kafka將接收來自使用者的提取請求，並在數據有1 MB數據返回時或100毫秒，以先發生者爲準。
max.partition.fetch.bytes
此屬性控制服務器每個分區返回的最大字節數。默認值是1 MB，這意味着當KafkaConsumer.poll（）返回ConsumerRecords時，記錄對象將最多使用分配給使用者的每個分區的 max.partition.fetch.bytes 。因此，如果一個主題有20個分區，並且有5個消費者，則每個消費者需要有4 MB的內存用於消費者記錄。實際上，如果組中的其他使用者發生故障，您將需要分配更多的內存，因爲每個使用者需要處理更多的分區。最大。partition.fetch.bytes
必須大於代理將接受的最大消息（由代理配置中的max.message.size 屬性確定），或者代理可能具有消費者將無法使用的消息，在這種情況下消費者會試圖閱讀它們。設置max.partition.fetch.bytes的另一個重要考慮因素是消費者處理數據所花費的時間。您記得，消費者必須經常調用poll（）以避免會話超時和隨後的重新平衡。如果單個poll（）返回的數據量非常大，則消費者可能需要更長的時間來處理，這意味着它不會及時到達輪詢循環的下一個迭代以避免會話超時。如果發生這種情況，兩個選項要麼降低最大值。partition.fetch.bytes
或增加會話超時。
session.timeout.ms
消費者在仍被認爲活着的情況下可以脫離與經紀人聯繫的時間量默認爲3秒。如果超過session.timeout.ms 而沒有消費者向組協調器發送心跳信號，則認爲它已經死亡，組協調器將觸發消費者組的重新平衡，以便將死亡消費者的分區分配給組中的其他消費者。此屬性與heartbeat.interval.ms密切相關。heartbeat.interval.ms 控制KafkaConsumer poll（）方法向組協調器發送心跳的頻率，而session.timeout.ms
控制消費者在不發送心跳的情況下可以走多久。因此，這兩個屬性通常一起修改 - heatbeat.interval.ms 必須低於session.timeout.ms ，通常設置爲超時值的三分之一。所以如果session.timeout.ms 是3秒鐘，heartbeat.interval.ms 應該是1秒。將session.timeout.ms設置爲低於默認值將允許用戶組更快地檢測並從故障中恢復，但是由於用戶花費更長時間來完成輪詢循環或垃圾回收，還可能導致不必要的重新平衡。將session.timeout.ms設置得更高會降低意外重新平衡的機會，但也意味着檢測到真正的故障需要更長的時間。
auto.offset.reset
當它開始讀取一個沒有提交偏移量的分區，或者提交的偏移量是無效的時，這個屬性控制着消費者的行爲（通常是因爲消費者關閉的時間太長，已經超出了經紀人的年齡）。缺省值是“latest”，這意味着缺少有效的偏移量，消費者將開始從最新的記錄（在消費者開始運行之後編寫的記錄）讀取。替代方法是“最早的”，這意味着缺少有效的偏移量，消費者將從頭開始讀取分區中的所有數據。
enable.auto.commit
我們在本章前面討論了抵銷的不同選擇。此參數控制使用者是否自動提交偏移量，並且默認爲true 。如果您希望控制何時提交偏移量，則將其設置爲false ，這是減少重複項並避免丟失數據所必需的。如果將enable.auto.commit設置爲true ，則可能還需要使用auto.commit.interval.ms來控制偏移提交的頻率。
partition.assignment.strategy
我們瞭解到，分區被分配給消費者羣體中的消費者。一個PartitionAssignor 則認爲，鑑於消費者和主題，他們訂閱類，決定哪些分區將被分配給消費者。默認情況下，Kafka有兩個分配策略：
RANGE
爲每個使用者分配來自其訂閱的每個主題的連續分區子集。因此，如果消費者C1和C2訂購了兩個主題T1和T2，並且每個主題具有三個分區，則C1將被分配來自主題T1和T2的分區0和1，而C2將從這些主題被分配分區2 。因爲每個主題都有不平衡的分區數量和分配爲每個主題獨立完成，第一個消費者比第二個消費者分區更多。無論何時使用範圍分配，消費者數量不會整齊劃分每個主題中的分區數量，就會發生這種情況。
ROUNDROBIN
從所有訂閱的主題中獲取所有分區，並逐個分配給消費者。如果之前描述的C1和C2使用RoundRobin分配，則C1將具有來自主題T1的分區0和2以及來自主題T2的分區1。C2將具有來自主題T1的分區1和來自主題T2的分區0和2。一般來說，如果所有消費者都訂購了相同的主題（一個非常常見的情況），RoundRobin分配將最終與所有消費者具有相同數量的分區（或至多1個分區差異）。
partition.assignment.strategy 允許您選擇一個分區分配策略。缺省值是org.apache.kafka.clients.consumer.RangeAssignor ，它實現了上述的Range策略。你可以用org.apache.kafka.clients.consumer.RoundRobinAssignor替換它。更高級的選項是實現你自己的分配策略，在這種情況下，partition.assignment.strategy 應該指向你的類的名字。
client.id
這可以是任何字符串，並且由經紀人用來識別從客戶端發送的消息。它用於日誌記錄和指標以及配額。
max.poll.records
這將控制一次調用poll（）將返回的最大記錄數。這有助於控制應用程序在輪詢循環中需要處理的數據量。
receive.buffer.bytes and send.buffer.byteu
這些是在寫入和讀取數據時由套接字使用的TCP發送和接收緩衝區的大小。如果這些設置爲-1，則將使用OS默認值。當生產者或消費者與不同的數據中心中的經紀人進行通信時，增加這些可能是一個好主意，因爲這些網絡鏈路通常具有更高的延遲和更低的帶寬。