發佈-訂閱消息模式 一、訂閱雜誌 我們很多人都訂過雜誌，其過程很簡單。只要告訴郵局我們所要訂的雜誌名、投遞的地址，付了錢就OK。出版社定期會將出版的雜誌交給郵局，郵局會根據訂閱的列表，將雜誌送達消費者手中。這樣我們就可以看到每一期精彩的雜誌了。 發佈-訂閱消息模式 一、訂閱雜誌 我們很多人都訂過雜誌 ...
發佈-訂閱消息模式
一、訂閱雜誌
我們很多人都訂過雜誌，其過程很簡單。只要告訴郵局我們所要訂的雜誌名、投遞的地址，付了錢就OK。出版社定期會將出版的雜誌交給郵局，郵局會根據訂閱的列表，將雜誌送達消費者手中。這樣我們就可以看到每一期精彩的雜誌了。
仔細思考一下訂雜誌的過程，我們會發現這樣幾個特點：1、消費者訂雜誌不需要直接找出版社；2、出版社只需要把雜誌交給郵局；3、郵局將雜誌送達消費者。郵局在整個過程中扮演了非常重要的中轉作用，在出版社和消費者相互不需要知道對方的情況下，郵局完成了雜誌的投遞。
二、發佈-訂閱消息模式
剛剛講了訂閱雜誌，下麵我們會講傳統調用模式演化到發佈-訂閱消息模式。
有些網站在註冊用戶成功後發一封激活郵件，用戶收到郵件後點擊激活鏈接後才能使用該網站。一般的做法是在註冊用戶業務邏輯中調用發送郵件的邏輯。這 樣用戶業務就依賴於郵件業務。如果以後改為簡訊激活，註冊用戶業務邏輯就必須修改為調用發送簡訊的邏輯。如果要註冊後給用戶加點積分，再加一段邏輯。經過 多次修改，我們發現很簡單的註冊用戶業務已經越來越複雜，越來越難以維護。相信很多開發者都會有類似痛苦的經歷。
即使用戶業務實現中對其他業務是介面依賴，也避免不了業務變化帶來的依賴影響。怎麼辦？解耦！將註冊用戶業務邏輯中註冊成功後的處理剝離出來。再回頭看看"訂閱雜誌"，如果沒有郵局，出版社就必須自己將雜誌送達所有消費者。這種情形就和現在的註冊用戶業務一樣。我們發現問題了，在用戶業務和其他業務之間缺少了郵局所扮角色。
我們把郵局抽象成一個管理消息的地方，叫"消息管理器"。註冊用戶成功後發送一個消息給消息管理器，由消息管理器轉發該消息給需要處理的業務。現在，用戶業務只依賴於消息管理器了，它再也不會為了註冊用戶成功後的其他處理而煩惱。
註冊用戶的改造就是借鑒了"訂閱雜誌"這樣原始的模式。我們再進一步抽象，用戶業務就是消息的"生產者"，它將消息發佈到消息管理器。郵件業務就是 消息的"消費者"，它將收到的消息進行處理。郵局可以訂閱很多種雜誌，雜誌都是通過某種編號來區分；消息管理器也可以管理多種消息，每種消息都會有一個 "主題"來區分，消費者都是通過主題來訂閱的。
發佈-訂閱消息模式已經呈現在我們面前，利用它可以產生更靈活、更鬆散耦合的系統。
MQ相關概念
1.消息(Message)
消息是MQ中最小的概念，本質上就是一段數據，它能被一個或者多個應用程式所理解，是應用程式之間傳遞的信息載體。
2.隊列(Queue）
2.1本地隊列
本地隊列按照功能可劃分為初始化隊列，傳輸隊列，目標隊列和死信隊列。
初始化隊列用作消息觸發功能。
傳輸隊列只是暫存待傳的消息，條件許可的情況下，通過管道將消息傳送到其他的隊列管理器。
目標隊列是消息的目的地，可以長期存放消息。
如果消息不能送達目標隊列，也不能再路由出去，則被自動放入死信隊列保存。
2.2別名隊列&遠程隊列
只是一個隊列定義，用來指定遠端隊列管理器的隊列。使用了遠程隊列，程式就不需要知道目標隊列的位置。
2.3模型隊列
模型隊列定義了一套本地隊列的屬性結合，一旦打開模型隊列，隊列管理器會按照這些屬性動態地創建出一個本地隊列。
3.隊列管理器(Queue Manager)
隊列管理器是一個負責嚮應用程式提供消息服務的機構，如果把隊列管理器比作資料庫，那麼隊列就是其中一張表。
4.通道(Channel)
通道是兩個管理器之間的一種單向點對點的的通信連接，如果需要雙向交流，可以建立一對通道。
5.監聽器(listner)
MQ產品的特性
可靠性傳輸
這個特點可以說是消息中間件的立足之本，對於應用來說，只要成功把數據提交給消息中間件，那麼關於數據可靠傳輸的問題就由消息中間件來負責。
不重覆傳輸
不重覆傳播也就是斷點續傳的功能，特別適合網路不穩定的環境，節約網路資源。
非同步性傳輸
非同步性傳輸是指，接受信息雙方不必同時線上，具有離線能力和安全性。
消息驅動
接到消息後主動通知消息接收方。
支持事務
應用程式可以把一些數據更新組合成一個工作單元，這些更新通常是邏輯相關的，為了保障數據完整性，所有的更新必須同時成功或者同時失敗）。
