1.為什麼使用訊息佇列？
（1）解耦：可以在多個系統之間進行解耦，將原本透過網路之間的呼叫的方式改為使用MQ進行訊息的非同步通訊，只要該操作不是需要同步的，就可以改為使用MQ進行不同系統之間的聯絡，這樣專案之間不會存在耦合，系統之間不會產生太大的影響，就算一個系統掛了，也只是訊息擠壓在MQ裡面沒人進行消費而已，不會對其他的系統產生影響。
不使用MQ的情況
使用MQ進行解耦之後
（2）非同步：加入一個操作設計到好幾個步驟，這些步驟之間不需要同步完成，比如客戶去建立了一個訂單，還要去客戶軌跡系統新增一條軌跡、去庫存系統更新庫存、去客戶系統修改客戶的狀態等等。這樣如果這個系統都直接進行呼叫，那麼將會產生大量的時間，這樣對於客戶是無法接收的；並且像新增客戶軌跡這種操作是不需要去同步操作的，如果使用MQ將客戶建立訂單時，將後面的軌跡、庫存、狀態等資訊的更新全都放到MQ裡面然後去非同步操作，這樣就可加快系統的訪問速度，提供更好的客戶體驗。
不使用MQ情況
使用MQ進行非同步之後
（3）削峰：一個系統訪問流量有高峰時期，也有低峰時期，比如說，中午整點有一個搶購活動等等。比如系統平時流量並不高，一秒鐘只有100多個併發請求，系統處理沒有任何壓力，一切風平浪靜，到了某個搶購活動時間，系統併發訪問了劇增，比如達到了每秒5000個併發請求，而我們的系統每秒只能處理2000個請求，那麼由於流量太大，我們的系統、資料庫可能就會崩潰。這時如果使用MQ進行流量削峰，將使用者的大量訊息直接放到MQ裡面，然後我們的系統去按自己的最大消費能力去消費這些訊息，就可以保證系統的穩定，只是可能要跟進業務邏輯，給使用者返回特定頁面或者稍後透過其他方式通知其結果。
使用MQ進行削峰
2。訊息佇列有什麼優點和缺點？
優點：
1、對結構複雜、設計系統多的操作進行解耦操作，降低系統的操作複雜度、降低系統的維護成本。
2、對一個可以進行非同步操作的一些系統操作進行非同步，減小操作的響應時間，提供更好的使用者體驗。
3、可對高流量進行削峰，保證系統的平穩執行。
缺點：
1、系統可用性降低。比如在系統中引入MQ，那麼萬一MQ掛了怎麼辦呢？一般而言，引入的外部依賴越多，系統越脆弱，每一個依賴出問題都會導致整個系統的崩潰。
2、系統複雜度提高。需要考慮MQ的各種情況，比如：訊息的重複消費、訊息丟失、保證消費順序等等……
3、資料一致性問題。比如A系統已經給客戶返回操作成功，這時候操作BC都成功了，操作D卻失敗了，導致資料不一致。
二、 kafka、activemq、rabbitmq、rocketmq都有什麼優點和缺點啊？
特性
ActiveMQ
RabbitMQ
RocketMQ
kafka
單機吞吐量
萬級，吞吐量比RocketMQ和kafka要低一個數量級
萬級，吞吐量比RocketMQ和kafka要低一個數量級
10萬級，RocketMQ也是可以支撐高吞吐的一種MQ
10萬級別，kafka最大優點就是吞吐量大，一般配合大資料類的系統來進行實時資料計算、日誌採集等場景。
topic數量對吞吐量的影響
topic可以達到幾百、幾千個的級別，吞吐量會有小幅度的下降。這是RocketMQ的一大優勢，可在同等數量機器下支撐大量的topic
topic從幾十個到幾百個的時候，吞吐量會大幅下降。所以在同等機器數量下，kafka儘量保證topic數量不要過多。如果支撐大規模topic需要增加更多的機器
時效性
ms級
微秒級，這是rabbitmq的一大特點，延遲是最低的
ms級
延遲在ms級以內
可用性
高，基於主從架構實現可用性
高，基於主從架構實現可用性
非常高，分散式架構
非常高，kafka是分散式的，一個數據多個副本，少數機器宕機，不會丟失資料，不會導致不可用
訊息可靠性
有較低的機率丟失資料
經過引數最佳化配置，可以做到0丟失
經過引數配置，訊息可以做到零丟失
功能支援
MQ領域的功能及其完備
基於erlang開發，所以併發效能極強，效能極好，延時低
MQ功能較為完備，分散式擴充套件性好
功能較為簡單，主要支援加單MQ功能
優勢
非常成熟，功能強大，在業內大量公司和專案中都有應用
erlang語言開發，效能極好、延時很低，吞吐量萬級、MQ功能完備，管理介面非常好，社群活躍；網際網路公司使用較多
介面簡單易用，阿里出品有保障，吞吐量大，分散式擴充套件方便、社群比較活躍，支援大規模的topic、支援複雜的業務場景，可以基於原始碼進行定製開發
超高吞吐量，ms級的時延，極高的可用性和可靠性，分散式擴充套件方便
劣勢
偶爾有較低機率丟失訊息，社群活躍度不高
吞吐量較低，erlang語音開發不容易進行定製開發，叢集動態擴充套件麻煩
介面不是按照標準JMS規範走的，有的系統遷移要修改大量的程式碼，技術有被拋棄的風險
有可能進行訊息的重複消費
應用
主要用於解耦和非同步，較少用在大規模吞吐的場景中
都有使用
用於大規模吞吐、複雜業務中
在大資料的實時計算和日誌採集中被大規模使用，是業界的標準
綜上所述，總結如下：
一般業務系統要引入MQ，最早大家都用ActiveMQ，但現在用的不多了。沒有經過大規模吞吐場景的驗證，社群也不活躍，不推薦再使用。後來大家開始用rabbitMQ，但是它是使用erlang語言開發的，如果不精通erlang，對公司而言，幾乎處於不可控的狀態，單其是開源的，社群活躍度高，擁有比較穩定的支援。現在越來越多的公司開始使用RocketMQ，但是要小心被拋棄的風險。如果公司有實力自己去維護開發，推薦使用。否則還是選擇RabbitMQ。如果實在大資料的實時計算、日誌採集等領域，用kafka是業界標準。所以，對於中小型公司，技術實力一般的，應該用rabbitmq，對於大公司，基礎架構研發能力強大的，推薦使用RocketMQ。
