Kafka 應對場景：消息持久化、吞吐量是第一要求、狀態由客戶端維護、必須是分散式的。Kafka 認為 broker 不應該阻塞生產者，高效的磁碟順序讀寫能夠和網路 IO 一樣快，同時依賴現代 OS 文件系統特性，寫入持久化文件時並不調用 flush，僅寫入 OS pagecache，後續由 OS ...
Kafka 應對場景：消息持久化、吞吐量是第一要求、狀態由客戶端維護、必須是分散式的。Kafka 認為 broker 不應該阻塞生產者，高效的磁碟順序讀寫能夠和網路 IO 一樣快，同時依賴現代 OS 文件系統特性，寫入持久化文件時並不調用 flush，僅寫入 OS pagecache，後續由 OS flush。
這些特性決定了 Kafka 沒有做“確認機制”，而是直接將生產消息順序寫入文件、消息消費後不刪除（避免文件更新），該實現充分利用了磁碟 IO，能夠達到較高的吞吐量。代價是消費者要依賴 Zookeeper 記錄隊列消費位置、處理同步問題。沒有消費確認機制，還導致了 Kafka 無法瞭解消費者速度，不能採用 push 模型以合理的速度向消費者推送數據，只能利用 pull 模型由消費者來拉消息（消費者承擔額外的輪詢開銷）。
消息生產分為同步模式和非同步模式
配置：https://www.cnblogs.com/the-tops/p/6046487.html
producer.type：消息發送類型同步還是非同步，預設為同步
消息確認分為三個狀態
(a)0：生產者只負責發送數據
(b)1：某個partition的leader收到數據給出響應
(c)-1：某個partition的所有副本都收到數據後給出響應
在同步模式下
(a)生產者等待10S，如果broker沒有給出ack響應，就認為失敗。
(b)生產者重試3次，如果還沒有響應，就報錯。
在非同步模式下
(a)先將數據保存在生產者端的buffer中。Buffer大小是2萬條。
(b)滿足數據閾值或者數量閾值其中的一個條件就可以發送數據。
(c)發送一批數據的大小是500條。
Kafka消息保證生產的信息不丟失和重覆消費問題
（1）使用同步模式的時候，有3種狀態保證消息被安全生產，在配置為1（只保證寫入leader成功）的話，如果剛好leader partition掛了，數據就會丟失。
（2）還有一種情況可能會丟失消息，就是使用非同步模式的時候，當緩衝區滿了，如果配置為0（還沒有收到確認的情況下，緩衝池一滿，就清空緩衝池裡的消息），
數據就會被立即丟棄掉。
在數據生產時避免數據丟失的方法：
（1）在同步模式的時候，確認機制設置為-1，也就是讓消息寫入leader和所有的副本。
（2）在非同步模式下，如果消息發出去了，但還沒有收到確認的時候，緩衝池滿了，在配置文件中設置成不限制阻塞超時的時間，也就說讓生產端一直阻塞，這樣也能保證數據不會丟失。
