一、訊息丟失和重複消費
生產者:
1、生產者丟失訊息
(1)、丟失場景
配置檔案裡面,ack設定為0,也就是生產者傳送之後,
不管分割槽副本(leader和follower)是否收到都不管了,
如果傳送失敗,就會訊息丟失。
ack設定為1,也就是生產者傳送之後,只要leader接收到了,就會返回成功,
follower沒來及同步的時候leader掛掉,就會訊息丟失。
(2)、解決辦法:
設定ack=all / -1,保證leader和follower分割槽都收到之後,
再返回給生產者成功。
如果其中有乙個步驟異常,都會觸發kafka的重試機制。
2、生產者重複消費
(1)、重複訊息場景:
生產傳送的訊息沒有收到正確的broke響應，導致producer重試。
producer發出一條訊息，broke落盤以後因為網路等種種原因
傳送端得到乙個傳送失敗的響應或者網路中斷，然後producer收到
乙個可恢復的exception重試訊息導致訊息重複。
(2)、解決辦法:
啟動kafka的冪等性
enable.idempotence=true 同時要求 ack=all 且 retries>1。
冪等原理：
每個生產者producer都有乙個唯一id,producer每傳送一條資料,
都會帶上乙個sequence,當訊息落盤,sequence就會遞增1。
那麼只需要判斷當前訊息的sequence是否大於當前最大sequence,
大於就代表此條資料沒有落盤過,可以正常消費。
不大於就代表落盤過,這個時候重發的訊息會被服務端拒掉從而避免訊息重複。
1、broker丟失資料
(1)、丟失場景
<1>、ack=1,follower沒來及同步的時候leader掛掉也不好重試,
當follower被選舉為新的leader時,這部分沒同步的資料就丟失了。
<2>、分割槽副本數小於2個,導致沒有足夠數量的副本參與新leader選舉,
無法保證資料的高可用,當原leader掛了之後,
沒有follower被選舉為leader。
(2)、解決辦法:
<1>、ack=-1，保證leader和follower分割槽的資料可以落盤。
<2>、保證分割槽副本數大於2,保證資料的高可用性
<3>、設定重試次數等。
1、消費者丟失訊息
(1)、丟失場景
<1>、設定的自動提交offset,當消費者已經消費到了訊息,
也記錄了新的偏移量offset,但是後面的業務失敗了或者
沒來得及處理就掛了。
這時候因為offset已經更新了,這條訊息也再消費不到了。
(2)、解決辦法:
<1>、設定為手動提交成功,當業務**都執行完成之後,
再進行手動提交,確保訊息被真正處理到。
(1)、丟失場景
<1>、資料消費完沒有及時提交offset到broke。
訊息消費端在消費過程中掛掉沒有及時提交offset到broke，
另乙個消費端啟動拿之前記錄的offset開始消費，
由於offset的滯後性可能會導致新啟動的客戶端有少量重複消費。
(2)、解決辦法
<1>、設定為手動提交成功
<2>、在下游程式裡面做冪等,
冪等實際上就兩種方法:
(1)、將唯一鍵存入第三方介質,
要運算元據的時候先判斷第三方介質(資料庫或者快取)
有沒有這個唯一鍵。
(2)、將版本號(offset)存入到資料裡面,
然後再要運算元據的時候用這個版本號做樂觀鎖,
當版本號大於原先的才能操作。
Kafka 訊息丟失和訊息重複消費
producer 的acks引數值設定為 0 或者 1 不等待伺服器確認或者只讓leader確認解決方法 將acks的值設定為all或者 1，讓leader和followers全部進行確認 producer 沒有設定失敗重試解決方法 根據實際場景將retries引數值設定為正整數 consumerp...
Kafka 訊息丟失和訊息重複消費
producer 的acks引數值設定為 0 或者 1 不等待伺服器確認或者只讓leader確認解決方法 將acks的值設定為all或者 1，讓leader和followers全部進行確認 producer 沒有設定失敗重試解決方法 根據實際場景將retries引數值設定為正整數 consumerp...
kafka訊息丟失和訊息重複的情況
kafka作為訊息佇列，一定會有訊息丟失和訊息重複的問題，那什麼場景下會出現這種情況呢？kafka有乙個引數叫做acks。當生產者向leader傳送訊息後，會返回乙個確認的訊息給生產者。但是什麼時候leader會傳送確認訊息返回給生產者呢？就是通過acks這個引數決定的，這個引數有三種情況0 1 1...