https://blog.csdn.net/weixin_42195284/article/details/93461429#7.1 push和pull模式
push和pull模式
在RocketMQ中，消費者有兩種模式，一種是push模式，另一種是pull模式。
- push模式：客戶端與服務端建立連接后，當服務端有消息時，將消息推送到客戶端。
- pull模式：客戶端不斷的輪詢請求服務端，來獲取新的消息。
但在具體實現時，Push和Pull模式都是采用消費端主動拉取的方式，即consumer輪詢從broker拉取消息。
區別： Push方式里，consumer把輪詢過程封裝了，並注冊MessageListener監聽器，取到消息后，喚醒 MessageListener的consumeMessage()來消費，對用戶而言，感覺消息是被推送過來的。 Pull方式里，取消息的過程需要用戶自己寫，首先通過打算消費的Topic拿到MessageQueue的集合，遍歷 MessageQueue集合，然后針對每個MessageQueue批量取消息，一次取完后，記錄該隊列下一次要取的開 始offset，直到取完了，再換另一個MessageQueue。
疑問：既然是采用pull方式實現，RocketMQ如何保證消息的實時性呢？
長輪詢
長輪詢即是在請求的過程中，若是服務器端數據並沒有更新，那么則將這個連接掛起，直到服務器推送新的 數據，再返回，然后進入循環周期。 客戶端像傳統輪詢一樣從服務端請求數據，服務端會阻塞請求不會立刻返回，直到有數據或超時才返回給客 戶端，然后關閉連接，客戶端處理完響應信息后再向服務器發送新的請求
消息模式
- 集群模式
同一個 ConsumerGroup(GroupName相同) 里的每 個 Consumer 只消費所訂閱消息的一部分內容， 同 一個 ConsumerGroup 里所有的 Consumer消費的內容合起來才是所訂閱 Topic 內容的整體， 從而達到 負載均衡的目的 。 - 廣播模式
同一個 ConsumerGroup里的每個 Consumer都 能消費到所訂閱 Topic 的全部消息，也就是一個消息會 被多次分發，被多個 Consumer消費。
重復消息的解決方案
造成消息重復的根本原因是：網絡不可達。只要通過網絡交換數據，就無法避免這個問題。所以解決這個問題的辦 法就是繞過這個問題。那么問題就變成了：如果消費端收到兩條一樣的消息，應該怎樣處理？
- 消費端處理消息的業務邏輯保持冪等性
- 保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現
第1條很好理解，只要保持冪等性，不管來多少條重復消息，最后處理的結果都一樣。
第2條原理就是利用一張日志 表來記錄已經處理成功的消息的ID，如果新到的消息ID已經在日志表中，那么就不再處理這條消息。 第1條解決方案，很明顯應該在消費端實現，不屬於消息系統要實現的功能。第2條可以消息系統實現，也可以業務 端實現。正常情況下出現重復消息的概率其實很小，如果由消息系統來實現的話，肯定會對消息系統的吞吐量和高 可用有影響，所以最好還是由業務端自己處理消息重復的問題，這也是RocketMQ不解決消息重復的問題的原因。
RocketMQ不保證消息不重復，如果你的業務需要保證嚴格的不重復消息，需要你自己在業務端去重