在解決這個問題之前，我們首先梳理一下kafka訊息的傳送和消費機制。
kafka的訊息傳送機制分為同步和非同步機制。可以通過producer.type屬性進行配置。使用同步模式的時候，有三種狀態來保證訊息的安全生產。可以通過配置request.required.acks屬性。三個屬性分別如下
當acks = 0的時候，不和kafka集群進行訊息接收確認，則當網路異常、緩衝區滿了等情況時，訊息可能丟失；當acks=1的時候，只保證leader寫入成功。當leader partition掛了的時候，資料就有可能發生丟失。另外還有一種情況，使用非同步模式的時候，當緩衝區滿了，acks=0的時候，不需要進行訊息接受是否成功的確認，所以會自動清空緩衝池裡的訊息。
同步模式下只需要將確認機制設定為-1，讓訊息寫入leader和所有的副本，就可以保證訊息安全生產。
非同步模式下，則需要在配置檔案中，將阻塞超時的時間設定為不限制。這樣生產端會一直阻塞。可以保證資料不丟失。
我們需要設定block.on.buffer.full = true。 這樣producer將一直等待緩衝區直至其變為可用。緩衝區滿了就阻塞
acks=all。所有的follwoer都響應了訊息就認為訊息提交成功。
retries=max。無限重試。
max.in.flight.requests.per.connnection = 1限制客戶端在單個連線上能夠傳送的未響應的請求的個數。設定為1表示kafka broker在響應請求之前client不能再向broker傳送請求了。通過此舉可以保證訊息的順序性。
訊息的接受端保證訊息不丟失的情形就比較簡單了。kafka的consumer模式是自動提交位移的。我們只需要在**邏輯中保證位移提交前訊息被處理就行。我們可以關閉自動提交位移，設定enable.auto.commit為false。自己手動處理訊息後提交位移。
重複消費的問題，一方面需要訊息中介軟體來進行保證。另一方面需要自己的處理邏輯來保證訊息的冪等性。極有可能**消費了訊息，但伺服器突然宕機，未來得及提交offset。所以我們可以在**保證訊息消費的冪等性。至於方法可以通過redis的原子性來保證，也可以通過資料庫的唯一id來保證。
kafka如何保證訊息不丟失
a 消費端弄丟了資料 關閉自動提交offset，在自己處理完畢之後手動提交offset，這樣就不會丟失資料。b kafka弄丟了資料 一般要求設定4個引數來保證訊息不丟失 給topic設定replication.factor引數 這個值必須大於1，表示要求每個partition必須至少有2個副本。在...
如何保證kafka訊息不丟失
這裡的kafka值得是broker,broker訊息丟失的邊界需要對齊一下 1 已經提交的訊息 2 有限度的持久化 如果訊息沒提交成功，並不是broke丟失了訊息 有限度的持久化 broker可用 producer.send object msg 這個傳送訊息的方式是非同步的 fire and fo...
kafka保證訊息不丟失
一 消費端保證訊息不丟失 消費端從broker取到訊息以後，先處理業務邏輯，然後再手動提交，這樣就可以避免消費端訊息丟失。二 生產端訊息不丟失 首先是設定每個訊息分割槽的副本，一本是幾個broker就配置幾個分割槽，然後設定如下，保證生產這生產的訊息傳送到broker時，不但leader確認收到訊息...