1.消費端弄丟了資料
唯一可能導致消費者弄丟資料的情況，就是說，你消費到了這個訊息，然後消費者那邊自動提交了 offset，讓 kafka 以為你已經消費好了這個訊息，但其實你才剛準備處理這個訊息，你還沒處理，你自己就掛了，此時這條訊息就丟咯。
這不是跟 rabbitmq 差不多嗎，大家都知道 kafka 會自動提交 offset，那麼只要關閉自動提交 offset，在處理完之後自己手動提交 offset，就可以保證資料不會丟。但是此時確實還是可能會有重複消費，比如你剛處理完，還沒提交 offset，結果自己掛了，此時肯定會重複消費一次，自己保證冪等性就好了。
生產環境碰到的乙個問題，就是說我們的 kafka 消費者消費到了資料之後是寫到乙個記憶體的 queue 裡先緩衝一下，結果有的時候，你剛把訊息寫入記憶體 queue，然後消費者會自動提交 offset。然後此時我們重啟了系統，就會導致記憶體 queue 裡還沒來得及處理的資料就丟失了。
2.kafka 弄丟了資料
這塊比較常見的乙個場景，就是 kafka 某個 broker 宕機，然後重新選舉 partition 的 leader。大家想想，要是此時其他的 follower 剛好還有些資料沒有同步，結果此時 leader 掛了，然後選舉某個 follower 成 leader 之後，不就少了一些資料？這就丟了一些資料啊。
生產環境也遇到過，我們也是，之前 kafka 的 leader 機器宕機了，將 follower 切換為 leader 之後，就會發現說這個資料就丟了。
所以此時一般是要求起碼設定如下 4 個引數：
我們生產環境就是按照上述要求配置的，這樣配置之後，至少在 kafka broker 端就可以保證在 leader 所在 broker 發生故障，進行 leader 切換時，資料不會丟失。
3. 生產者會不會弄丟資料？
如果按照上述的思路設定了acks=all，一定不會丟，要求是，你的 leader 接收到訊息，所有的 follower 都同步到了訊息之後，才認為本次寫成功了。如果沒滿足這個條件，生產者會自動不斷的重試，重試無限次。
Kafka如何保證訊息的可靠性傳輸
1.消費端弄丟了資料 在 kafka 服務端設定min.insync.replicas引數 這個值必須大於 1，這個是要求乙個 leader 至少感知到有至少乙個 follower 還跟自己保持聯絡，沒掉隊，這樣才能確保 leader 掛了還有乙個 follower 吧。在 producer 端設定...
Kafka如何保證資料可靠性
kafka的資料可靠性保證 1.副本資料同步策略 兩種副本資料同步策略 kafka選擇第二種 方案優點 缺點半數以上完成同步，就傳送ack 延遲低選舉新的leader時，容忍n臺節點的故障，需要2n 1個副本 全部完成同步，才傳送ack 選舉新的leader時，容忍n臺節點的故障，需要n 1個副本 ...
Kafka訊息可靠性
如果mq沒有類似資料庫事務結構和保證，是不可能達到訊息投遞100 可靠的，極端情況下訊息投遞要麼丟失或重複。下面咋們從producer，broker，consumer的角度分析一下kafka中會出現哪些情況。目前生產者傳送訊息 request.required.acks 有三種方式。acks 0 p...