WildFly消息子系統深度評估：HornetQ核心特性與企業級應用指南

WildFly（原JBoss AS，V8+更名）整合HornetQ作為消息子系統。HornetQ完全支援JMS 1.1，並定義自有Core Client API極致性能與靈活性。

Core Client API參考：官方文檔

消息類型：點對點與發布訂閱

完全對齊JMS兩大模型：

• Point-to-Point：佇列模式，單一消費者
• Publish/Subscribe：主題模式，多消費者廣播

核心術語：Acceptors/Connectors與Invm/Netty

Acceptors與Connectors：連接雙向定義

• Acceptor：Server端接受何種連接
• Connector：Client端連接Server方式

配置於standalone/domain profile中：

<connectors>
    <netty-connector name="netty" socket-binding="messaging" />
    <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
        <param key="batch-delay" value="50" />
    </netty-connector>
    <servlet-connector name="servlet" socket-binding="http" host="default-host" />
    <in-vm-connector name="in-vm" server-id="0" />
</connectors>
<acceptors>
    <netty-acceptor name="netty" socket-binding="messaging" />
    <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
        <param key="batch-delay" value="50" />
        <param key="direct-deliver" value="false" />
    </netty-acceptor>
    <in-vm-acceptor name="in-vm" server-id="0" />
</acceptors>

Invm與Netty：JVM邊界判斷

• Invm：Client與Server同一JVM（進程內通信）
• Netty：跨JVM網絡通信

成對定義：Invm Acceptor對應Invm Connector，Netty同理。

消息持久化：預設AIO、支援多模式

預設持久化至文件（Persistent Journal），兩種文件操作：

• Java NIO：標準非阻塞IO，需Java SE 6+
• Linux AIO：本地異步IO庫，強依賴Linux 2.6+內核，性能優於NIO

預設使用AIO，無AIO環境自動降級NIO。

支援三種部署模式：

1. 本地文件系統（單機）
2. NFS網絡文件系統
3. 基於SAN的GFS V2共享文件系統

注意：模式2/3僅支援AIO。模式1做HA需配置消息復制（主從同步日誌）。

作者觀點：持久化方式單一（無資料庫選項），但NFS/GFS共享避免復制性能損耗。極高負載場景建議引入Infinispan緩存集群做消息共享增強HA。

消息復制：HA前提功能

集群環境主從節點狀態對等，主失效從即時接管。模式2/3共享存儲天然一致；模式1需復制。

注意：從節點啟動時同步現有數據，同步完成前無容錯能力。

消息去重：業務幂等性保障

兩類故障場景導致重複發送：

1. 發送後、到達前故障
2. 處理完、響應前故障

發送端無法區分，統一重發。訂單系統若無去重將導致重複下單。

HornetQ去重原理：

1. 發送端附加唯一ID（建議UUID）於消息頭
2. 目標服務器收訊前查本地緩存Duplicate ID Cache
3. 存在則忽略，不存在則處理並緩存ID

作者觀點：極端情況（緩存崩潰）仍可能重複。實際業務（訂單/積分/支付/物流）一般不考慮極端場景，淘寶Notify/MetaQ同策略。建議分布式緩存（Terracotta BigMemory、Oracle Coherence）統一管理Duplicate ID，節點崩潰亦不重複消費。

嚴格消息順序保證：Message Grouping

電商場景：訂購iPad→加入佇列→取消訂購→加入佇列。若消費順序顛倒，取消失效。

JMS 2.0僅規範「單生產者、單佇列、單消費者」順序一致，分布式環境無強制要求。IBM MQ消息分組、WebLogic Unit-of-Order、HornetQMessage Grouping均提供解決方案。

Message Grouping機制

同業務類型消息分組，確保同組消息由同一消費者順序消費（即使集群環境）。

前提條件：

• 佇列內消息順序正確（發送端需保證時序）
• 消費端禁用多線程處理
• 集群負載均衡可能分散同組消息至不同佇列，需修改演算法（類似Sticky Session）導向同一Server/Destination

參考資源：WildFly評估之消息子系統