1.為什麼使用訊息佇列？
（1）解耦：可以在多個系統之間進行解耦，將原本通過網路之間的呼叫的方式改為使用MQ進行訊息的非同步通訊，只要該操作不是需要同步的，就可以改為使用MQ進行不同系統之間的聯絡，這樣專案之間不會存在耦合，系統之間不會產生太大的影響，就算一個系統掛了，也只是訊息擠壓在MQ裡面沒人進行消費而已，不會對其他的系統產生影響。
（2）非同步：加入一個操作設計到好幾個步驟，這些步驟之間不需要同步完成，比如客戶去建立了一個訂單，還要去客戶軌跡系統新增一條軌跡、去庫存系統更新庫存、去客戶系統修改客戶的狀態等等。這樣如果這個系統都直接進行呼叫，那麼將會產生大量的時間，這樣對於客戶是無法接收的；並且像新增客戶軌跡這種操作是不需要去同步操作的，如果使用MQ將客戶建立訂單時，將後面的軌跡、庫存、狀態等資訊的更新全都放到MQ裡面然後去非同步操作，這樣就可加快系統的訪問速度，提供更好的客戶體驗。
（3）削峰：一個系統訪問流量有高峰時期，也有低峰時期，比如說，中午整點有一個搶購活動等等。比如系統平時流量並不高，一秒鐘只有100多個併發請求，系統處理沒有任何壓力，一切風平浪靜，到了某個搶購活動時間，系統併發訪問了劇增，比如達到了每秒5000個併發請求，而我們的系統每秒只能處理2000個請求，那麼由於流量太大，我們的系統、資料庫可能就會崩潰。這時如果使用MQ進行流量削峰，將使用者的大量訊息直接放到MQ裡面，然後我們的系統去按自己的最大消費能力去消費這些訊息，就可以保證系統的穩定，只是可能要跟進業務邏輯，給使用者返回特定頁面或者稍後通過其他方式通知其結果。
2.訊息佇列有什麼優點和缺點？
優點：1、對結構複雜、設計系統多的操作進行解耦操作，降低系統的操作複雜度、降低系統的維護成本。
2、對一個可以進行非同步操作的一些系統操作進行非同步，減小操作的響應時間，提供更好的使用者體驗。
3、可對高流量進行削峰，保證系統的平穩執行。
缺點：1、系統可用性降低。比如在系統中引入MQ，那麼萬一MQ掛了怎麼辦呢？一般而言，引入的外部依賴越多，系統越
脆弱，每一個依賴出問題都會導致整個系統的崩潰。
2、系統複雜度提高。需要考慮MQ的各種情況，比如：訊息的重複消費、訊息丟失、保證消費順序等等......
3、資料一致性問題。比如A系統已經給客戶返回操作成功，這時候操作BC都成功了，操作D卻失敗了，導致資料不
一致。
3.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。
下一篇《如何保證訊息佇列的高可用》