原文鏈接:https://juejin.im/post/6844904078862974984
前言
消息隊列在互聯網技術存儲方面使用如此廣泛，幾乎所有的后端技術面試官都要在消息隊列的使用和原理方面對小伙伴們進行360°的刁難。
面試官杠上消息隊列？高可用、重復消費、丟失、順序消息...
什么，這么多問題啊！別慌，現在就來找找解決方案。
高可用
主流的MQ都有高可用模式可以供我們選擇！
RabbitMQ可以使用鏡像模式搭建高可用集群，可以配置數據同步到所有節點還是指定數量的節點以滿足實際需求。
RocketMQ、Kafka天然的是分布式設計讓他們天然具有高可用的技能^^ RocketMQ有多master多slave異步復制模式、多master多slave同步雙寫模式多種集群部署模式可以選擇 多master多slave模式部署架構圖:
Producer與NameServer集群中的其中一個節點（隨機選擇）建立長連接，定期從NameServer獲取Topic路由信息，並向提供Topic服務的Broker Master建立長連接，且定時向Master發送心跳。Producer只能將消息發送到Broker master。
Consumer則不一樣，它同時與提供Topic服務的Master、Slave建立長連接，既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
Kafka的架構與RocketMQ十分相似
Zookeeper的的作用與NameServer的作用相似， 用於保存集群配置、選舉Leader等。
集群中有許多broker用於堆積消息，Kafka支持水平擴展，一般broker數量越多，集群吞吐率越高。
Producer使用push模式將消息發布到broker。
Consumer使用pull模式從broker訂閱並消費消息。
重復消費
現在消息隊列一般都能保證at least once的，也就是消息至少一次投遞。 在這種情況為什么會出現重復消費的問題呢？ 通常都是由於網絡原因造成的，原因如下： 通常消息被成功消費后消費者都會發送一個成功標志給MQ，MQ收到這個標志就表示消息已經成功消費了，就不會再發送給其他消費者了。 但是如果因為網絡這個標志沒有送到MQ就丟失了，MQ就認為這個消息沒有被成功消費，就會再次發送給其他消費者消費，就造成了重復了。
這時我們看這個問題就變成了我們怎么保證消費端的冪等性。
冪等性 是指一個操作其執行任意多次所產生的影響均與一次執行的影響相同 大白話就是你同樣的參數調用我這個接口，調用多少次結果都相同
冪等性需要根據業務需求來具體看，但是主要的原理就是去重 一般可分為強校驗、弱校驗
- 強校驗 一般與金融相關的操作都是強校驗的 （人在996，鍋從天上來 偷跑) 比如消費者是一個打款服務，在付款成功后都加一條流水記錄。且兩個操作放入一個事務中。 再次消費的時候就去流水表查一下有沒有這條紀錄，如果有表示已經消費過了，直接返回。流水表也能起到對賬的作用！ 一些簡單的場景也可以依賴數據庫唯一約束實現
- 弱校驗 這個就沒那么嚴格，重復一下也沒那么重要的情況。 可以將ID保存在redis set中，過期時間看情況設置。 如果ID不能保證唯一可以選擇生產方生成一個token存入redis，消費方在消費后將其刪除（redis的操作能夠保證其原子性，刪除失敗會返回0）
消息丟失
有些消息怎么跑着跑着就沒了呢？
一般來講消息丟失的途徑有三個：
- 生產者弄丟數據
主流的MQ都有確認機制或者事務機制，可以保證生產者將消息送達到MQ。 比如RabbitMQ就有事務模式和confirm模式。 - 消息隊列弄丟數據
一般只要開啟MQ的持久化磁盤配置就能解決這個問題，寫入了磁盤就放心了。 - 消費者弄丟數據
消費者丟數據一般是因為采用了自動確認消息模式。MQ收到確認消息后會刪除消息，如果這時消費者異常了，那消息就沒了。改用手動確認就能解決這個問題了呢！
順序消息
順序消息的場景可能用的比較少，但是還是有的 比如一個電商的下單操作，下單后先減庫存然后生成訂單，這個操作就需要順序執行的 那怎么保證順序呢？
- 首先生產者需要保證入隊的順序，入隊都是亂的那再厲害的MQ也招架不住啊 (舌燦蓮花)
- 一般的MQ都能保證內部Queue是FIFO的（先進先出），但是只是針對一個Queue，所以在發送消息的時候可以使用Hash取模法將同一個操作的消息發送到同一個Queue里面，這樣就能保證出隊時是順序的了。
- 消費者也需要注意，如果多個消費者同時消費一個隊列。一樣可能出現順序錯亂的情況。這就相當於是多線程消費了！
通過上面的連招基本就能解決順序消息消費的問題了呢！