Kafka是一個高度可擴充的消息系統，它在LinkedIn的中央資料庫管理中扮演着十分重要的角色，因其可水準擴充和高吞吐率而被廣泛使用，現在已經被多家不同類型的公司作為多種類型的資料管道和消息系統。
那麼，如何學習Kafka源碼？？
我覺得最高效的方式就是去讀最核心的源碼，先看一張 Kafka結構圖 以及 Kafka 源碼全景圖
1. 消息的可靠性投遞
在使用 RabbitMQ 的時候，作為消息發送方希望杜絕任何消息丢失或者投遞失敗場景。
RabbitMQ 為我們提供了兩種方式用來控制消息的投遞可靠性模式。
confirm 确認模式:當消息從 producer 發送到 exchange 則會執行 confirmCallback中的confirm方法。
return 退回模式:當消息發送給Exchange後, Exchange将消息路由到queue失敗會執行ReturnCallBack。
确認模式會傳回{1.相關配置資訊, 2.交換機是否成功接收到消息 , true 成功 false失敗 3.失敗原因 }
回退模式會傳回{1.消息對象,2.錯誤碼,3.錯誤資訊,4.交換機名稱,5.路由鍵}
2.Consumer ACK(消費者 ACK)
ack指Acknowledge，确認。 表示消費端收到消息後的确認方式。
RabbitMQ提供三種确認方式：
自動确認: acknowledge=“none” 當消息一旦被Consumer接收到，則自動确認收到，并将相應 message 從 RabbitMQ 的消息緩存中移除。
手動确認: acknowledge=“manual” 如果出現異常，則調用channel.basicNack()方法，讓其自動重新發送消息。
根據異常情況确認：acknowledge=“auto”。
3. 消息過期(TTL)
TTL 全稱 Time To Live（存活時間/過期時間）。當消息到達存活時間後，還沒有被消費，會被自動清除。
RabbitMQ可以對消息設定過期時間，也可以對整個隊列（Queue）設定過期時間。
消息過期, 可以讓隊列統一過期, 也可以讓它單獨的消息過期。
4. 死信隊列
死信隊列，英文縮寫：DLX 。Dead Letter Exchange（死信交換機），當消息成為Dead message (死信)後，可以被重新發送到另一個交換機，這個交換機就是DLX。
消息成為死信的三種情況：
1.隊列消息長度到達限制；
2.消費者拒接消費消息，并且不把消息重新放入原目标隊列;
3.原隊列存在消息過期設定，消息到達逾時時間未被消費；
死信隊列和死信交換機：
死信隊列和死信交換機與正常的隊列和交換機一模一樣, 沒有任何差別 !!
如何實作隊列與死信交換機綁定 , 給隊列設定如下參數：
- x-dead-letter-exchange : 設定死信交換機
- x-dead-letter-routing-key : 設定死信路由key
5. 延遲隊列
消息進入隊列後不會立即被消費，隻有到達指定時間後，才會被消費。 例如:
延遲隊列是一個很強大的功能 , 但是在RabbitMQ中并沒有提供延遲隊列功能。
可以使用：TTL(消息過期)+死信隊列組合實作延遲隊列的效果。
實作流程圖如下 :
6. 消費端限流
當系統峰值比較高的時候 , 我們我們可以使用RabbitMQ實作削峰填谷, 讓我們系統處理的請求更加平穩
實作步驟
- 設定akc機制為手動确認
- 配置監聽容器
7.RabbitMQ應用問題 (消息補償機制)
我們通過之前的消息可靠性投遞 , ACK 确認機制 , 以及死信隊列 , 基本上已經能夠保證消息投遞成功了 !
為什麼還要消息補償機制呢？ 難道消息還會丢失，沒錯，系統是在一個複雜的環境，不要想的太簡單了，雖然以上的三種方案，基本可以保證消息的高可用不丢失的問題，但是作為有追求的程式員來講，要絕對保證我的系統的穩定性，有一種危機意識。
比如：持久化的消息，儲存到硬碟過程中，目前隊列節點挂了，存儲節點硬碟又壞了，消息丢了，怎麼辦？
産線網絡環境太複雜，是以不知數太多，是以要做消息補償機制 !
消息補償機制需要建立在業務資料庫和MQ資料庫的基礎之上 , 當我們發送消息時 , 需要同時将消息資料儲存在資料庫中, 兩者的狀态必須記錄。 然後通過業務資料庫和MQ資料庫的對比檢查消費是否成功，不成功，進行消息補償措施，重新發送消息處理
最後
由于篇幅限制，小編在此截出幾張知識講解的圖解，有需要的程式猿（媛）可以點贊後戳這裡免費領取全部資料擷取哦
[外鍊圖檔轉存中…(img-1g3IlShW-1624693188000)]
[外鍊圖檔轉存中…(img-312Bj2Ch-1624693188001)]
[外鍊圖檔轉存中…(img-Q7trfRwt-1624693188002)]