關於MQ的幾件小事（一）消息隊列的用途、優缺點、技術選型

1.爲何使用消息隊列？

（1）解耦：能夠在多個系統之間進行解耦，將本來經過網絡之間的調用的方式改成使用MQ進行消息的異步通信，只要該操做不是須要同步的，就能夠改成使用MQ進行不一樣系統之間的聯繫，這樣項目之間不會存在耦合，系統之間不會產生太大的影響，就算一個系統掛了，也只是消息擠壓在MQ裏面沒人進行消費而已，不會對其餘的系統產生影響。

（2）異步：加入一個操做設計到好幾個步驟，這些步驟之間不須要同步完成，好比客戶去建立了一個訂單，還要去客戶軌跡系統添加一條軌跡、去庫存系統更新庫存、去客戶系統修改客戶的狀態等等。這樣若是這個系統都直接進行調用，那麼將會產生大量的時間，這樣對於客戶是沒法接收的；而且像添加客戶軌跡這種操做是不須要去同步操做的，若是使用MQ將客戶建立訂單時，將後面的軌跡、庫存、狀態等信息的更新全都放到MQ裏面而後去異步操做，這樣就可加快系統的訪問速度，提供更好的客戶體驗。

（3）削峯：一個系統訪問流量有高峯時期，也有低峯時期，好比說，中午整點有一個搶購活動等等。好比系統平時流量並不高，一秒鐘只有100多個併發請求，系統處理沒有任何壓力，一切風平浪靜，到了某個搶購活動時間，系統併發訪問了劇增，好比達到了每秒5000個併發請求，而咱們的系統每秒只能處理2000個請求，那麼因爲流量太大，咱們的系統、數據庫可能就會崩潰。這時若是使用MQ進行流量削峯，將用戶的大量消息直接放到MQ裏面，而後咱們的系統去按本身的最大消費能力去消費這些消息，就能夠保證系統的穩定，只是可能要跟進業務邏輯，給用戶返回特定頁面或者稍後經過其餘方式通知其結果。

2.消息隊列有什麼優勢和缺點？

優勢：一、對結構複雜、設計系統多的操做進行解耦操做，下降系統的操做複雜度、下降系統的維護成本。    二、對一個能夠進行異步操做的一些系統操做進行異步，減少操做的響應時間，提供更好的用戶體驗。    三、可對高流量進行削峯，保證系統的平穩運行。 缺點：一、系統可用性下降。好比在系統中引入MQ，那麼萬一MQ掛了怎麼辦呢？通常而言，引入的外部依賴越多，系統越
    脆弱，每個依賴出問題都會致使整個系統的崩潰。    二、系統複雜度提升。須要考慮MQ的各類狀況，好比：消息的重複消費、消息丟失、保證消費順序等等......    三、數據一致性問題。好比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。

下一篇《如何保證消息隊列的高可用》