kafka的ack機制：在kafka傳送資料的時候，每次傳送訊息都會有乙個確認反饋機制，確保訊息正常的能夠被收到，其中狀態有0,1，-1。
producer.type=syncrequest.required.acks=1
producer.type=async結論：producer有丟資料的可能，但是可以通過配置保證訊息的不丟失。request.required.acks=1
queue.buffering.max.ms=5000
queue.buffering.max.messages=10000
queue.enqueue.timeout.ms = -1
batch.num.messages=200
通過offset commit 來保證資料的不丟失，kafka自己記錄了每次消費的offset數值，下次繼續消費的時候，會接著上次的offset進行消費。
而offset的資訊在kafka0.8版本之前儲存在zookeeper中，在0.8版本之後儲存到topic中，即使消費者在執行過程中掛掉了，再次啟動的時候會找到offset的值，找到之前消費訊息的位置，接著消費，由於offset的資訊寫入的時候並不是每條訊息消費完成後都寫入的，所以這種情況有可能會造成重複消費，但是不會丟失訊息。
唯一例外的情況是，我們在程式中給原本做不同功能的兩個consumer組設定kafkaspoutconfig.bulider.setgroupid的時候設定成了一樣的groupid，這種情況會導致這兩個組共享同乙份資料，就會產生組a消費partition1，partition2中的訊息，組b消費partition3的訊息，這樣每個組消費的訊息都會丟失，都是不完整的。 為了保證每個組都獨享乙份訊息資料，groupid一定不要重複才行。
每個broker中的partition我們一般都會設定有replication（副本）的個數，生產者寫入的時候首先根據分發策略（有partition按partition，有key按key，都沒有輪詢）寫入到leader中，follower（副本）再跟leader同步資料，這樣有了備份，也可以保證訊息資料的不丟失。
kafka資料丟失問題
1 消費端弄丟了資料 唯一可能導致消費者弄丟資料的情況，就是說，你那個消費到了這個訊息，然後消費者那邊自動提交了offset，讓kafka以為你已經消費好了這個訊息，其實你剛準備處理這個訊息，你還沒處理，你自己就掛了，此時這條訊息就丟咯。這不是一樣麼，大家都知道kafka會自動提交offset，那麼...
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 保證原子性的寫入多個分割槽，即寫入到多個分割槽的訊息要麼全部成功，...