中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載
39套Java架構師/高級課/微服務/高併發/高性能/性能調優/電商緩存/併發編程/虛擬機視頻教程39套Java架構師，高併發，高性能，高可用，分佈式，集羣，電商，緩存，微服務，微信支付寶支付，公衆號開發，java8新特性，P2P金融項目，程序設計，功能設計，數據庫設計，第三方支付，web安全，性能調優，設計模式，數據結構，併發編程，虛擬機，中間件，數據庫，項目實戰，大型分佈式電商項目實戰視頻教程
視頻課程包含：
39套包含：架構師，高併發，高性能，高可用，高可擴展，分佈式，集羣，電商，緩存，微服務，微信支付寶支付，公衆號開發，java8新特性，P2P金融項目，程序設計，功能設計，數據庫設計，架構設計，web安全，性能調優，設計模式，數據結構，項目實戰，工作流，程序調優，負載均衡，Solr集羣與應用，主從複製，中間件，全文檢索，任務調度，jvm虛擬機，Spring boot，Spring cloud，Docker，Kubernetes，jvm，Dubbo，Elasticsearch，ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat，Spring，Git，Nosql，Mecached，Netty，Nio，Mina，Nutch，Webservice，Activiti，Shiro，Tomcat，Mysql，Oracle，Quartz，ELK Stack，zookeeper，Activiti大型分佈式電商實戰等高端視頻課程......
39套精品課程介紹：
1、39套精品是掌櫃最近整理出的最新課程，都是當下最火的技術，最火的課程，也是全網課程的精品；
2、39套資源包含：全套完整高清視頻、完整源碼、配套文檔；
3、知識也是需要投資的，有投入纔會有產出（保證投入產出比是幾百上千倍），如果有心的朋友會發現，身邊投資知識的大都是技術經理或者項目經理，工資一般相對於不投資的也要高出很多；
總目錄：39套Java架構師項目實戰高併發高性能高可用分佈式集羣緩存性能調優設計模式數據結構算法併發編程微服務架構虛擬機中間件數據庫微信支付公衆號大型電商視頻課程
第一套：【系統學習】高併發大型電商詳情頁系統的大型高性能與高可用緩存架構實戰視頻教程
第二套：【項目實戰】4套Spring Boot基礎到精通，實戰與原理分析，微服務架構應用視頻課程
第01套.Spring boot入門到精通視頻課程
第02套.SpringBoot全套教程2018年更新
第03套.SpringBoot微服務架構應用
第04套.Spring Boot實戰與原理分析視頻課程
第三套：【微服務課】Spring Cloud微服務最新技術入門到精通視頻教程
第四套：【微服務課】5套Docker基本概念與架構，Docker構建微服務，Docker到Kubernetes之技術實戰視頻課程
第01套、Docker基本概念與架構
第02套、Docker雲計算與自動化實踐
第03套、Docker實戰系列課程
第04套、Docker構建微服務實戰
第05套：Docker到Kubernetes技術系列實戰視頻教程
第五套：【2套項目實戰】微信支付實戰，支付寶支付實戰，公衆號網頁支付實戰，web商城支付系列實戰視頻課程
第01套.【項目實戰】微信支付實戰視頻課程—公衆號網頁支付實戰（ Java版）
第02套.【項目實戰】支付寶即時到賬web商城支付系列實戰視頻課程 （Java版）
第六套：【項目實戰】微信二次開發實戰JAVA版，微信驗證，微信公衆平臺，智能客服，微信菜單定製，人臉識別系統視頻課程
第七套：【併發編程】Java高併發編程，線程安全深入解析，鎖原理，同步容器，實戰講解視頻教程
第八套：從無到有搭建中小型互聯網公司後臺服務架構與運維架構視頻課程
第九套：【系統學習】深入理解spring架構與原理從設計模式與原則理解Sring視頻課程
第十套：【項目實戰】設計模式綜合項目（實戰），設計模式綜合應用的實戰案例視頻教程
第十一套：【項目實戰】軟件系統功能設計（實戰）訓練（6個設計案例，真實項目功能需求）視頻教程
第十二套：【系統學習】Java數據結構和算法精講版（數組、棧、隊列、鏈表、遞歸、排序、二叉樹、紅黑樹、堆、哈希表）視頻課程
第十三套：【系統學習】Java虛擬機，深入JVM內核-原理，診斷與優化+內存模型+虛擬機原理
第十四套：【項目實戰】Java8新特性原理，高級進階實戰視頻教程
第十五套：深入Java程序性能調優視頻(阿姆達爾定律、緩存組件、並行開發、線程池、JVM調優)
第十六套：【系統學習】Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程
01.Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程-基礎篇
02.Elasticsearch基礎到深入，底層深入解析，結構化搜索，全文檢索高級案例實戰視頻課程-高級篇
第十七套：【中 間 件】3套ActiveMq，RocketMQ，RabbitMQ中間件架構，基礎到精通高級實戰視頻課程
01.【中 間 件】ActiveMq中間件基礎到精通高級實戰視頻課程
02.【中 間 件】JAVA-ACE架構師系列課程 Rocketmq
03.【中 間 件】RabbitMQ中間件基礎到精通，消息訂閱視頻課程
第十八套：【中 間 件】Kafka原理剖析及實戰演練
第十九套：【數 據 庫】4套Mysql，從小白到大神，數據庫查詢優化，大型分佈式集羣，數據庫運維視頻課程
01.【數據庫】Mysql從小白到大神
02.【數據庫】MySQL高級大型分佈式集羣，主從複製，負載均衡，數據庫中間件視頻課程
03.【數據庫】MySQL數據庫查詢優化
04.【數據庫】MySQL數據庫運維全套視頻教程 阿里巴巴DBA講授
第二十套：【數 據 庫】2套Oracle引航，深入，性能優化，高可用，海量數據庫設計視頻課程
01.【數據庫】oracle五部曲
02.【數據庫】Oracle性能優化視頻教程
第二十一套：【數 據 庫】Mycat從基礎到精通，分佈式數據庫中間件視頻課程
第二十二套：【3套項目實戰】Apache Shiro權限框架實戰Springboot與Shiro整合+項目案例+權限設計實現視頻課程
第03套.【項目實戰】Apache Shiro權限框架實戰+項目案例+權限設計實現視頻課程
第01套.SpringBoot與Shiro整合-權限管理實戰視頻
第02套.Shiro基礎到精通，原理與架構視頻課程
第二十三套：【系統學習】spring+quartz的分佈式任務調度及源碼解析視頻課程
第二十四套：【項目實戰】Dubbo分佈式系統架構-第三方支付項目的系統架構實戰視頻教程
第二十五套：【微服務課】基於支付系統場景的微服務架構的分佈式事務解決方案視頻課程
第二十七套：【項目實戰】日誌分析之ELK stack實戰視頻教程
第二十八套：【項目實戰】Zookeeper分佈式系統開發實戰視頻課程
第二十九套：【項目實戰】瘋狂講義Activiti6.X工作流進階與項目實戰，Activiti整合Drools視頻課程
第三十套：【項目實戰】P2P互聯網金融平臺項目SSM+Redis+Mysql+Bootstrap+JQuery視頻課程
第三十一套：【項目實戰】P2P網絡借貸平臺項目SSH+Redis+ActiveMQ+POI+Shiro+AngularJS+Nginx+Quartz視頻程
第三十三套：【項目實戰】大型分佈式電商系統redis+solr+Linux+nginx+springmvc+mybatis電商項目
第三十四套：【項目實戰】大型分佈式電商系統redis+solr+Linux+nginx+springmvc+mybatis電商項目
第三十五套：【架構師課】站在架構師的角度架構屬於自己的項目框架（ORM、MVC、IOC框架）視頻課程
第三十六套：【架構師課】架構師必備大規模高性能分佈式存儲系統設計與實現視頻課程
第三十七套：【架構師課】Java高級系統培訓架構師課程148課時（階段一）（maven+spring+mybatis+git+memcached+activemq+nginx+內存調優）
(01-07)Java架構師之Maven和Git課程
(08-30)Maven+Git+Spring+Mybatis+X-gen基本業務功能塊構建
(31-42)Java架構師之Ngnix入門到精通
(43-57)Java架構師之Varnish入門到精通部分
(58-70)Memcached+Nginx+Varnish內存調優緩存機制部分
(71-100)Java架構師之ActiveMQ消息存儲持久化+Spring+JMS+Queue隊列部分
(101-131)Java架構師之MongoDB入門到精通課程
(132-142)Java架構師之MogileFS部分+Nginx+Memcached的集成課程
(143-148)Nginx+Varnish+ActiveMQ階段小結和整體部署
第三十八套：【架構師課】Java高級系統培訓架構師課程116課時（階段二）（分佈式事物+單點登錄+高併發+性能優化+邏輯層處理+數據庫性能優化）
(1-23)、分佈式架構和部署部分
(24-50)、高併發和Web層的性能優化部分
(51-98)、邏輯層處理和性能優化部分
(99-110)、數據層處理和性能優化部分
(111-116)、數據庫性能優化
第三十九套：【架構師課】Java高級互聯網架構師系統培訓班課程（nginx+redis+zookeeper+activemq+storm+dubbo+netty+jvm+併發編程鎖+項目實戰）
高級互聯網架構師（源碼資料）
高級互聯網架構師（項目實戰）
4、如何保證消息隊列是高可用的？
分析:在第二點說過了，引入消息隊列後，系統的可用性下降。在生產中，沒人使用單機模式的消息隊列。因此，作爲一個合格的程序員，應該對消息隊列的高可用有很深刻的瞭解。如果面試的時候，面試官問，你們的消息中間件如何保證高可用的？你的回答只是表明自己只會訂閱和發佈消息，面試官就會懷疑你是不是隻是自己搭着玩，壓根沒在生產用過。請做一個愛思考，會思考，懂思考的程序員。
回答:這問題，其實要對消息隊列的集羣模式要有深刻了解，纔好回答。
以rcoketMQ爲例，他的集羣就有多master 模式、多master多slave異步複製模式、多 master多slave同步雙寫模式。多master多slave模式部署架構圖(網上找的,偷個懶，懶得畫):
其實博主第一眼看到這個圖，就覺得和kafka好像，只是NameServer集羣，在kafka中是用zookeeper代替，都是用來保存和發現master和slave用的。通信過程如下:
Producer 與 NameServer集羣中的其中一個節點（隨機選擇）建立長連接，定期從 NameServer 獲取 Topic 路由信息，並向提供 Topic 服務的 Broker Master 建立長連接，且定時向 Broker 發送心跳。Producer 只能將消息發送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave建立長連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。
那麼kafka呢,爲了對比說明直接上kafka的拓補架構圖(也是找的，懶得畫)
如上圖所示，一個典型的Kafka集羣中包含若干Producer（可以是web前端產生的Page View，或者是服務器日誌，系統CPU、Memory等），若干broker（Kafka支持水平擴展，一般broker數量越多，集羣吞吐率越高），若干Consumer Group，以及一個Zookeeper集羣。Kafka通過Zookeeper管理集羣配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將消息發佈到broker，Consumer使用pull模式從broker訂閱並消費消息。
至於rabbitMQ,也有普通集羣和鏡像集羣模式，自行去了解，比較簡單，兩小時即懂。
要求，在回答高可用的問題時，應該能邏輯清晰的畫出自己的MQ集羣架構或清晰的敘述出來。
5、如何保證消息不被重複消費？
分析:這個問題其實換一種問法就是，如何保證消息隊列的冪等性?這個問題可以認爲是消息隊列領域的基本問題。換句話來說，是在考察你的設計能力，這個問題的回答可以根據具體的業務場景來答，沒有固定的答案。
回答:先來說一下爲什麼會造成重複消費?
其實無論是那種消息隊列，造成重複消費原因其實都是類似的。正常情況下，消費者在消費消息時候，消費完畢後，會發送一個確認信息給消息隊列，消息隊列就知道該消息被消費了，就會將該消息從消息隊列中刪除。只是不同的消息隊列發送的確認信息形式不同,例如RabbitMQ是發送一個ACK確認消息，RocketMQ是返回一個CONSUME_SUCCESS成功標誌，kafka實際上有個offset的概念，簡單說一下(如果還不懂，出門找一個kafka入門到精通教程),就是每一個消息都有一個offset，kafka消費過消息後，需要提交offset，讓消息隊列知道自己已經消費過了。那造成重複消費的原因?，就是因爲網絡傳輸等等故障，確認信息沒有傳送到消息隊列，導致消息隊列不知道自己已經消費過該消息了，再次將該消息分發給其他的消費者。
如何解決?這個問題針對業務場景來答分以下幾點
(1)比如，你拿到這個消息做數據庫的insert操作。那就容易了，給這個消息做一個唯一主鍵，那麼就算出現重複消費的情況，就會導致主鍵衝突，避免數據庫出現髒數據。
(2)再比如，你拿到這個消息做redis的set的操作，那就容易了，不用解決，因爲你無論set幾次結果都是一樣的，set操作本來就算冪等操作。
(3)如果上面兩種情況還不行，上大招。準備一個第三方介質,來做消費記錄。以redis爲例，給消息分配一個全局id，只要消費過該消息，將<id,message>以K-V形式寫入redis。那消費者開始消費前，先去redis中查詢有沒消費記錄即可。
6、如何保證消費的可靠性傳輸?
分析:我們在使用消息隊列的過程中，應該做到消息不能多消費，也不能少消費。如果無法做到可靠性傳輸，可能給公司帶來千萬級別的財產損失。同樣的，如果可靠性傳輸在使用過程中，沒有考慮到，這不是給公司挖坑麼，你可以拍拍屁股走了，公司損失的錢，誰承擔。還是那句話，認真對待每一個項目，不要給公司挖坑。
回答:其實這個可靠性傳輸，每種MQ都要從三個角度來分析:生產者弄丟數據、消息隊列弄丟數據、消費者弄丟數據
RabbitMQ
(1)生產者丟數據
從生產者弄丟數據這個角度來看，RabbitMQ提供transaction和confirm模式來確保生產者不丟消息。
transaction機制就是說，發送消息前，開啓事物(channel.txSelect())，然後發送消息，如果發送過程中出現什麼異常，事物就會回滾(channel.txRollback())，如果發送成功則提交事物(channel.txCommit())。
然而缺點就是吞吐量下降了。因此，按照博主的經驗，生產上用confirm模式的居多。一旦channel進入confirm模式，所有在該信道上面發佈的消息都將會被指派一個唯一的ID(從1開始)，一旦消息被投遞到所有匹配的隊列之後，rabbitMQ就會發送一個Ack給生產者(包含消息的唯一ID)，這就使得生產者知道消息已經正確到達目的隊列了.如果rabiitMQ沒能處理該消息，則會發送一個Nack消息給你，你可以進行重試操作。處理Ack和Nack的代碼如下所示（說好不上代碼的，偷偷上了）:
channel.addConfirmListener(new ConfirmListener() {
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
System.out.println("nack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
System.out.println("ack: deliveryTag = "+deliveryTag+" multiple: "+multiple);
}
});
(2)消息隊列丟數據
處理消息隊列丟數據的情況，一般是開啓持久化磁盤的配置。這個持久化配置可以和confirm機制配合使用，你可以在消息持久化磁盤後，再給生產者發送一個Ack信號。這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那麼生產者收不到Ack信號，生產者會自動重發。
那麼如何持久化呢，這裏順便說一下吧，其實也很容易，就下面兩步
1、將queue的持久化標識durable設置爲true,則代表是一個持久的隊列
2、發送消息的時候將deliveryMode=2
這樣設置以後，rabbitMQ就算掛了，重啓後也能恢復數據
(3)消費者丟數據
消費者丟數據一般是因爲採用了自動確認消息模式。這種模式下，消費者會自動確認收到信息。這時rahbitMQ會立即將消息刪除，這種情況下如果消費者出現異常而沒能處理該消息，就會丟失該消息。
至於解決方案，採用手動確認消息即可。
kafka
這裏先引一張kafka Replication的數據流向圖
Producer在發佈消息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然後無論該Topic的Replication Factor爲多少（也即該Partition有多少個Replica），Producer只將該消息發送到該Partition的Leader。Leader會將該消息寫入其本地Log。每個Follower都從Leader中pull數據。
針對上述情況，得出如下分析
(1)生產者丟數據
在kafka生產中，基本都有一個leader和多個follwer。follwer會去同步leader的信息。因此，爲了避免生產者丟數據，做如下兩點配置
第一個配置要在producer端設置acks=all。這個配置保證了，follwer同步完成後，才認爲消息發送成功。
在producer端設置retries=MAX，一旦寫入失敗，這無限重試
(2)消息隊列丟數據
針對消息隊列丟數據的情況，無外乎就是，數據還沒同步，leader就掛了，這時zookpeer會將其他的follwer切換爲leader,那數據就丟失了。針對這種情況，應該做兩個配置。
replication.factor參數，這個值必須大於1，即要求每個partition必須有至少2個副本
min.insync.replicas參數，這個值必須大於1，這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯繫
這兩個配置加上上面生產者的配置聯合起來用，基本可確保kafka不丟數據
(3)消費者丟數據
這種情況一般是自動提交了offset，然後你處理程序過程中掛了。kafka以爲你處理好了。再強調一次offset是幹嘛的
offset：指的是kafka的topic中的每個消費組消費的下標。簡單的來說就是一條消息對應一個offset下標，每次消費數據的時候如果提交offset，那麼下次消費就會從提交的offset加一那裏開始消費。
比如一個topic中有100條數據，我消費了50條並且提交了，那麼此時的kafka服務端記錄提交的offset就是49(offset從0開始)，那麼下次消費的時候offset就從50開始消費。
解決方案也很簡單，改成手動提交即可。
ActiveMQ和RocketMQ
大家自行查閱吧
7、如何保證消息的順序性？
分析:其實並非所有的公司都有這種業務需求，但是還是對這個問題要有所複習。
回答:針對這個問題，通過某種算法，將需要保持先後順序的消息放到同一個消息隊列中(kafka中就是partition,rabbitMq中就是queue)。然後只用一個消費者去消費該隊列。
有的人會問:那如果爲了吞吐量，有多個消費者去消費怎麼辦？
這個問題，沒有固定回答的套路。比如我們有一個微博的操作，發微博、寫評論、刪除微博，這三個異步操作。如果是這樣一個業務場景，那隻要重試就行。比如你一個消費者先執行了寫評論的操作，但是這時候，微博都還沒發，寫評論一定是失敗的，等一段時間。等另一個消費者，先執行寫評論的操作後，再執行，就可以成功。
總之，針對這個問題，我的觀點是保證入隊有序就行，出隊以後的順序交給消費者自己去保證，沒有固定套路。
一、kafka
1、不完全符合jms規範，注重吞吐量，類似udp 和 tcp
2、一般做大數據吞吐的管道 我們現在的用途就是負責在各個idc之間通信
3、量大對數據不是百分之百保證的，會有數據丟失，不是百分百送達（amq和rmq等有重發機制，而kafka沒有）；在吞吐量有提升 ，在這方面就得有犧牲， 所以kafka適合大數據量流轉， 比如日誌數據 比如用作統計的數據。
二、activeMQ
ActiveMQ居於兩者之間，類似於ZemoMQ，它可以部署於代理模式和P2P模式。類似於RabbitMQ，它易於實現高級場景，而且只需付出低消耗。它被譽爲消息中間件的“瑞士×××”。
三、rabbitMQ
RabbitMQ是AMQP協議領先的一個實現，它實現了代理(Broker)架構，意味着消息在發送到客戶端之前可以在中央節點上排隊。此特性使得RabbitMQ易於使用和部署，適宜於很多場景如路由、負載均衡或消息持久化等，用消息隊列只需幾行代碼即可搞定。但是，這使得它的可擴展性差，速度較慢，因爲中央節點增加了延遲，消息封裝後也比較大。
四、zeroMQ
ZeroMQ是一個非常輕量級的消息系統，專門爲高吞吐量/低延遲的場景開發，在金融界的應用中經常可以發現它。與RabbitMQ相比，ZeroMQ支持許多高級消息場景，但是你必須實現ZeroMQ框架中的各個塊（比如Socket或Device等）。ZeroMQ非常靈活，但是你必須學習它的80頁的手冊（如果你要寫一個分佈式系統，一定要閱讀它）。
五、rocketMQ（阿里官方指定消息中間件）
RocketMQ 是一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。同時，廣泛應用於多個領域，包括異步通信解耦、企業解決方案、金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通信、移動應用、手遊、視頻、物聯網、車聯網等。
具有以下特點：
能夠保證嚴格的消息順序
提供豐富的消息拉取模式
高效的訂閱者水平擴展能力
實時的消息訂閱機制
億級消息堆積能力
總結
1、性能小量小用什麼都沒有關係，性質是一樣的，如果消息性能要求高，用rocketMQ與kafka可以更優，rocketMQ與kafka 比較就看技術選型了，各有利弊，看業務需要。
2、activeMQ、rabbitMQ與 kafka、rocketMQ有很大的區別就是前2個只支持主從模式，後2個是分佈式消息系統，支持分佈式。
3、持久化消息比較： zeroMq不支持，activeMq和rabbitMq都支持。
持久化消息主要是指：MQ down或者MQ所在的服務器down了，消息不會丟失的機制。
4、高併發
從實現語言來看，RabbitMQ最高，原因是它的實現語言是天生具備高併發高可用的erlang語言。RabbitMQ、activeM、zeroMQ三者中，綜合來看，RabbitMQ是首選。下面提供一篇文章，是淘寶使用RabbitMQ的心得，可以參看一些業務場景。
7、kafka和RabbitMQ的比較
1-RabbitMq比kafka成熟，在可用性上，穩定性上，可靠性上，RabbitMq超過kafka
2-Kafka設計的初衷就是處理日誌的，可以看做是一個日誌系統，針對性很強，所以它並沒有具備一個成熟MQ應該具備的特性
3-Kafka的性能（吞吐量、tps）比RabbitMq要強，這篇文章的作者認爲，兩者在這方面沒有可比性。
消息隊列
爲什麼寫這篇文章?
博主有兩位朋友分別是小A和小B:
小A，工作於傳統軟件行業(某社保局的軟件外包公司)，每天工作內容就是和產品聊聊需求，改改業務邏輯。再不然就是和運營聊聊天，寫幾個SQL，生成下報表。又或者接到客服的通知，某某功能故障了，改改數據，然後下班部署上線。每天過的都是這種生活，技術零成長。
小B，工作於某國企，雖然能接觸到一些中間件技術。然而，他只會訂閱/發佈消息。通俗點說，就是調調API。對爲什麼使用這些中間件啊？如何保證高可用啊？沒有充分的認識。
慶幸的是兩位朋友都很有上進心，於是博主寫這篇文章，幫助他們複習一下關於消息隊列中間件這塊的要點
複習要點
本文大概圍繞如下幾點進行闡述:
我們圍繞以上七點進行闡述。需要說明一下，本文不是《消息隊列從入門到精通》這種課程，因此只是提供一個複習思路，而不是去教你們怎麼調用消息隊列的API。建議對消息隊列不瞭解的人，去找點消息隊列的博客看看，再看本文，收穫更大
正文
1、爲什麼要使用消息隊列?
分析:一個用消息隊列的人，不知道爲啥用，這就有點尷尬。沒有複習這點，很容易被問蒙，然後就開始胡扯了。
回答:這個問題,咱只答三個最主要的應用場景(不可否認還有其他的，但是隻答三個主要的),即以下六個字:解耦、異步、削峯
(1)解耦
傳統模式:
傳統模式的缺點：
系統間耦合性太強，如上圖所示，系統A在代碼中直接調用系統B和系統C的代碼，如果將來D系統接入，系統A還需要修改代碼，過於麻煩！
中間件模式:
中間件模式的的優點：
將消息寫入消息隊列，需要消息的系統自己從消息隊列中訂閱，從而系統A不需要做任何修改。
(2)異步
傳統模式:
傳統模式的缺點：
一些非必要的業務邏輯以同步的方式運行，太耗費時間。
中間件模式:
中間件模式的的優點：
將消息寫入消息隊列，非必要的業務邏輯以異步的方式運行，加快響應速度
(3)削峯
傳統模式
傳統模式的缺點：
併發量大的時候，所有的請求直接懟到數據庫，造成數據庫連接異常
中間件模式:
中間件模式的的優點：
系統A慢慢的按照數據庫能處理的併發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峯期積壓是允許的。
2、使用了消息隊列會有什麼缺點?
分析:一個使用了MQ的項目，如果連這個問題都沒有考慮過，就把MQ引進去了，那就給自己的項目帶來了風險。我們引入一個技術，要對這個技術的弊端有充分的認識，才能做好預防。要記住，不要給公司挖坑！
回答:回答也很容易，從以下兩個個角度來答
系統可用性降低:你想啊，本來其他系統只要運行好好的，那你的系統就是正常的。現在你非要加個消息隊列進去，那消息隊列掛了，你的系統不是呵呵了。因此，系統可用性降低
系統複雜性增加:要多考慮很多方面的問題，比如一致性問題、如何保證消息不被重複消費，如何保證保證消息可靠傳輸。因此，需要考慮的東西更多，系統複雜性增大。
但是，我們該用還是要用的。
3、消息隊列如何選型?
先說一下，博主只會ActiveMQ,RabbitMQ,RocketMQ,Kafka，對什麼ZeroMQ等其他MQ沒啥理解，因此只能基於這四種MQ給出回答。
分析:既然在項目中用了MQ，肯定事先要對業界流行的MQ進行調研，如果連每種MQ的優缺點都沒了解清楚，就拍腦袋依據喜好，用了某種MQ，還是給項目挖坑。如果面試官問:"你爲什麼用這種MQ？。"你直接回答"領導決定的。"這種回答就很LOW了。還是那句話，不要給公司挖坑。
回答:首先，咱先上ActiveMQ的社區，看看該MQ的更新頻率:
Apache ActiveMQ 5.15.3 Release
Christopher L. Shannon posted on Feb 12, 2018
Apache ActiveMQ 5.15.2 Released
Christopher L. Shannon posted on Oct 23, 2017
Apache ActiveMQ 5.15.0 Released
Christopher L. Shannon posted on Jul 06, 2017
省略以下記錄
...
我們可以看出，ActiveMq幾個月才發一次版本，據說研究重心在他們的下一代產品Apollo。
接下來，我們再去RabbitMQ的社區去看一下,RabbitMQ的更新頻率
RabbitMQ 3.7.3 release 30 January 2018
RabbitMQ 3.6.15 release 17 January 2018
RabbitMQ 3.7.2 release23 December 2017
RabbitMQ 3.7.1 release21 December 2017
省略以下記錄
...
我們可以看出，RabbitMQ版本發佈比ActiveMq頻繁很多。至於RocketMQ和kafka就不帶大家看了，總之也比ActiveMQ活躍的多。詳情，可自行查閱。
再來一個性能對比表
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 開發語言 | java | erlang | java | scala |
| 單機吞吐量 | 萬級 | 萬級 | 10萬級 | 10萬級 |
| 時效性 | ms級 | us級 | ms級 | ms級以內 |
| 可用性 | 高(主從架構) | 高(主從架構) | 非常高(分佈式架構) | 非常高(分佈式架構) |
| 功能特性 | 成熟的產品，在很多公司得到應用；有較多的文檔；各種協議支持較好 | 基於erlang開發，所以併發能力很強，性能極其好，延時很低;管理界面較豐富 | MQ功能比較完備，擴展性佳 | 只支持主要的MQ功能，像一些消息查詢，消息回溯等功能沒有提供，畢竟是爲大數據準備的，在大數據領域應用廣。 |
綜合上面的材料得出以下兩點:
(1)中小型軟件公司，建議選RabbitMQ.一方面，erlang語言天生具備高併發的特性，而且他的管理界面用起來十分方便。正所謂，成也蕭何，敗也蕭何！他的弊端也在這裏，雖然RabbitMQ是開源的，然而國內有幾個能定製化開發erlang的程序員呢？所幸，RabbitMQ的社區十分活躍，可以解決開發過程中遇到的bug，這點對於中小型公司來說十分重要。不考慮rocketmq和kafka的原因是，一方面中小型軟件公司不如互聯網公司，數據量沒那麼大，選消息中間件，應首選功能比較完備的，所以kafka排除。不考慮rocketmq的原因是，rocketmq是阿里出品，如果阿里放棄維護rocketmq，中小型公司一般抽不出人來進行rocketmq的定製化開發，因此不推薦。
(2)大型軟件公司，根據具體使用在rocketMq和kafka之間二選一。一方面，大型軟件公司，具備足夠的資金搭建分佈式環境，也具備足夠大的數據量。針對rocketMQ,大型軟件公司也可以抽出人手對rocketMQ進行定製化開發，畢竟國內有能力改JAVA源碼的人，還是相當多的。至於kafka，根據業務場景選擇，如果有日誌採集功能，肯定是首選kafka了。具體該選哪個，看使用場景。
中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載中間件系列ActiveMQ，Rocketmq，Rabbitmq比較視頻教程網盤下載