要呼叫mq服務之前要先啟動mq官網專案
生產者消費者模式（點對點訊息）
訂閱者生產者模式（點對多訊息）
點對點是發布訊息佇列 createqueue
點對多是發布訂閱 createtopic（要先訂閱才能收到訊息consumer(消費者)）先啟動消費者
以下介紹訊息佇列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和訊息通訊四個場景。
場景說明：使用者註冊後，需要發註冊郵件和註冊簡訊。傳統的做法有兩種1.序列的方式；2.並行方式。
（1）序列方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件，再傳送註冊簡訊。以上三個任務全部完成後，返回給客戶端。
（2）並行方式：將註冊資訊寫入資料庫成功後，傳送註冊郵件的同時，傳送註冊簡訊。以上三個任務完成後，返回給客戶端。與序列的差別是，並行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鐘，不考慮網路等其他開銷，則序列方式的時間是150毫秒，並行的時間可能是100毫秒。
因為cpu在單位時間內處理的請求數是一定的，假設cpu1秒內吞吐量是100次。則序列方式1秒內cpu可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。
小結：如以上案例描述，傳統的方式系統的效能（併發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
引入訊息佇列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：
按照以上約定，使用者的響應時間相當於是註冊資訊寫入資料庫的時間，也就是50毫秒。註冊郵件，傳送簡訊寫入訊息佇列後，直接返回，因此寫入訊息佇列的速度很快，基本可以忽略，因此使用者的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 qps。比序列提高了3倍，比並行提高了兩倍。
場景說明：使用者下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統呼叫庫存系統的介面。如下圖：
傳統模式的缺點：
1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；
2） 訂單系統與庫存系統耦合；
如何解決以上問題呢？引入應用訊息佇列後的方案，如下圖：
· 訂單系統：使用者下單後，訂單系統完成持久化處理，將訊息寫入訊息佇列，返回使用者訂單下單成功。
· 庫存系統：訂閱下單的訊息，採用拉/推的方式，獲取下單資訊，庫存系統根據下單資訊，進行庫存操作。
· 假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入訊息佇列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
流量削鋒也是訊息佇列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入訊息佇列。
1. 可以控制活動的人數；
2. 可以緩解短時間內高流量壓垮應用；
1. 使用者的請求，伺服器接收後，首先寫入訊息佇列。假如訊息佇列長度超過最大數量，則直接拋棄使用者請求或跳轉到錯誤頁面；
2. 秒殺業務根據訊息佇列中的請求資訊，再做後續處理。
ActiveMQ 核心概念
1.failover 當a無法為客戶服務時，系統能夠自動地切換，使b能夠及時地頂上繼續為客戶提供服務，且客戶感覺不到這個為他提供服務的物件已經更換。如資料庫 應用服務 硬體裝置等的失效轉移。2.stomp streaming text orientated message protocol 流文字定...
ActiveMQ學習教程（二） 概念解釋
這一節對jms api中的一些重要概念進行一下說明。jms api的主要概念如一下 本節只列出提綱，詳細說明，請檢視附件。下面對兩種jms domains進行一下說明 1.publish subscribe 在這種模式下，mq伺服器中的客戶端可訂閱自己感興趣的topic，當其它客戶端向mq伺服器傳送...
ActiveMQ入門 ActiveMQ環境搭建
解壓縮就能用，執行bin資料夾下面的可執行檔案 cd users szz downloads apache activemq 5.15.9 bin macosx macosx activemq startstarting activemq broker.可以開啟它的管理介面http localhos...