2.1 什么是JMS？
JMS是Java的消息服務，JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。
2.2 什么是消息模型
| ○ Point-to-Point(P2P) --- 點對點 ○ Publish/Subscribe(Pub/Sub)--- 發布訂閱 |
即點對點和發布訂閱模型
2.2.1 P2P (點對點)
1、P2P
2、涉及到的概念
-
- 消息隊列（Queue）
- 發送者(Sender)
- 接收者(Receiver)
- 每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，直到他們被消費或超時。
3、P2P的特點
- 每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
- 發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之后，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列
- 接收者在成功接收消息之后需向隊列應答成功
如果你希望發送的每個消息都應該被成功處理的話，那么你需要P2P模式。
應用場景
A用戶與B用戶發送消息
2.2.2Pub/Sub (發布與訂閱)
Pub/Sub模式圖
涉及到的概念
主題（Topic）
發布者（Publisher）
訂閱者（Subscriber）
客戶端將消息發送到主題。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
Pub/Sub的特點
每個消息可以有多個消費者
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之后，才能消費發布者的消息，而且為了消費消息，訂閱者必須保持運行的狀態。
為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。
如果你希望發送的消息可以不被做任何處理、或者被一個消息者處理、或者可以被多個消費者處理的話，那么可以采用Pub/Sub模型
消息的消費
在JMS中，消息的產生和消息是異步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。
○ 同步
訂閱者或接收者調用receive方法來接收消息，receive方法在能夠接收到消息之前（或超時之前）將一直阻塞
○ 異步
訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之后，系統自動調用監聽器的onMessage方法。
發布訂閱模式：
消息容器 類似隊列
隊列里面存放多個消息，消息容器里面可以存放多個隊列
原則： 先進先出原則
生產者 消費者 消息容器
消費者和消息容器建立長鏈接 一旦生產者發布消息后 推送退給 消費者（監聽）
上圖中： 容器中可以存放多個隊列，一個隊列里面存放多個消息。
原則：先進先出，后進后出
消息：生產者與消費者之間傳遞數據
如果消費者宕機了，消息會丟失嗎？
不會的。原因消息存在隊列里面的。隊列中存放消息，如果消費者沒有及時消費的話，都會存放在消息隊列中。
消息中間件可以解決高並發問題，流量削鋒問題，如果生產者上產一萬個消息，消費者每次只能一千個消息消費。
整個過程屬於異步方式的。
1、生產者發送一條消息到queue，只有一個消費者能收到 （一對一模式）
2、客戶端包括生產者和消費者 隊列中的消息只能被一個消息消費者消費
消息消費者可以隨時消費隊列中的消息
1、發布者發送套tipic的消息，只有訂閱了topic的訂閱者才會收到消息
1 特性：
客戶端暴扣發布者和訂閱者
主題中的消息被所有訂閱者消費
消費者不能消費訂閱之前就發送到主題中的消息
發布訂閱和點對點通訊方式的卻別：
點對點 只能保證一個消費者進行消費
發布訂閱 只要集群服務訂閱該主題都會收到消息 一對多
下次隊列指的是生產者與消費者傳遞數據
隊列里存放消息集合
消息中間件包括 消息隊列 和 發布訂閱
應用場景:
用戶注冊、訂單修改庫存、日志存儲
畫圖演示
異步處理
場景說明：用戶注冊后，需要發注冊右鍵和注冊短信。傳統的做法兩種：
1、串行方式 將注冊信息寫入數據庫成功后，發送注冊郵件，再發送注冊短信。串行方式： 一步一步走 是同步的過程 單線程的
2、並行方式 將信息寫入數據庫成功后，發送注冊郵件的同時，發送注冊短信。完成任務后，返回給客戶端，與串行的區別是，並行方式可以提高處理的時間
2、引入消息隊列。將不是必須的業務邏輯異步處理。用戶響應時間相當於是注冊信息寫入數據庫的時間，也就是50毫秒。注冊郵件發送短信寫入消息隊列后，直接返回。因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。系統的吞吐量提高到每秒20 QPS，比串行提高了3倍，比並行提高了2倍。
將發送郵件、短信內容以MQ異步進行消費
這樣提高程序效率
如果消費者發送短信或者郵件消費失敗的話，MQ自帶重合和補償機制。
耗時間的接口 統一采用MQ推送 不建議使用激光同步方式
消息隊列應用場景 流量削峰的使用
流量削峰是消息隊列匯總的常用場景，一般再秒殺或者團搶活動中使用
秒殺活動，一般回應為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要再應用其那段加入消息隊列。
1、控制活動人數
2、緩解短時間內流量壓垮應用
用戶的請求，服務器接受后，首先寫入消息隊列。加入消息隊列長度超過最大數量，則直接拋棄用戶請求或者跳轉錯誤頁面
秒殺業務根據消息隊列中的請求信息，在做后續處理
秒殺： Redis+MQ+服務保護機制（服務降級、隔離、熔斷）+服務限流+圖像驗證碼+token