關於JMS和MQ

2.1 什麼是JMS？

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

2.2 什麼是消息模型

○ Point-to-Point(P2P) --- 點對點 ○ Publish/Subscribe(Pub/Sub)---  發佈訂閱

即點對點和發佈訂閱模型

2.2.1 P2P (點對點)

一、P2P

二、涉及到的概念 

 

1. 1. 消息隊列（Queue）
   2. 發送者(Sender)
   3. 接收者(Receiver)
   4. 每一個消息都被髮送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，直到他們被消費或超時。

 三、P2P的特色

     

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

若是你但願發送的每一個消息都應該被成功處理的話，那麼你須要P2P模式。

      

應用場景

A用戶與B用戶發送消息

 

2.2.2Pub/Sub (發佈與訂閱)

     Pub/Sub模式圖 

   

 

涉及到的概念 

主題（Topic）

發佈者（Publisher）

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

Pub/Sub的特色

每一個消息能夠有多個消費者

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

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

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

消息的消費 
在JMS中，消息的產生和消息是異步的。對於消費來講，JMS的消息者能夠經過兩種方式來消費消息。 
○ 同步 
訂閱者或接收者調用receive方法來接收消息，receive方法在可以接收到消息以前（或超時以前）將一直阻塞 
○ 異步 
訂閱者或接收者能夠註冊爲一個消息監聽器。當消息到達以後，系統自動調用監聽器的onMessage方法。

 

發佈訂閱模式：

消息容器 相似隊列

隊列裏面存放多個消息，消息容器裏面能夠存放多個隊列

原則： 先進先出原則

 生產者 消費者  消息容器

消費者和消息容器創建長連接   一旦生產者發佈消息後   推送退給 消費者（監聽）

 

 

上圖中： 容器中能夠存放多個隊列，一個隊列裏面存放多個消息。

   原則：先進先出，後進後出

   消息：生產者與消費者之間傳遞數據 

 

 

若是消費者宕機了，消息會丟失嗎？

不會的。緣由消息存在隊列裏面的。隊列中存放消息，若是消費者沒有及時消費的話，都會存放在消息隊列中。

 

消息中間件能夠解決高併發問題，流量削鋒問題，若是生產者上產一萬個消息，消費者每次只能一千個消息消費。

 

 整個過程屬於異步方式的。

 

  

一、生產者發送一條消息到queue，只有一個消費者能收到     （一對一模式）

二、客戶端包括生產者和消費者 隊列中的消息只能被一個消息消費者消費

     消息消費者能夠隨時消費隊列中的消息

   

一、發佈者發送套tipic的消息，只有訂閱了topic的訂閱者纔會收到消息

1 特性： 

    客戶端暴扣發佈者和訂閱者

   主題中的消息被全部訂閱者消費

    消費者不能消費訂閱以前就發送到主題中的消息 

 

 發佈訂閱和點對點通信方式的卻別：

 點對點  只能保證一個消費者進行消費

 發佈訂閱 只要集羣服務訂閱該主題都會收到消息 一對多

 

下次隊列指的是生產者與消費者傳遞數據  

  隊列裏存放消息集合

 

消息中間件包括 消息隊列 和 發佈訂閱

 

 

 

應用場景:

   用戶註冊、訂單修改庫存、日誌存儲

   畫圖演示

 

 

 

 

 

異步處理

 場景說明：用戶註冊後，須要發註冊右鍵和註冊短信。傳統的作法兩種：

    一、串行方式    將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。串行方式： 一步一步走  是同步的過程  單線程的  

    二、並行方式   將信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。完成任務後，返回給客戶端，與串行的區別是，並行方式能夠提升處理的時間

    二、引入消息隊列。將不是必須的業務邏輯異步處理。用戶響應時間至關因而註冊信息寫入數據庫的時間，也就是50毫秒。註冊郵件發送短信寫入消息隊列後，直接返回。所以寫入消息隊列的速度很快，基本能夠忽略，所以用戶的響應時間多是50毫秒。系統的吞吐量提升到每秒20 QPS，比串行提升了3倍，比並行提升了2倍。

    

將發送郵件、短信內容以MQ異步進行消費

 

這樣提升程序效率

若是消費者發送短信或者郵件消費失敗的話，MQ自帶重合和補償機制。

 

耗時間的接口 統一採用MQ推送  不建議使用激光同步方式

 

消息隊列應用場景 流量削峯的使用

 流量削峯是消息隊列彙總的經常使用場景，通常再秒殺或者團搶活動中使用

   秒殺活動，通常回應爲流量過大，致使流量暴增，應用掛掉。爲解決這個問題，通常須要再應用其那段加入消息隊列。

一、控制活動人數

二、緩解短期內流量壓垮應用

 

用戶的請求，服務器接受後，首先寫入消息隊列。加入消息隊列長度超過最大數量，則直接拋棄用戶請求或者跳轉錯誤頁面

秒殺業務根據消息隊列中的請求信息，在作後續處理

 

秒殺：  Redis+MQ+服務保護機制（服務降級、隔離、熔斷）+服務限流+圖像驗證碼+token