MQ消息隊列基礎1

消息隊列的作用：

異步，削峯，降低系統耦合性。

1.通過異步處理提高系統性能：（削峯，減少響應時間，比如如果沒有消息隊列，那麼可能100條數據同時打入數據庫，而有了消息隊列，則數據會一條一條寫入數據庫，遵守消息隊列的先進先出規則）。

2.降低系統耦合性：不同進程之間傳遞消息時，兩個進程之間耦合度過高，改動一個進程，則必須修改另一個進程，爲了隔離這兩個進程，在兩進程間抽離出一層（一個模塊），兩進程之間的通信，必須通過消息隊列來傳遞，單獨修改某一個進程，不會影響另一個；（比如你去送信，如果接受人的地址改變了，那麼你送信的路線也會改變，但是如果中間多個郵局，那麼即使收信人的地址改變了，也和你沒關係，你只要把信放在郵局就ok了，你的路線永遠是從你家到郵局這條固定的。）

常見的MQ：ActiveMq,RabbitMQ,RocketMQ,Kafka

名稱	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單擊吞吐量	萬級，吞吐量比RockerMQ和Kafka要低了一個數量級	萬級，吞吐量比RocketMQ和kafka要低了一個數量級	十萬級，RocketMQ也是可以支撐高吞吐的一種MQ	十萬級別，這是kafka最大的有點，就是吞吐量高。一般配合大數據類的系統來進行實時數據計算，日誌採集等場景
topic數量對吞吐量的影響			topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降。這是RocketMQ的一大優勢，在同等機器下，可以支撐大量的topic	topic從幾十個到幾百個的時候，吞吐量會大幅度下降。因此在同等機器下，kafka儘量保證topic數量不要過多，如果要支撐大規模topic，需要增加更多的機器資源
時效性	ms級	微秒級，這是rabbitmq的一大特點，延遲是最低的	ms級	延遲在ms級以內
高可用性	高，基於主從架構實現高可用	高，基於主從架構實現高科應	非常高，分佈式架構	非常高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
消息可靠性	有較低的概率丟失數據	開啓持久化使數據寫入磁盤，數據丟失概率基本可以忽略（除非數據還沒吸入磁盤呢rabbitmq就掛了）	經過參數優化配置，可以做到零丟失	經過參數優化配置，消息可以做到零丟失
功能支持	mq領域的功能及其完備	基於erlang開發，所以併發能力很強，性能極好，延時很低	mq功能較爲完善，還是分佈式的，擴展性很好	功能比較簡單，主要支持簡單的mq功能，在大數據領域的實時計算以及日誌採集被大規模使用，
優劣勢總結	非常成熟，功能強大，在業內大量的公司以及項目中都有應用偶爾會有較低概率丟失消息而且現在社區以及國內應用都越來越少，官方社區現在對ActiveMQ 5.x維護越來越少，幾個月才發佈一個版本而且確實主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用	erlang語言開發，性能極其好，延時很低；吞吐量到萬級，MQ功能比較完備而且開源提供的管理界面非常棒，用起來很好用社區相對比較活躍，幾乎每個月都發布幾個版本分在國內一些互聯網公司近幾年用rabbitmq也比較多一些但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因爲他做的實現機制比較重而且erlang開發，國內有幾個公司有實力做erlang源碼級別的研究和定製？如果說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴於開源社區的快速維護和修復bug。而且rabbitmq集羣動態擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定製和掌控	接口簡單易用，而且畢竟在阿里大規模應用過，有阿里品牌保障日處理消息上百億之多，可以做到大規模吞吐，性能也非常好，分佈式擴展也很方便，社區維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支持複雜MQ業務場景而且一個很大的優勢在於，阿里出品都是java系的，我們可以自己閱讀源碼，定製自己公司的MQ，可以掌控社區活躍度相對較爲一般，不過也還可以，文檔相對來說簡單一些，然後接口這塊不是按照標準JMS規範走的有些系統要遷移需要修改大量代碼還有就是阿里出臺的技術，你得做好這個技術萬一被拋棄，社區黃掉的風險，那如果你們公司有技術實力我覺得用RocketMQ挺好的	kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分佈式可以任意擴展同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量而且kafka唯一的一點劣勢是有可能消息重複消費，那麼對數據準確性會造成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響可以忽略這個特性天然適合大數據實時計算以及日誌收集