JMS訊息服務介紹

一、JMS訊息服務介紹
什麼是JMS:
Java 訊息服務（Java Message Service）, Java平臺中關於面向訊息中介軟體的介面
JMS是一種與廠商無關的API, 用來訪問訊息收發系統訊息，它類似於JDBC(Java Database Connectivity). 這裡，JDBC是可以用來訪問許多不同關聯式資料庫的API
使用場景：
核心應用：
解耦： 訂單系統——> 物流系統
非同步： 使用者註冊——> 傳送郵件，初始化資訊
削峰： 秒殺、日誌處理
跨平臺、多語言
分散式事務、最終一致性
RPC 呼叫上下游對接，資料來源變動 ——> 通知下級
二、訊息中介軟體常見概念和程式設計模型
常見概念
JMX 提供者： 連線面向訊息中介軟體的，JMS介面的一個實現，RocketMQ、RabbitMQ、ActiveMQ、Kafka 等
JMS 生產者（Message Producer）： 生產訊息的服務
JMS 消費者（Message Consumer）: 消費訊息的服務
JMS 訊息： 資料物件
JMS 佇列： 儲存消費訊息的區域
JMS 主題： 一種支援傳送訊息給多個訂閱者的機制
JMS 訊息通常有兩種型別： 點對點（Point-to-Point）、釋出/訂閱（Publish/Subscribe）
基礎程式設計模型
MQ 中需要一些常用的類
ConnectionFactory: 連線工廠，JMS 用它建立連線
Connection: JMS 客戶端到JMS Provider 的連線
Session: 一個傳送或接收訊息的執行緒
Destination: 訊息的目的地， 訊息傳送給誰
MessageConsumer/MessageProducer: 訊息消費者，訊息生產者
三、主流訊息佇列和技術選型
對比當下主流的訊息佇列和選擇問題
主流訊息佇列和技術選型
訊息佇列的模型:

Producer：生產訊息，將訊息寫入 channel。
Message Broker：訊息代理，將寫入 channel 的訊息按佇列的結構進行管理，負責儲存/轉發訊息。Broker 一般是需要單獨搭建、配置的叢集，而且必須是高可用的。
Consumer：訊息的消費者。目前大多數的訊息佇列都是保證訊息至少被消費一次，所以根據使用的訊息佇列設施不同，消費者要做好冪等。
Apache AcitveMQ、 Kafka、 RabbitMQ、 RocketMQ

ActiveMQ：http://activemq.apache.org/

Apache出品，歷史悠久，支援多種語言的客戶端和協議，支援多種語言Java, .NET, C++ 等，基於JMS Provider的實現
缺點：
吞吐量不高，多佇列的時候效能下降，存在訊息丟失的情況，比較少大規模使用
官方社群現在對ActiveMQ 5.x維護越來越少
Kafka：http://kafka.apache.org/

是由Apache 軟體基金會開發的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分散式訂閱訊息系統，它可以處理大規模的網站中的所有動作流資料（網頁瀏覽，搜尋和其他使用者的行動），副本集機制，實現資料冗餘，保障資料儘量不丟失；支援多個生產者和消費者
高吞吐量的特點，可以用於日誌手機、離線分析、試試分析等
以時間複雜度為 O(1) 的方式快速訊息持久化
支援線上水平擴充套件，自帶負載均衡
支援只消費且僅消費一次（Exactly Once）模式等
Kafka 官方提供了 Java 版本的客戶端 API，Kafka 社群目前也支援多種語言，包括 PHP、Python、Go、C/C++、Ruby、NodeJS 等
缺點：
Kafka 單機超過64個佇列/分割槽, Load會發生明顯的飆高現象、佇列越多、load 越高、傳送訊息響應時間變長
使用段輪詢方式， 實時性取決於輪詢間隔時間
管理介面雞肋， 可以使用 kafka-manager , kafka-eagle
不支援批量和廣播訊息，運維難度大，文件比較少，需要掌握Scala
RabbitMQ：http://www.rabbitmq.com/

是一個開源的AMQP實現，伺服器端用Erlang語言編寫，支援多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、用於在分散式系統中儲存轉發訊息，在易用性、擴充套件性、高可用性等方面表現不錯
健壯、穩定、文件齊全
社群活躍度高
缺點：
使用Erlang開發，閱讀和修改原始碼難度大， 不利於做二次開發和維護
RabbitMQ 吞吐量會低一些，這是因為它做的實現機制比較重
需要學習比較複雜的介面和協議，學習和維護成本較高。
RocketMQ：http://rocketmq.apache.org/

阿里開源的一款訊息中介軟體，純Java開發，具有高吞吐量、高可用性、適合大規模分散式系統應用的特點， 效能強勁（零拷貝技術），支援海量堆積，支援指定次數和時間間隔的失敗訊息重發，支援Consumer 端tag過濾、延遲訊息等， 在阿里內度進行大規模使用，適合在電商，網際網路金融等領域使用
缺點：
支援的客戶端語言不多，目前是java及c++，其中c++不成熟；
社群活躍度一般
沒有在 mq 核心中去實現JMS等介面，有些系統要遷移需要修改大量程式碼
四、阿里巴巴開源RocketMQ4.x訊息佇列介紹
阿里開源訊息佇列 RocketMQ4.x介紹和新概念講解
Apache RocketMQ 作為阿里開源的一款高效能、高吞吐量的分散式中介軟體

特點：

支援Broker 和 Consumer 端訊息過濾
支援釋出訂閱模型、點對點
支援拉Pull 和 推Push兩種訊息模式
單一佇列百萬訊息、億級訊息堆積
支援單master 節點，多master節點，多master多slave節點
任意一點都是高可用，水平擴充，Producer、Consumer、佇列都可以分散式
訊息失敗重試機制、支援特定level的定時訊息
新版本底層採用Netty
4.3.X 支援分散式事務
適合金融類業務，高可用性跟蹤和審計功能
概念

Producer: 訊息生產者
Producer Group: 訊息生產者組， 傳送同類訊息的一個訊息生產組
Consumer: 訊息者
Consumer Group: 消費同類訊息的多個例項
Tag: 標籤， 子主題（二級分類）對topic的進一步細化，用於區分同一個主題的不同業務的訊息
Topic: 主題，如訂單類訊息，queue 是訊息的物理管理單位，而topic是邏輯管理單位。 一個topic下可以有多個queue。 預設自動建立是4個，手動建立是8個
Message: 訊息， 每個message 必須指定一個topic
Broker: MQ 程式， 接收生產的訊息，提供給消費者消費的程式
Namer Server: 給生產和消費提供路由資訊，提供輕量級的服務發現、路由、後設資料資訊，可以多個部署，互相獨立（比Zookeeper更輕量）
Offset: 偏移量， 可以理解為訊息進度
commit log: 訊息儲存會寫在Commit log檔案裡面
官網地址：

http://rocketmq.apache.org/
參考資料：

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/
https://www.jianshu.com/p/453c6e7ff81c
--------------------- 
原文：https://blog.csdn.net/fxbin123/article/details/89324035