使用MQ消息隊列的優缺點

一、前言

公司的項目一直都是在使用MQ的，可是因爲使用的功能很簡單，因此一直都是知其然不知其因此然，做爲一個程序猿有必要了解每個使用的技術，爲何使用它？它的優勢是什麼？缺點是什麼？等等。。。

2.0使用mq的好處

2.1解耦與複用

系統A要發送一個消息到多個系統，若是此時每增長一個系統，系統A都須要經過修改源碼來增長接口，此時耦合很是高，可是若是中間使用消息隊列的話，系統只須要發送一次到消息隊列，別的系統就能複用該信息，當增長或刪除系統調用接口的時候，不須要額外的更新代碼。

2.2異步

用戶調用一個接口的時候，可能該接口調用了別的方法。例如：用戶註冊的時候，後臺可能須要調用：查詢數據庫，插入數據庫，發送郵件，發送用戶指南等等...

可是用戶可能並不須要後臺將全部的任務執行完畢，那麼此時在初入數據口後面加入mq隊列，用戶就能很快獲得註冊成功的響應而去作一些別的事情。mq的機制又能保證最終的一致性，因此使用起來很安全很穩定。

2.3消峯

何爲消峯，就是當系統壓力過大的時候，讓系統壓力減少。如何作？

加入數據庫的讀寫每秒3000，在高峯期，系統的訪問達到了每秒10000。此時因爲加入了消息隊列，因此不會出現激增的訪問致使系統奔潰。
（注意，曉峯並不會讓用戶的等待時間減小，因此通常會跟異步搭配來使用）

3.0使用mq的缺點

3.1增長了複雜度與下降了可用性

原本系統之間直接通行調用接口就好了，可是引入了mq致使系統的複雜度大大增長，而且若是mq掛掉了，那麼系統之間的通訊就中斷了，致使整個系統的所有掛掉。

3.2一致性問題

A系統處理完了發送到消息對流後直接返回成功了，用戶覺得你這個請求就成功了；可是問題是，其餘系統消費該消息後，若是當中有一個系統出現了問題，致使數據丟失。最後就會發生數據不一致等問題。

4.0常見的mq的區別

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單機吞吐量	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	10萬級，RocketMQ也是能夠支撐高吞吐的一種MQ	10萬級別，這是kafka最大的優勢，就是吞吐量高。通常配合大數據類的系統來進行實時數據計算、日誌採集等場景
topic數量對吞吐量的影響			topic能夠達到幾百，幾千個的級別，吞吐量會有較小幅度的降低這是RocketMQ的一大優點，在同等機器下，可	topic能夠達到幾百，幾千個的級別，吞吐量會有較小幅度的降低這是RocketMQ的一大優點，在同等機器下，可
時效性	ms級	微秒級，這是rabbitmq的一大特色，延遲是最低的	ms級	延遲在ms級之內
可用性	高，基於主從架構實現高可用性	高，基於主從架構實現高可用性	很是高，分佈式架構	很是高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會致使不可用
消息可靠性	有較低的機率丟失數據		通過參數優化配置，能夠作到0丟失	通過參數優化配置，消息能夠作到0丟失
功能支持	MQ領域的功能極其完備	基於erlang開發，因此併發能力很強，性能極其好，延時很低	MQ功能較爲完善，仍是分佈式的，擴展性好	功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用，是事實上的標準
優劣勢總結	很是成熟，功能強大，在業內大量的公司以及項目中都有應用偶爾會有較低機率丟失消息並且如今社區以及國內應用都愈來愈少，官方社區如今對ActiveMQ 5.x維護愈來愈少，幾個月才發佈一個版本並且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用	erlang語言開發，性能極其好，延時很低；吞吐量到萬級，MQ功能比較完備並且開源提供的管理界面很是棒，用起來很好用社區相對比較活的。RabbitMQ吞吐量會低一些，這是由於他作的實現機制比較重。erlang開發很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。	接口簡單易用，並且畢竟在阿里大規模應用過，能夠作到大規模吞吐，性能也很是好，分佈式擴展也很方便，社區維護還能夠，可靠性和可用性是ok的，還能夠支撐大規模的topic數量。阿里出品都是java系的，咱們能夠本身閱讀源碼。	kafka的特色其實很明顯，就是僅僅提供較少的核心功能，可是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，並且分佈式能夠任意擴展同時kafka最好是支撐較少的topic數量便可，保證其超高吞吐量並且kafka惟一的一點劣勢是有可能消息重複消

5.0總結

因此在軟件的正常功能開發中，並不須要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在能夠異步處理的耗時操做，若是存在的話即可以引入消息隊列來解決。不然盲目的使用消息隊列可能會增長維護和開發的成本卻沒法獲得可觀的性能提高，那就得不償失了。