RabbitMQ/RocketMQ/Kafka 消息投遞

消息投遞分爲兩個部分,一是生產者對Broker的消息投遞,二是Broker對消費者的消息投遞。 生產者需要保證消息正確的投遞到了Broker, Broker保證每個消息至少消費一次。

RabbitMQ

1.事務(同步,性能差)

   txSelect() //事務開啓

   txCommit() //事務提交

   txrollback() //事務回滾

2.confirm 確認機制,包含三種模式

     普通確認:發送完一條消息,就等待waitForConfirms方法,等待Broker返回

     批量確認:發送完一批消息之後,等待waitFormConfirms,(異常情況下,會導致大量消息重複,會帶來重複消息)

     異步確認:註冊回調,Broker確認了一條或多條之後,執行回調

3.消費的消息確認包括三種模式

    autocommit 自動提交(在消息處理失敗的情況下,會丟失消息),

    手動ACK

    NACK (消息會重會隊列)

4.消費確認過程

      (1)broker投遞消息給消費者,並將投遞的消息記錄爲已投遞未確認。

      (2)消費者消費消息,並根據ACK模式進行消息消費確認(手動、自動)

      (3)如果消費者提交ACK,broker將對應消息標記刪除,並等待被刪除

      (4)如果提交NACK,將該消息重新投遞到消費隊列中。

      (5)如果已投遞未確認的消息在指定時間內未收到消息確認,重新投遞到消息隊列中。

參考:https://blog.csdn.net/u013256816/article/details/55515234/

 

RocketMQ

1.rocketMQ事務消息流程

    (1)發送half消息,消息狀態爲half狀態,消費者看不見(確認MQ還活着,且將消息發送的半消息隊列)

    (2)執行本地任務

    (3)如果本任務執行失敗 rollback  MQ刪除half消息

    (4)否則commit,將half消息標記爲已提交,並將消息投遞的消費隊列中。

2.事務補償流程,對一直沒有進行commit/rollback的消息,回調你的系統接口。

3.底層原理

   (1)如果發現是half消息,會把消息寫入 RMQ_SYS_TRANS_HALF_TOPIC 這個topic對應的一個ConsumeQueue 裏去,所以消費者無法看見。

    (2)補償機制是後臺有個定時任務,去掃描RMQ_SYS_TRANS_HALF_TOPIC中的half消息,如果超過一定時間還是half消息,會調用指定接口,去判斷這個half消息是rollback 或 commit。

     (3)RocketMQ都是順序寫入磁盤文件的,rollback的時候,本質是用一個OP操作標記消息的狀態。如果commit,RocketMQ就會在OP_TOPIC裏寫一條記錄,標記half消息commit,同時將消息寫入對應的Topic的ConsumeQueue裏。

4.消費確認

   (1)與RabbitMQ不同,RocketMQ ACK之後,並不會刪除消息,只是提交消費進度。當返回NACK時,會進入重試隊列(併發模式下)

   (2)默認重試次數最多16次,時間間隔每次不一樣,可以進行配置 messageDelayLevel=1s 5s 10s 30s 1m 2m .....

   (3)如果16次都無法處理完成,這時候就需要一個隊列叫做 死信隊列。

   (4)我們可以單獨對死信隊列的消息進行單獨處理,比如單獨開一個後臺線程,進行訂閱處理。

Kafka

1.消息事務

      確保一個事務中發送的多條消息,要麼都成功,要麼都失敗,沒有反查機制。Kafka的這種事務機制,單獨來使用的場景不多,更多的情況下是被用來配合Kafka冪等進制來實現Kafka的 Exactly Once。

      通常理解消費隊列的Exactly Once,是指消息從生產者發送到Broker,然後消費者從Broker拉取消息,進行消費,這個過程確保每個消息恰好傳輸一次,不重不丟。

      Kafka解決的是在流計算中,用Kafka作爲數據源,並且將計算結果保存到Kafa這種場景下,數據從Kafka的某個主題中消費,在計算集羣中計算,在把計算結果保存在Kafka的其他主題中。這樣的過程中,保證每條消息恰好計算一次,確保計算結果正確。

      Kafka的 Exactly Once 機制,是爲了解決 讀數據-計算-保存結果 這樣的計算過程中的數據不重不丟。

2.消費確認:

    這裏消費確認是指提交消費位移,與RocketMQ相似,但是Kafka不支持重試。

總結

1.RabbitMQ提供事務及confirm機制實現生產者的投遞保證,並通過消費確認機制實現消費者至少消費一次。

2.RocketMQ通過half消息即事務補償流程實現生產者投遞的保證。消費確認ACK並不會刪除消息,只是提交消費進度。NACK時,消息會進入重試隊列。

3.Kafka通過事務機制實現生產者的投遞保證,消費者在確認消費時提交消費位移。

參考

1.狸貓技術窩 RocketMQ系列

2.《深入理解Kafka:核心設計與實踐原理》

3.《RabbitMQ實戰》

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章