RabbitMQ MQ的優缺點

一、優點

1、解耦

1）未使用mq之前

a系統嚴重依賴各種亂七八糟的系統耦合起來，a系統產生了乙個比較關鍵的資料，很多系統需要a系統把這個關鍵的資料傳過來。負責a系統的哥們還得考慮，如果a系統掛了怎麼辦？如果e系統訪問超時怎麼辦？我是不是需要做乙個重試機制？

2）使用mq之後

如果來乙個新系統e需要資料，直接從mq中消費即可。如果老系統d不需要這條資料了，就取消對mq的消費即可。系統a壓根不用考慮給誰發資料，不需要維護這個**，不需要考慮人家是否呼叫成功，失敗超時等。

小結：通過mq的發布和訂閱的這麼乙個模型，pub/sub模型，系統a就跟其他系統徹底解耦了。

我們需要考慮一下負責的專案中是否有類似的場景，就是1個系統或者乙個模組，呼叫了多個系統或者模組，相互之間的呼叫很複雜，維護起來很麻煩。但是這個呼叫是不需要同步介面的，如果用mq給它非同步化解耦，也是可以的。你就需要考慮在你的專案裡，是否可以用mq去進行系統的解耦。

2、非同步

1）不用mq的同步高延時請求

一般的網際網路企業，對使用者的直接操作，一般要求是每個請求在200ms以內完成，對使用者幾乎是無感知的。而按照上述同步執行，整個過程大概需要1秒。

2）使用mq非同步化之後的介面效能優化

系統從接受請求到相應給使用者共耗時20ms+5ms。對使用者a而言，無感知。

3、削峰

1）沒用mq的時候，高峰期系統***的場景

一般的mysql，抗到每秒2000的請求就差不多啦。如果每秒請求5000，可能就直接把mysql打死啦。如果mysql***，整個系統沒法用了，但是中午高峰期過了之後，到了下午，也就是1萬個使用者同時操作，每秒中可能就50個請求。

2）使用mq來進行削峰

每秒在mq積壓3000條訊息，1個小時積壓18萬條訊息，1個半小時左右差不多就沒有積壓啦。

二、缺點

1）系統可用性降低

mq一旦故障了，系統a就沒法傳送訊息給mq啦，然後系統bcd也沒法消費到訊息。整個系統就崩潰了，沒有辦法正常運轉啦。

2）系統複雜性變高

硬生生加了個mq，你怎麼保證消費沒有重複消費？怎麼處理訊息丟失的情況？怎麼保證訊息傳遞的順序性。問題一大堆，痛苦不已。

3）系統一致性問題

系統abc執行成功了，但是系統d執行失敗了。但是給使用者返回執行成功了，結果後台邏輯實際上是差了一點。完全沒有執行完。