消息隊列-ActiveMQ

1 業務需求描述

舉例描述：

再警情通報的業務時經過發送消息界面能夠選擇

警情聯絡，和船情通報兩種消息

發送方式可分爲

一對一發送：部門對部門、我的對我的

一對多發送：部門對多部門、我的對多人

2 功能實現設計

基於上述需求描述，在消息傳輸功能實現上選用activemq進行警情聯絡消息傳輸功能的實現。

1. 基礎概念

ActiveMQ：是Apache出品，最流行的，能力強勁的開源消息總線。是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現。

JMS（Java消息服務）：是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。

2. JMS消息模式

1) 點對點或隊列模式

每一個消息只能有一個消費者。消息的生產者和消費者之間沒有時間上的相關性，不管消費者在生產者發送消息的時候是否處於運行狀態，它均可以提取消息。

2) Pub/Sub 發佈/訂閱模式

每一個消息能夠有多個消費者。生產者和消費者之間有時間上的相關性。訂閱一個主題的消費者只能消費自它訂閱以後發佈的消息。

（基於咱們的需求選用pub/sub）

3. Broker節點

表明一個運行MQ的節點。

4. Transport傳輸方式

ActiveMQ目前支持的Transport有：VM Transport、TCP Transport、NIO Transport、SSL Transport、Peer Transport、UDP Transport、Multicast Transport、HTTP and HTTPS Transport、WebSockets Transport、Failover Transport、Fanout Transport、Discovery Transport、ZeroConf Transport等。

1) VM Transport：容許客戶端和Broker直接在VM內部通訊，採用的鏈接不是Socket鏈接，而是直接的方法調用，從而避免了網絡傳輸的開銷。應用場景也僅限於Broker和客戶端在同一JVM環境下。

2) TCP Transport：客戶端經過TCP Socket鏈接到遠程Broker。配置語法：

tcp://hostname:port?transportOptions

3) HTTP and HTTPS Transport：容許客戶端使用REST或者Ajax的方式進行鏈接。這意味着能夠直接使用Javascript向ActiveMQ發送消息。

4) WebSockets Transport：容許客戶端經過HTML5標準的WebSockets方式鏈接到Broker。

5) Failover Transport：青龍系統MQ採用的就是這種鏈接方式。這種方式具有自動從新鏈接的機制，工做在其餘Transport的上層，用於創建可靠的傳輸。容許配置任意多個的URI，該機制將會自動選擇其中的一個URI來嘗試鏈接。配置語法：

failover:(tcp://localhost:61616,tcp://localhost:61617,.....)?transportOptions

6) Fanout Transport：主要適用於生產消息發向多個代理。若是多個代理出現環路，可能形成消費者接收重複的消息。因此，使用該協議時，最好將消息發送給多個不相鏈接的代理。

5. Persistence持久化存儲

1) AMQ Message Store

ActiveMQ 5.0 的缺省持久化存儲方式。

2) Kaha Persistence

這是一個專門針對消息持久化的解決方案。它對典型的消息使用模式進行了優化。

3) JDBC Persistence

目前支持的數據庫有：Apache Derby, Axion, DB2, HSQL, Informix, MaxDB, MySQL, Oracle, Postgresql, SQLServer, Sybase。

4) Disable Persistence

不該用持久化存儲。

6. 集羣方案

1. Master / Slave

1.1. Pure Master Slave

無單點故障；

不須要依賴共享文件系統或是共享數據庫，使用 KahaDB的方式持久化存儲；

一個Master只能帶一個Slave；

Master工做期間，會將消息情況自動同步到Slave；

Master一旦崩潰，Slave自動接替其工做，已發送並還沒有消費的消息繼續有效；

Slave接手後，必須中止Slave才能重啓先前的Master；

1.2. Shared File System Master Slave

1.3. JDBC Master Slave

配置上，不存在Master和Slave的區分，多個共享數據源的Broker構成JDBC Master Slave；

首先搶到資源（數據庫鎖）的Broker成爲Master，其餘Broker按期嘗試搶佔資源；

一旦Master崩潰，其餘Broker搶佔資源，最終只有一臺搶到，馬上成爲Master，以前的Master即使重啓成功，也只能做爲Slave等待；