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