ActiveMQ基本詳解與總結

• MQ簡介：
  　　MQ全稱為Message Queue, 訊息佇列（MQ）是一種應用程式對應用程式的通訊方法。應用程式通過寫和檢索出入列隊的針對應用程式的資料（訊息）來通訊，而無需專用連線來連結它們。訊息傳遞指的是程式之間通過在訊息中傳送資料進行通訊，而不是通過直接呼叫彼此來通訊，直接呼叫通常是用於諸如遠端過程呼叫的技術。排隊指的是應用程式通過佇列來通訊。佇列的使用除去了接收和傳送應用程式同時執行的要求。其中較為成熟的MQ產品有IBMWEBSPHERE MQ。
• MQ特點：
  　　MQ的消費-生產者模型的一個典型的代表，一端往訊息佇列中不斷的寫入訊息，而另一端則可以讀取或者訂閱佇列中的訊息。MQ和JMS類似，但不同的是JMS是SUN JAVA訊息中介軟體服務的一個標準和API定義，而MQ則是遵循了AMQP協議的具體實現和產品。
• 使用場景：
  　　在專案中，將一些無需即時返回且耗時的操作提取出來，進行了非同步處理，而這種非同步處理的方式大大的節省了伺服器的請求響應時間，從而提高了系統的吞吐量。
• JMS簡介：
  　　JMS即Java訊息服務（Java Message Service）應用程式介面是一個Java平臺中關於面向訊息中介軟體（MOM）的API，用於在兩個應用程式之間，或分散式系統中傳送訊息，進行非同步通訊。Java訊息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支援。
• 定義：
  　　JMS（Java Messaging Service）是Java平臺上有關面向訊息中介軟體(MOM)的技術規範，它便於訊息系統中的Java應用程式進行訊息交換,並且通過提供標準的產生、傳送、接收訊息的介面簡化企業應用的開發，翻譯為Java訊息服務。
• 簡介：
  　　JMS是一種與廠商無關的 API，用來訪問訊息收發系統訊息。它類似於JDBC(Java DatabaseConnectivity)：這裡，JDBC 是可以用來訪問許多不同關係資料庫的 API，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問訊息收發服務。許多廠商目前都支援JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這只是幾個例子。 JMS 使您能夠通過訊息收發服務（有時稱為訊息中介程式或路由器）從一個 JMS 客戶機向另一個JMS客戶機發送訊息。訊息是 JMS 中的一種型別物件，由兩部分組成：報頭和訊息主體。報頭由路由資訊以及有關該訊息的元資料組成。訊息主體則攜帶著應用程式的資料或有效負載。根據有效負載的型別來劃分，可以將訊息分為幾種型別，它們分別攜帶：簡單文字(TextMessage)、可序列化的物件 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負載的訊息 (Message)。
• JMS和MQ的關係：
  　　JMS是一個用於提供訊息服務的技術規範，它制定了在整個訊息服務提供過程中的所有資料結構和互動流程。而MQ則是訊息佇列服務，是面向訊息中介軟體（MOM）的最終實現，是真正的服務提供者；MQ的實現可以基於JMS，也可以基於其他規範或標準。
  支援JMS的開源MQ：
  目前選擇的最多的是ActiveMQ。
• ActiveMQ 是Apache出品，最流行的，能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
  主要特點：
  
  1. 多種語言和協議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire,Stomp REST,WSNotification,XMPP,AMQP
  2. 完全支援JMS1.1和J2EE 1.4規範 (持久化,XA訊息,事務)
  3. 對Spring的支援,ActiveMQ可以很容易內嵌到使用Spring的系統裡面去,而且也支援Spring2.0的特性
  4. 通過了常見J2EE伺服器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何相容J2EE 1.4 商業伺服器上
  5. 支援多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
  6. 支援通過JDBC和journal提供高速的訊息持久化
  7. 從設計上保證了高效能的叢集,客戶端-伺服器,點對點
  8. 支援Ajax
  9. 支援與Axis的整合
  10. 可以很容易得呼叫內嵌JMS provider,進行測試
  11. ActiveMQ速度非常快；一般要比jbossMQ快10倍。
• 優點：
  　　是一個快速的開源訊息元件(框架)，支援叢集，同等網路，自動檢測，TCP，SSL，廣播，持久化，XA，和J2EE1.4容器無縫結合，並且支援輕量級容器和大多數跨語言客戶端上的Java虛擬機器。訊息非同步接受，減少軟體多系統整合的耦合度。訊息可靠接收，確保訊息在中介軟體可靠儲存，多個訊息也可以組成原子事務。
• 缺點：
  　　ActiveMQ預設的配置效能偏低，需要優化配置，但是配置檔案複雜，ActiveMQ本身不提供管理工具；示例程式碼少；主頁上的文件看上去比較全面，但是缺乏一種有效的組織方式，文件只有片段，使用者很難由淺入深進行了解，二、文件整體的專業性太強。在研究階段可以通過查maillist、看Javadoc、分析原始碼來了解。
• ActiveMQ應用場景：
  1、 不同語言應用整合
  ActiveMQ 中介軟體用Java語言編寫，因此自然提供Java客戶端 API。但是ActiveMQ 也為C/C++、.NET、Perl、PHP、Python、Ruby 和一些其它語言提供客戶端。在你考慮如何整合不同平臺不同語言編寫應用的時候，ActiveMQ 擁有巨大優勢。在這樣的例子中，多種客戶端API通過ActiveMQ 傳送和接受訊息成為可能，無論使用的是什麼語言。此外，ActiveMQ 還提供交叉語言功能，該功能整合這種功能，無需使用遠端過程呼叫（RPC）確實是個優勢，因為訊息協助應用解耦。
  2、 作為RPC的替代
  使用RPC同步呼叫的應用十分普遍。假設大多數客戶端伺服器應用使用RPC，包括ATM、大多數WEB應用、信用卡系統、銷售點系統等等。儘管很多系統很成功，但是轉換使用非同步訊息可以帶來很多好處，而且也不會放棄響應保證。使用同步請求的系統在規模上有較大的限制，因為請求會被阻塞，從而導致整個系統變慢。如果使用非同步訊息替代，可以很容易增加額外的訊息接收者，使得訊息能被併發消耗，從而加快請求處理。當然，你的系統應用間應該是解耦的。
  3、 應用之間解耦
  正如之前討論的，緊耦合架構可以導致很多問題，尤其是如果他們是分佈的。鬆耦合架構，在另一方面，證實了更少的依賴性，能夠更好地處理不可預見的改變。不僅可以在系統中改變元件而不影響整個系統，而且元件互動也相當的簡單。相比使用同步的系統（呼叫者必須等待被呼叫者返回資訊），非同步系統（呼叫方傳送訊息後就不管，即fire-and-forget）能夠給我們帶來事件驅動架構（event-driven architecture EDA）。
  4、 作為事件驅動架構的主幹
  解耦，非同步架構的系統允許通過代理器自己配置更多的客戶端，記憶體等（即vertical scalability）來擴大系統，而不是增加更多的代理器（即horizontal scalability）。考慮如亞馬遜這樣繁忙的電子商務系統。當用戶購買物品，事實上系統需要很多步驟去處理，包括下單，建立發票，付款，執行訂單，運輸等。但是使用者下單後，會立即返回“謝謝你下單”的介面。不只是沒有延遲，而且使用者還會受到一封郵件表明訂單已經收到。在亞馬遜下單的例子就是一個多步處理的例子。每一步都由單獨的服務去處理。當用戶下單是，有一個同步的體積表單動作，但整個處理流程並不通過瀏覽器同步處理。相反地，訂單馬上被接受和反饋。而剩下的步驟就通過非同步處理。如果在處理過程中出錯，使用者會通過郵件收到通知。這樣的非同步處理能提供高負載和高可用性。
  5、 提高系統擴充套件性
  很多使用事件驅動設計的系統是為了獲得高可擴充套件性，例如電子商務，政府，製造業，線上遊戲等。通過非同步訊息分開商業處理步驟給各個應用，能夠帶來很多可能性。考慮設計一個應用來完成一項特殊的任務。這就是面向服務的架構（service-oriented architecture SOA）。每一個服務完成一個功能並且只有一個功能。應用就通過服務組合起來，服務間使用非同步訊息和最終一致性。這樣的設計便可以引入一個複雜事件處理概念（complex event processing CEP）。使用CEP，部件間的互動可以被記錄追蹤。在非同步訊息系統中，可以很容易在部件間增加一層處理。
  　　
• 個人理解總結：
  activeMQ是什麼？
  　　是Apache公司旗下的一個訊息匯流排
  ActiveMQ是一個開源相容Java Message Service (JMS) 1.1面向訊息的中件間. 來自Apache Software Foundation. ActiveMQ提供鬆耦合的應用程式架構.
  activeMQ能幹什麼？
  　　用來在服務與服務之間進行非同步通訊的

• activeMQ優勢
  1.流量肖鋒
  2.任務非同步處理
  特點：可以解耦合
  　　(學習新技術的三要素：是什麼？能幹什麼？有什麼優勢？)

  　圖1：
  

• 通訊模式：
  1.點對點(queue)
  》一個訊息只能被一個服務接收
  》訊息一旦被消費，就會消失
  》如果沒有被消費，就會一直等待，直到被消費
  》多個服務監聽同一個消費空間，先到先得
  詳解：這個特點的原理是這樣的，在activeMQ

• 2.釋出/訂閱模式(topic)
  　　》一個訊息可以被多個服務接收
  　　》訂閱一個主題的消費者，只能消費自它訂閱之後釋出的訊息。
  　　》消費端如果在生產端傳送訊息之後啟動，是接收不到訊息的，除非生產端對訊息進行了持久化(例如廣播，只有當時聽到的人能聽到資訊)

  　　圖2：
  　　

注：訊息是被推送和拉取的(訊息生產端和消費端)，不是mq伺服器去主動傳送的
- 總：一些簡單常用的應用場景
1.傳送郵件
詳解：
　　最經典的就是當用戶註冊時，我們就需要用activeMQ來做為中介軟體，當用戶註冊後，我門把使用者的郵箱號和驗證碼等資訊通過activeMQ的生產端傳送到activeMQ的訊息佇列中，而一旦訊息佇列中出現了資料，我們的郵件模組通過實時的監控activeMQ的訊息佇列就能通過消費端獲取到這個資料，染回郵件模組就會自行的去對資料進行解析，給使用者傳送郵件
2.傳送簡訊
詳解：
　　原理同傳送郵件相同
3.同步索引庫
詳解：
　　為了緩解資料庫的壓力，我們把經常被呼叫的資料放入索引庫中，當有請求查詢時，我們會先去查詢索引庫，如果索引庫內有資料，那麼我們就不用就資料庫進行查詢，這樣就能大大的減輕伺服器的壓力，可是隨之而來的一個問題是，假如我們伺服器內的資料已經發生了改變，而瀏覽使用者查詢資料時，因為索引庫中已經有資料了，那麼這樣一來資料庫與索引庫的資料就不一致了，那麼怎麼解決這個問題呢？我們想到了通過用activeMQ來監聽資料庫的操作來實現資料庫與索引庫的資料同步，當後臺管理員或房產經紀人對資料庫的資料進行了增刪改的操作時，我們通過activeMQ監聽到了資料的改變，獲取到被修改的資料的id，然後在另一個服務模組中通過這個資料的id去資料庫先查詢一把，然後根據查詢結果進行判斷，再去做索引庫的資料同步。打個比方，如果查詢結果返回的是空，就說明商品已經被刪除，那麼我們就可以根據資料的id去把索引庫中的資料也一併刪除了。
4.同步靜態頁面
詳解：
　　此原理同上一個同步索引庫是一個原理，目的都是為了減緩伺服器的壓力，我們經過資料分析發現，其實我們的一些商品詳情頁面的資料其實都是大同小異的，完全可以通過freemarker頁面靜態化的模組加上後臺查詢出的資料拼裝成一個靜態頁面，而這些資料從哪來呢？我們經過討論和研究，最後一致認為還是放在緩衝中比較好，這樣一來就能大大的減輕了資料 庫的壓力，而另一個好處是，由於頁面是純靜態頁面，所以頁面上的資料都是死資料，這樣一來就不用像JSP動態頁面那樣需要和後臺資料庫有大量的資料互動，可以最大化的降低伺服器的壓力，其實這個技術已經有很多大型公司在使用了，比如淘寶，京東，網易等，我們要是細心一些就會發現，他們的頁面其實就都是HTML格式的靜態頁面。

訊息中介軟體的主要功能是訊息的路由(Routing)和快取(Buffering)。在AMQP中提供類似功能的兩種域模型：Exchange 和 Message queue。

訊息佇列-推/拉模式學習 & ActiveMQ及JMS學習