01---JMS與消息中間件的基本概念

JMS消息服務介紹和使用場景

什麼是JMS

JMS : Java Message Service(Java消息服務),Java平臺中關於面向消息中間件的介面. 重點在於介面,介面就意味著與JDBC類似,僅僅有聲明,沒有實現,具體的實現交給廠商. 介面本身是一種與廠商無關的API.

使用場景

每一種技術都有其產生的原因和解決的問題,消息服務的使用場景如下:

• 核心應用:
  • 解耦: 訂單 --> 物流 (降低工程間的強依賴程度)
  • 非同步: 用戶註冊 --> 發送郵件,初始化信息 (耗時長非必須的業務抽離,放在空閑的時候處理)
  • 流量削峰: 秒殺,日誌處理 (針對突發情況的大訪問量場景)
• 跨平臺, 多語言
• 分散式事務, 最終一致性 (引入和分散式和微服務之後,事務的處理和數據的一致是比較難保證的一個方面)
• RPC調用上下游對接,數據源變動通知下屬

消息中間件常見概念與編程模型

常見概念

• JMS提供者: 連接面向消息中間件的,也就是JMS的介面實現, RocketMQ, ActiveMQ等. 簡單的來說就是JMS介面的實現廠商提供的實現, 中間件本身.
• Broker伺服器: 接收生產消息,提供給消費者消費的程式
• JMS生產者(Message Producer): 生產消息的服務
• JMS消費者(Message Consumer): 消費消息的服務
• JMS消息: 數據對象, 傳遞的內容
• JMS隊列: 存儲待消費信息的區域(可以簡單的理解為數據結構中的隊列,可以保證順序,存儲消息的介質)
• JMS主題(Topic): 一種支持發送消息給多個訂閱者的機制(中轉,不同的生產者發送消息到主題,經過伺服器分發到不同的訂閱者)
• JMS消息通常的兩種類型: 點對點(Point-to-Point), 發佈/訂閱(Publish/Subscribe). 區別在於前者是多個消費者但只有一個消費者可以消費消息,後者是多個消費者都可以同時消費一個消息.

一個消息對應一個主題,一個主題下由多個queue. 要註意的是topic是一個邏輯管理單位,queue是物理管理單位

我是這麼理解的: Producer發送Message到Broker,Topic在Broker內, Queue在Topic內, Message經過Broker發送給Consumer

基礎編程模型

• MQ中需要用到的一些類
  • ConnectionFactory: 連接工廠, JMS使用它來創建連接
  • Connection: JMS客戶端到JMS Provider的連接
  • Session: 一個發送或接收消息的線程
  • Destination: 消息的目的地; 消息發送給誰(Broker)
  • MessageConsumer / MessageProducer: 消息消費者 / 消息生產者

主流消息隊列與選型

對比

• ActiveMQ: http://activemq.apache.org/
  • 支持多種語言的客戶端和協議,基於JMS Provider的實現,容易上手. 但是吞吐量不高,多隊列的時候性能會下降,存在消息丟失情況.
• Kafka: http://kafka.apache.org/
  • 由Scala和Java編寫,可以處理大規模的網站中的所有動作流數據(網頁瀏覽,搜索等),保證數據儘量不丟失,適用於大數據領域(電商等). 但是不支持批量個廣播消息,運維難度大,文檔少,需要掌握Scala
• RabbitMQ: http://www.rabbitmq.com/
  • 開源的AMQP實現,服務端用Erlang語言編寫,支持多種客戶端,在易用性,擴展性和高可用性等方面表現不錯. 但是使用Erlang語言開發,閱讀和修改源碼難度大.(當然公司如果大部分人熟悉Erlang語言的話例外)
• RocketMQ: http://rocketmq.apache.org/
  • 阿裡開源的一款消息中間件,純java開發,具有高吞吐量,高可用性,是和大規模分散式系統應用的特點,性能強勁(零拷貝技術),支持海量堆積,支持指定次數和時間間隔的失敗消息重發,支持consumer端tag過濾,延遲消息等,是和電商,金融等領域. 但是也正是因為太強大了,所以不是很容易上手.

還有更多的瞭解參考: http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/ 和 https://www.jianshu.com/p/453c6e7ff81c