ActiveMQ( 一) 同步，異步，阻塞 JMS 消息模型

同步請求：瀏覽器 向服務器 發送一個登陸請求,若是服務器 沒有及時響應，則瀏覽器則會一直等待狀態，直至服務器響應或者超時。

異步請求：瀏覽器 向服務器 發送一個登陸請求,無論服務器是否當即響應，瀏覽器不須要等待。

 在java中,在多線程的狀況，也有同步，異步 阻塞的說法，多線程的狀況，加了同步關鍵字synchronized之後，當一個線程正在執行一個方法的時候，其他線程想要執行該方法則須要等待當前正在執行的線程 執行完之後，這個過程其餘線程就是阻塞狀態。

同步請求，瀏覽器--->服務器，若是服務器有延遲，則 瀏覽器 會一直等待，等待服務器的響應或者Http超時，若是在一些實際項目中，例如，A 項目調用B 項目，同步請求，B 因爲網絡緣由或者說查詢數據庫過慢，致使 A 項目調用超時，則可能A 會重複提交。

同步請求的缺點：超時，阻塞，數據可能重複提交

以上 能夠看出：

在客戶端與服務器進行通信時.客戶端調用後，必須等待服務對象完成處理返回結果才能繼續執行。客戶端與服務器對象的生命週期緊密耦合,客戶端進程和服務對象進程都都必須正常運行;若是因爲服務對象崩潰或者網絡故障致使用戶的請求不可達,客戶端會受到異常

在這種狀況下，可使用消息中間件

什麼是消息中間件：

發送者將消息發送給消息服務器，消息服務器將消息存放到隊列中，在合適的時候再將消息轉發給接收者，發送者將消息發送給隊列的時候，不須要關注接收者是否接受消息，也不須要等待接收者的響應，接收者處理消息的時候，一樣也不須要關注 發送者是否正常運行。這種模式下，發送和接收是異步的，發送者無需等（異步通信）

消息中間件的通信方式：JMS 

JMS是java的消息服務，JMS的客戶端之間能夠經過JMS服務進行異步的消息傳輸。

JMS有兩種消息模型：點對點 和點對多（發佈訂閱）

  點對點消息模型

   生產者：向隊列發送消息的一方（提供接口）

   消費者：向隊列獲取消息的一方（調用接口）

   消息隊列：存放消息的地方（能夠作持久化）

生產者向消息隊列發送消息，若是消費者在，則從消息隊列獲取消息消費，消費成功之後，該消息在隊列中清除，若是消費者不在，生產者生成的消息則會緩存到到隊列之中 ,根據這個特性，能夠知道中間件能夠解決高併發，對消息 緩存排隊，在高併發的狀況下，大量的消息會緩存到隊列中，消費者能夠根據本身的須要選擇一次性消費多少條數據，而不是直接將全部的消息 直接發送給消費者。

點對點模型特色：

 

1. 每一個消息只有一個消費者(即一旦被消費，消息就再也不在消息隊列中)
2. 發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息以後，無論接收者有沒有正在運行，它不會影響到消息被髮送到隊列
3. 接收者在成功接收消息以後需向隊列應答成功

 因此若是但願發送的每一個消息都應該被成功處理的話

 

 

在點對點中 一個消息只能被一個消費者消費，一旦消費成功，該消息就從隊列中清除，若是不清除，則可能出現重複消費的狀況

  點對多 (發佈與訂閱)

  發佈者：

    主題：

 訂閱者：

 

客戶端將消息發送到主題。多個發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

點對多特色：

1 .發佈者發佈到主題的消息能夠被多個訂閱者訂閱消費

發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱者以後，才能消費發佈者的消息，並且爲了消費消息，訂閱者必須保持運行的狀態。

爲了緩和這樣嚴格的時間相關性，JMS容許訂閱者建立一個可持久化的訂閱。這樣，即便訂閱者沒有被激活（運行），它也能接收到發佈者的消息。

若是你但願發送的消息能夠不被作任何處理、或者被一個消息者處理、或者能夠被多個消費者處理的話，那麼能夠採用點對多模型

在JMS中，消息的產生和消息是異步的。對於消費來講，JMS的消息者能夠經過兩種方式來消費消息。 

○ 同步 
訂閱者或接收者調用receive方法來接收消息，receive方法在可以接收到消息以前（或超時以前）將一直阻塞 
○ 異步 
訂閱者或接收者能夠註冊爲一個消息監聽器。當消息到達以後，系統自動調用監聽器的onMessage方法。

能夠理解成廣播，或者電視的場景