一、會丟資料的情況
1、生產端
可通過 producer.type 來選擇傳送模式，預設為 producer.type = sync (同步)，非同步設定為 async
1）同步模式下
producer 在傳送訊息之後，在得到返回結果前阻塞。這是一種犧牲效能的辦法，而且對於不同的配置，效能的損失程度不同、可靠性也不一樣。關鍵引數如下
request.required.acks 表示producer的一次請求被認為是完成時，需要的 ack 確認數，這裡的 ack 具體是指哪些 broker 已經提交訊息到log日誌檔案中。
為 0 時表示不需要等待來自broker的確認資訊，可實現最大的吞吐量，但是這種發出去就不管了的方式可能會丟失資料。因為 message 放入 socket buffer 即認為已經傳送，沒有任何機制來保證broker成功接收資料。重試機制也不會起作用。
為 1 時表示等 leader 所在 broker 已經成功將訊息寫入到本地log中返回確認即可，但是如果 leader 返回確認後，fllower 還沒有來的及從leader同步message而 leader 就掛掉了，此時也會丟資料。
為 -1 時 producer 會獲得leader及所有同步replicas都收到資料的確認，同步replicas數由 min.insync.replicas 確定。
2）非同步模式下
非同步傳送模式下，可以批量處理請求，訊息先被填入緩衝區當中，當達到 batch.size 時或者達到 linger.ms 配置的等待時間傳送緩衝區資料到broker。
這種情況下，如果客戶端掛了，那麼便會丟失未傳送資料。
2、消費端
enable.auto.commit=true
一般情況下，自動提交offset預設為true，也就是在consumer拉取一批資料時會自動提交最新的消費偏移給kafka，表示我已經消費到**了。
這樣的話，如果consumer拉取並提交了最新的 offset ，而 consumer 當前的message還沒有處理完，這時consumer掛了，恢復時從最新提交的 offset 處理，這麼一來便丟失了資料。
解決這個問題，可以在訊息處理完成後手動提交 offset。
3、broker
unclean.leader.election.enable = true 從kafka 0.11.0.0 之後 預設值改為了 false
這個引數確定了什麼事呢？也就是確定不在同步副本當中的broker是否可以參與新leader的選舉
1）參與
如果在isr中的同步副本同時下線，這時如果unclean.leader.election.enable = true，那麼不在isr中的副本就可以參與選舉，此時機器還是可用的。
但是乙個問題是，不在isr中的副本，其偏移會落後於isr中的副本，當其成為leader之後，接收來自客戶端的訊息。之前下線的leader恢復之後成為follower，去新的leader同步訊息，發現自己的log end offset大於新leader的log end offset，必須進行截斷（follower不能比leader的leo大），此時便造成了丟資料和不一致的情況。
2）不參與
如果unclean.leader.election.enable = false，那麼不在isr中的副本就不可以參與選舉，此時如果在isr中的同步副本同時下線，kafka服務便不可用了。
4、刷盤方式
1）同步刷盤
寫入頁快取，執行緒等待，通知刷盤執行緒刷盤，刷盤執行緒刷盤後，喚醒前端等待執行緒，等待執行緒向使用者返回寫入結果，也就是進行ack
可見，同步等待落盤後確認，不會出現掉電資料未刷盤的情況，但對效能的影響是顯而易見的
2）非同步刷盤
寫入頁快取，執行緒返回，向使用者返回寫入結果，刷盤由作業系統完成
如果執行緒返回ack，而broker所在節點突然掉電導致頁快取未刷盤，就丟失了資料。
和主動刷盤相關的幾個配置
log.flush.interval.messages 設定刷盤前在記憶體中最多累積的訊息數
log.flush.interval.ms 設定訊息在刷盤之前最多在記憶體中儲存的ms數
log.flush.scheduler.interval.ms 設定log flusher執行緒檢查是否有訊息需要刷盤的檢查頻度
在kafka中，資料可靠性主要靠分布式副本冗餘來完成，避免單點故障，所以不出現極端的情況，非同步刷盤也沒有問題。
總之，萬事無絕對，效能和可靠性之間總是要進行權衡，根據需要來進行選擇吧。
kafka 資料不丟失
設定引數 props.put bootstrap.servers 10.176.2.170 9092,10.176.1.97 9092,10.176.7.57 9092 producer用於壓縮資料的壓縮型別。預設是無壓縮 props.put compression.type gzip 增加延遲 p...
Kafka重複消費，不丟失資料
kafka0.11.0.0版本正式支援精確一次處理語義exactly once semantic eos kafka冪等性參考 1 冪等producer 保證單個分割槽的只會傳送一次，不會出現重複訊息 2 事務 transation 保證原子性的寫入多個分割槽，即寫入到多個分割槽的訊息要麼全部成功，...
Kafka如何保證資料不丟失
kafka的ack機制 在kafka傳送資料的時候，每次傳送訊息都會有乙個確認反饋機制，確保訊息正常的能夠被收到，其中狀態有0,1，1。producer.type sync request.required.acks 1 producer.type async request.required.ac...