Java Message Service (JMS) 核心概念與兩大消息模型深度解析

前言：企業級異步通訊的標準

JMS (Java Message Service) 是 Java EE 標準化的訊息中介軟體 API，解決異構系統間可靠、異步、鬆耦合通訊問題。支援 Point-to-Point (P2P) 與 Publish/Subscribe (Pub/Sub) 兩大模型，廣泛用於訂單處理、通知推送、日誌收集、微服務事件驅動等場景。

一、JMS 核心架構組件

二、兩大消息模型詳細對比

1. Point-to-Point (P2P) — Queue

• 語義：一條訊息只被一個消費者處理（負載均衡）。
• 儲存：訊息持久化於 Queue，消費者離線時訊息保留，上線後收取。
• 適用場景：任務分發、命令下發、訂單處理、任何「必須被處理一次」的業務。
• 確認機制：消費者處理完畢後確認（ACK），未 ACK 會重發。

2. Publish/Subscribe (Pub/Sub) — Topic

• 語義：一條訊息廣播給所有訂閱者（一對多）。
• 非持久訂閱：訂閱者必須在線才能收到，離線期間訊息丟失。
• 持久訂閱：createDurableSubscriber(topic, "subName")，訂閱者離線時訊息保留，重新連線時收取。
• 適用場景：事件通知、股價推送、系統廣播、日誌收集、允許「錯過訊息」的業務。

模型選擇決策表

三、關鍵進階特性

1. 訊息確認模式

• AUTO_ACKNOWLEDGE：Session 自動確認（預設，效能最好，可能重複/丟失）。
• CLIENT_ACKNOWLEDGE：客戶端手動調用 message.acknowledge()（精確控制，效能稍低）。
• DUPS_OK_ACKNOWLEDGE：懶惰確認，允許重複（高吞吐、容忍重複）。
• SESSION_TRANSACTED：事務性 Session，commit()/rollback() 原子確認。

2. 訊息持久化

• DeliveryMode.PERSISTENT：訊息寫入磁碟/資料庫，Broker 重啟不丟失（預設）。
• DeliveryMode.NON_PERSISTENT：僅記憶體，高吞吐低延遲，Broker 重啟丟失。
• 代碼：producer.send(msg, DeliveryMode.PERSISTENT, priority, timeToLive);

3. 優先級 (0-9)

• 0-4：普通優先級；5-9：加急優先級。Broker 應盡力優先投遞高優先級，但不保證嚴格順序。
• 代碼：publisher.publish(msg, DeliveryMode.PERSISTENT, 8, 10000); (優先級 8，TTL 10秒)

4. 訊息選擇器

SQL92 風格過濾：consumer = session.createConsumer(queue, "orderType='VIP' AND amount > 1000");，Broker 端過濾，減少網路傳輸。

四、最佳實踐與避坑

1. Connection/Session/Producer/Consumer 重用：建立成本高，應用生命週期內共用，執行緒安全需注意（Session 非執行緒安全）。
2. 關閉資源順序：Consumer → Producer → Session → Connection。
3. 異常處理：實作 ExceptionListener 監聽連線斷開，觸發重連邏輯。
4. 大訊息處理：超過 Broker 限制（通常 1-2MB）需分塊或用外部存儲（S3/資料庫）傳引用。
5. 事務邊界：業務邏輯與訊息確認在同一事務，避免「業務成功但訊息未確認」導致重複處理。

五、現代替代方案

• JMS 2.0 (Java EE 7+)：簡化 API，支援 JMSContext、CompletionListener、@JMSListener 註解驅動。
• Spring JMS：JmsTemplate、@JmsListener、自動重連、錯誤處理器。
• 現代訊息中介軟體：Apache Kafka (高吞吐日誌)、RabbitMQ (靈活路由)、RocketMQ (事務訊息)、Pulsar (多租戶)、NATS (輕量)。JMS 仍是標準介面，多數 Broker 支援 JMS 協議。

結語

JMS 以標準化 API 屏蔽了底層 Broker 差異，掌握 P2P 與 Pub/Sub 兩大模型、確認機制、持久化、優先級、選擇器等核心概念，即可設計出高可靠、鬆耦合的企業級異步系統。