RabbitMQ簡介
MQP 即Advanced Message Queuing Protocol(高級消息隊列協議),是一個網絡協議，是應用協議的一個開發標準，為面向消息的中間件設計。基於此協議的客户端與消息中間件可傳遞消息，並不受客户端/中間件不同產品，不同的開發語言等條件的限制。2006年，AMQP規範發佈。類比HTTP。
2007年，Rabbit技術公司基於AMQP標準開發的RabbitMQ 1.0發佈。RabbitMQ採用Erlang語言開發。Erlang語言由Ericson設計，專門為開發高併發和分佈式系統的一種語言，在電信領域使用廣泛。
MQ的優勢，為什麼要使用MQ？
1.應用解耦(提高容錯性和可維護性)
2.異步提速(與數據庫串行、並行同理)
MQ的劣勢
1.系統可用性降低(系統引入的外部依賴越多，系統穩定性越差，一旦MQ宕機會對業務造成影響)——>如何保證MQ的高可用？
2.系統複雜性提高 ——>如何保證消息不被丟失？
常見MQ及區別
MQ的工作模式
-
可伸縮性： 設計為分佈式的，例如分為nameBervice和broker；broker負責Topic消息存儲、管理和分發等功能；bs就是一個註冊中心、維護所有Brokers信息。這樣通過水平擴展就提升了吞吐量和容量了。
-
可靠性： 數據要磁盤落地，來做到可恢復、持久化。然後順序寫隨機讀來提高性能。
-
容錯性： 多個機器中有的宕機後,要有類似zookeeper的的投票選舉功能，確保集羣穩定運行。
MQ常見面試題
1.1、場景\業務
例：
需求：1.下單後，30分鐘為支付，取消訂單，回滾庫存
2.新用户註冊成功7天后，發送短信問候
解：使用MQ高級特效—延遲隊列（設置多久消費這條消息）
P:MQ中並未提供延遲隊列功能。但是可以使用：TTL+死信隊列組合實現延遲隊列的效果
1.2、消息積壓、重複消費、消息丟失等怎麼處理？解決方案？
消息積壓：
一般出現消息積壓基本上分為幾種情況：
-
消費者消費消息的速度趕不上生產速度，這總問題主要是業務邏輯沒設計好消費者和生產者之間的平衡，需要改業務流程或邏輯已保證消費度跟上生產消息的速，譬如增加消費者的數量等。
-
消費者出現異常，導致一直無法接收新的消息，這種問題需要排查消費的邏輯是不是又問題，需要優化程序。
解決思路：
1.拆分MQ,生產者一個MQ，消費者一個MQ，寫一個程序監聽生產者的MQ模擬消費速度（譬如線程休眠），然後發送到消費者的MQ，如果消息積壓則只需要處理生產者的MQ的積壓消息，不影響消費者MQ
2.拆分MQ,生產者一個MQ，消費者一個MQ，寫一個程序監聽生產者的MQ，定義一個全局靜態變量記錄上一次消費的時間，如果上一次時間和當前時間只差小於消費者的處理時間，則發送到一個延遲隊列（可以使用死信隊列實現）發送到消費者的MQ，如果消息積壓則只需要處理生產者的MQ的積壓消息，不影響消費者MQ
3.使用Redis的List或ZSET做接收消息緩存，寫一個程序按照消費者處理時間定時從Redis取消息發送到MQ
4.設置消息過期時間，過期後轉入死信隊列，寫一個程序處理死信消息（重新如隊列或者即使處理或記錄到數據庫延後處理）
重複消費：先説為什麼會重複消費：正常情況下，消費者在消費消息的時候，消費完畢後，會發送一個確認消息給消息隊列，消息隊列就知道該消息被消費了，就會將該消息從消息隊列中刪除；
但是因為網絡傳輸等等故障，確認信息沒有傳送到消息隊列，導致消息隊列不知道自己已經消費過該消息了，再次將消息分發給其他的消費者。
針對以上問題，一個解決思路是：保證消息的唯一性，就算是多次傳輸，不要讓消息的多次消費帶來影響；保證消息等冪性；
比如：在寫入消息隊列的數據做唯一標示，消費消息時，根據唯一標識判斷是否消費過；
消息丟失：一.消息持久化
1.Exchange設置持久化：durable:true
2.Queue設置持久化
3.Message持久化發送
二.ACK確認機制
1.消息發送確認
2.消息接受確認
三.設置集羣鏡像模式
四.消息補償機制
1.3、MQ使用場景、為什麼使用MQ、MQ的優劣
1.4、使用MQ時遇到什麼問題，怎麼解決
