如果簡歷中有寫到使用過RabbitMQ或者其他的消息中間件，可能在MQ方面的第一個問題就是問：為什么要使用MQ
面試官期望的回答
1、項目中有什么業務場景需要用到MQ
2、但是用了MQ，會帶來很多問題，有什么缺點
所以，我們首先要回答的就是MQ的使用場景，在第一篇MQ文章中有簡單提過這個
應用場景
1、異步處理
2、流量削峰
3、日志處理
4、應用解耦
1、異步處理
假如系統有多個服務，如果是串行同步設計，例如：A服務產生一條數據，進行入庫操作花費100ms，然后需要同步給B服務，B服務執行
insert和update SQL花費了200ms，然后A服務得到響應，到了C服務，又花費了300ms，然后整個系統響應花費了600ms+，如果系統有更多服務，用
戶整個就崩潰了，特別是互聯網公司，需要響應在200ms以內。
如果使用MQ，A服務入庫操作話費100ms，發給MQ Broker只用了20ms，整個系統響應120ms，后面其余服務的入庫操作就是異步的了，這個響應
時間就很正常。而且對失敗重試很友好，設置重試次數，給個最終狀態，如果還是失敗，需要人工進行處理。
更通俗的例子就是：注冊之后，發送短信和郵件，通過MQ異步處理。
2、流量削峰
流量高峰期對於系統來說是不可避免的，特別是互聯網公司，例如：餓了嗎中午是高峰期，這時候有100W用戶在使用，每秒5000個請求打過來，
MySQL理論上只能承受每秒2000筆（這里不考慮Redis，或者其他架構設計），MySQL可能直接就掛了
如果使用MQ，每次從MQ拉取2000請求過來，處理完了，進行ACK確認，繼續拉取，能夠有流量削峰的作用，雖然會造成MQ消息的堆積
3、日志處理
這個主要是針對kafka的，很多大數據平台的日志量超級恐怖，kafka就是為了解決這種問題的，kafka我沒怎么用過，就不細講了。。。
4、應用解耦
其實本人做過的第一個項目是保險項目，應用耦合比較嚴重，技術方面都比較落后吧，一個保費計算通過WebService接口串行調用好幾個第三方
服務接口，感覺真的有點操蛋。類似這種情況，可能今天新增一個別的接口，明天減少一個接口。而且要考慮有的接口突然不通了，或者超時。是否
需要有一個重試機制，總之來說，很麻煩。
這種時候如果使用RabbitMQ，通過發布訂閱模型，使用交換機類型為fanout，都可以收到Producer的消息，fanout在講java API的時候有講到實
現廣播，我只要把消息發送給Broker，下游是否接口怎么變化，跟上游的關系已經不大了，反正就是你想怎么搞就怎么搞
MQ優缺點：
優點：
應用場景也是MQ的優點。。。
缺點：
1、系統可用性降低，MQ一旦掛了，影響很大，雖然MQ也有集群，可以實現高可用。據說有一線互聯網公司MQ真的宕機過幾小時，影響很大
2、使用MQ，我們需要考慮的更多了，導致系統復雜性增加，例如：消息的冪等性、消息如何進行可靠性投遞、消息突然丟失了等
3、一致性問題。例如業務流程設計服務ABCD，需要保證原子性的，但是ABC都成功了，D失敗了，這種時候就很蛋疼了
所以無論是什么中間件，Redis、MQ、Elasticsearch等，都要考慮很多