1.什麼是kafka消費訊息時的冪等性
kafka消費訊息時的冪等性，簡而言之就是消費者對介面的多次呼叫所產生的結果和呼叫一次是是一致的，也就是說在kafka中有可能會消費到重複的資料，這個時候需要客戶端去處理這種情況，使得訊息消費一次和消費多次是一樣的結果。
2.產生原因
資料流**
生產者：生產者會往kafka中傳送訊息，kafka會給每條訊息乙個offset，代表這個資料的序號；
消費者消費訊息，消費之後，會將offset的資料提交給kafka；
kafka根據zookeeper中存放的offset資料區確定需要傳送那些資料給消費者；
容易出問題的環節：
由於消費者消費訊息之後，來不及向系統提交offset資料，有可能這個時候，系統發生異常，導致系統直接宕機。此時zookeeper中存放的offset的資料是上一次提交的資料，所以不是最新的。
還有乙個原因，由於消費者不是消費了一條資料之後，直接提交資料，而是批量的去提交，這個時候，如果是系統宕機，也是會導致zookeeper中存放的資料不是最準確的。
3. 解決辦法
當消費者消費到了重複的資料的時候，消費者需要去過濾這部分的資料。主要有以下兩種思路：
1.將訊息的offset存在消費者應用中或者第三方儲存的地方
可以將這個資料存放在redis或者是記憶體中，消費訊息時，如果有這條資料的話，就不會去做後續操作
2.資料落庫的時候，根據主鍵去過濾
在落庫時，如果不不在這條資料，則去新增，如果存在則去修改
如何維護訊息消費的冪等性
冪等性 乙個請求，不管重複來多少次，結果是不會改變的。每個訊息都會有唯一的訊息 id。1 先查再儲存 每次儲存資料的時候，都先查一下，如果資料存在了那麼就不儲存。這個情況是併發不高的情況。2 業務表新增約束條件 如果你的資料庫將來都不會分庫分表，那麼可以在業務表字段加上唯一約束條件 unique 這...
訊息佇列三 訊息重複消費問題（冪等性）
其實這個很常見的乙個問題，這倆問題基本可以連起來問。既然是消費訊息，那肯定要考慮考慮會不會重複消費？能不能避免重複消費？或者重複消費了也別造成系統異常可以嗎？這個是mq領域的基本問題，其實本質上還是問你使用訊息佇列如何保證冪等性，這個是你架構裡要考慮的乙個問題。要考慮的實際生產上的系統設計問題。首先...
訊息佇列 保證訊息消費的冪等
昨天業務反饋了乙個問題，乙個使用者的月流水賬單重複了，拿到userid，開始定位問題之路。檢視資料庫記錄，如下圖，使用者月流水資料確實重複了 taskid同乙個批次，每個月資料都有二條 1.首先，看外部資料 商是否重複推送業務資料給我，我程式中是會設定攔截重複訊息 2.檢視訊息接收，以及訊息推送到m...