Kafka的消息安全機制

序言

       關於JMS有一些共性的問題,每個框架給出的解決方案各不相同.這裏僅針對Kafka.

 

生產者消息可靠性

生產者提供瞭如下的幾個模式來弄處理生產消息的可靠性.

1. 發送並忘記(不關心消息是否正常到達，對返回結果不做任何判斷處理):發送並忘記的方式本質上也是一種異步的方式，只是它不會獲取消息發送的返回結果，這種方式的吞吐量是最高的，但是無法保證消息的可靠性

2. 同步發送(通過get方法等待Kafka的響應，判斷消息是否發送成功):以同步的方式發送消息時，一條一條的發送，對每條消息返回的結果判斷， 可以明確地知道每條消息的發送情況，但是由於同步的方式會阻塞，只有當消息通過get返回future對象時，纔會繼續下一條消息的發送
3. 異步發送+回調函數(消息以異步的方式發送，通過回調函數返回消息發送成功/失敗):在調用send方法發送消息的同時，指定一個回調函數，服務器在返回響應時會調用該回調函數，通過回調函數能夠對異常情況進行處理，當調用了回調函數時，只有回調函數執行完畢生產者纔會結束，否則一直會阻塞

 

對應配置文件的內容如下:當producer向leader發送數據時，可以通過request.required.acks參數來設置數據可靠性的級別：

   1（默認）：這意味着producer在ISR中的leader已成功收到的數據並得到確認後發送下一條message。如果leader宕機了，則會丟失數據。

   0：這意味着producer無需等待來自broker的確認而繼續發送下一批消息。這種情況下數據傳輸效率最高，但是數據可靠性確是最低的。

   -1：producer需要等待ISR中的所有follower都確認接收到數據後纔算一次發送完成，可靠性最高。但是這樣也不能保證數據不丟失，比如當ISR中只有leader時，這樣就變成了acks=1的情況。

 

消費者的消息可靠性

      唯一可能導致消費者弄丟數據的情況，就是說，你消費到了這個消息，然後消費者那邊自動提交了 offset，讓 Kafka 以爲你已經消費好了這個消息，但其實你纔剛準備處理這個消息，你還沒處理，你自己就掛了，此時這條消息就丟咯。但是此時確實還是可能會有重複消費，比如你剛處理完，還沒提交 offset，結果自己掛了，此時肯定會重複消費一次，自己保證冪等性就好了。

 

關於消息的順序

這個可以從邏輯上進行控制,也可以在隊列上進行處理,比如只有一個消費者.沒消費完一次才能消費下一個消息.

 

關於重複消費

這個可以從邏輯上進行判斷,但是這是萬不得以的情況.另後面想到了問題在補充,歡迎騷擾:[email protected]