文章目錄
- 如何保證訊息不被重復消費？
- 如何保證消費的可靠性傳輸?訊息不丟失？
- kafka :
- rabbitMQ：
- 如何保證訊息順序
- rabbitMQ
- kafka有序
- 談談rabbitMQ的了解？
- rabbitMQ集群模式
- 談談kafka理解
- kafka性能
- kafka如何從頭開始消費topic的全量資料
- 選型
- 為什么選擇使用rabbitMq?
- 為什么沒有使用rocketMQ?
- 為什么選擇kafka?
如何保證訊息不被重復消費？
造成重復消費原因其實都是類似的，確認資訊沒有傳送到訊息佇列，導致訊息佇列不知道自己已經消費過該訊息了，再次將該訊息分發給其他的消費者，
rabbitMQ是消費完成發送一個ACK確認訊息,
rocketMQ是消費完成回傳一個CONSUME_SUCCESS成功標志，
kafka消費過訊息后，需要提交offset
如何解決？
根據訊息的里面唯一標志，比如訂單號等唯一鍵，做冪等性處理，無論消費多少次都一樣，
如何保證消費的可靠性傳輸?訊息不丟失？
kafka :
生產者: 1.使用異步回呼發送模式，使發送出去的訊息得到發送結果，2.將ack設定為all，leader和follower全部落盤后才認為成，
訊息佇列：訊息佇列設定多個副本
消費者：開啟手動提交offset，確保訊息正確消費后再提交
rabbitMQ：
生產者：開啟異步確認模式，訊息被投遞后，會回傳一個ack給生產者，如果rabbitMQ沒能處理訊息，則會發送一個 Nack訊息，可以進行重試
訊息佇列：開始持久化，超時訊息進入死信佇列，
消費者：設定手動回傳ack，
如何保證訊息順序
rabbitMQ
可以將先后順序的訊息放到同一個訊息佇列中，然后用一個消費者去消費，
如果有多個消費者怎么辦？
這個可以根據業務邏輯判斷，比如賣家發貨，賣家識訓，這兩個行為是有序，如果先讀取的是識訓消費，就回傳失敗，然后等待一段時間進行重試，重試的話可以將訊息繼續放入佇列中，也可以手動提交ack
kafka有序
在kafka中只保證了一個磁區中的訊息是有序的，如果要保證訊息順序，有2個辦法，
方法1.topic只創建一個磁區，那么所有資料都發送到一個磁區，保證了訊息順序消費，
方法2. 生產者在發送訊息的時候，指定發送到哪個磁區，
談談rabbitMQ的了解？
- rabbitMQ是基于erlang語言開發，
- rabbitMQ基本架構有生產者，消費者，訊息佇列
- 核心組件是exchange和queue，一個exchange可以和多個佇列系結，系結方式有direct topic 發布訂閱，
- exchange包含普通的交換機和死信交換機，佇列中的訊息超時沒有消費會發送到死信交換機，進而轉發到死信佇列
rabbitMQ集群模式
- 普通模式，可以橫向擴展，但是不能保證搞可用，每個節點值保存部分資料，各個節點互通，消費時候以此從各個節點尋找資料，
- 鏡像模式，可以保證高可用，但是每個節點存盤了所有資料，不能支持橫向擴展
談談kafka理解
kafka架構中主要包含生產者，消費者，broker，
- 消費者有個消費者組，同一個訊息只能被一個組里面的一個消費者消費，消費后提交offset，記錄當前消費位置，
- 訊息佇列broker，一個broker可以存盤有多個topic訊息，kafka有個磁區的概念，一個topic，可以有多個磁區，磁區可以實作分布式存盤，一個每個磁區存一部分訊息，所以kafka支持橫向擴展，
kafka性能
kafka訊息存盤和傳輸有很高的性能，主要是因為采用了順序存盤，零拷貝，索引，批量讀寫，
訊息讀寫只會從leader節點讀寫，leader節點是分布在各個broker中，分擔了單個broker的讀寫壓力，從節點會從主節點拉取資料進行同步，向主節點發送fetch請求，主節點回傳資料，并且記錄offset位置，
kafka如何從頭開始消費topic的全量資料
滿足兩個條件，
- 新建一個消費者組group.id，之前沒有被消費者使用過，
- 指定auto.offset.reset，引數值設定為eearlist
選型
為什么選擇使用rabbitMq?
rabbitmq的吞吐量已經足夠支持系統業務，
開源提供的管理界面比較友好，非常便捷，提供了豐富的延遲佇列功能，滿足開發需求，
缺點： 當然rabbitmq缺點是，采用erlang開發，維護比較困難，很難定制，如果采用鏡像模式的話，不支持橫向擴展，
為什么沒有使用rocketMQ?
公司業務沒有到達rocketmq的量級，中間件平臺一直用的rabbtmq相對穩定，第三rocketmq的延遲佇列的時間，目前開源的部分還不能自定義延遲時間，
為什么選擇kafka?
kafka是流式處理，從端到端，沒有復雜的傳遞規則，采用零拷貝和順序讀寫，有高吞吐、低延遲，
而且可以分布式部署，有partition支持，可以很好的支持橫向擴展，對于大量訊息，訊息通知或者日志系統采用kafka，
對于可能存在的訊息重發，可以利用訊息冪等性解決，訊息丟失可以開啟手動offset ，開啟all落盤，異步回呼發送
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/421694.html
標籤：其他
上一篇：03WordCount案例