JMS 之 Active MQ 消息存儲

一、消息的存儲方式

ActiveMQ支持JMS規範中的持久化消息與非持久化消息

• 持久化消息通常用於不管是否消費者在線，它們都會保證消息會被消費者消費。當消息被確認消費後，會從存儲中刪除
• 非持久化消息通常用於發送通知以及實時數據，通常要求性能優先，消息可靠性並不是必須的情況
• MQ支持可插拔式的消息存儲，如：內存、文件和關係資料庫等方式

Queue消息模型在ActiveMQ的存儲

採用存儲採用先進先出（FIFO），一個消息只能被一個消費者消費，當消息被確認消費之後才會被刪除。

Topic消息模型（針對持久訂閱） 每個訂閱者獲取的消息實際是消息的一個副本，只有一個消息副本會被存儲，MQ提供了一個指針來指向消息存儲並且分發消息副本到訂閱者，消息直到所有的持久化訂閱者都被接收才能被刪除。

持久化存儲方式：

1. KahaDB消息存儲
2. AMQ消息存儲
3. JDBC消息存儲
4. 內存消息存儲

二、KahaDB存儲方式

KahaDB是從ActiveMQ 5.4開始默認的持久化插件。KahaDb恢復時間遠遠小於其前身AMQ並且使用更少的數據文件，所以可以完全代替AMQ，kahaDB的持久化機制同樣是基於日誌文件，索引和緩存。

（一）、KahaDB主要特性：

1. 日誌形式存儲消息；
2. 消息索引以B-Tree結構存儲，可以快速更新；
3. 完全支持JMS事務；
4. 支持多種恢復機制；

（二）、適用場景：

1. 高吞吐量的應用程序
2. 存儲大數據量的消息

（三）、配置方式 conf/activemq.xml：

（四）、KahaDB存儲原理：

當有活動消費者時，用於臨時存儲，消息會被發送給消費著，同時被安排將被存儲，如果消息及時被確認，就不需要寫入到磁碟。寫入到磁碟中的數據消息，在後續的消息活動中，如果消息發送成功，變標記為可刪除的。系統會周期性的清除或者歸檔日誌文件。

1、KahaDB內部結構

Data logs：消息日誌包含了消息日誌和一些命令

Cache：當有活動消費者時，用於臨時存儲，消息會被發送給消費著，同時被安排將被存儲，如果消息及時被確認，這不需要寫入到磁碟

Btree indexes（消息索引）：用於引用消息日誌（message id），它存儲在內存中，這樣能快速定位到。MQ會定期將內存中的消息索引保存到metadata store中，避免大量消息未發送時，消息索引佔用過多內存空間。

Redo log用於在非正常關機情況下維護索引完整性。

2、目錄結構：

Db log files：用於存儲消息（默認大小32M），當log日誌滿了，會創建一個新的，當log日誌中的消息都被刪除，該日誌文件會被刪除或者歸檔。

Archive directory：當datalog不在被kahadb需要會被歸檔（通過archiveDataLogs屬性控制）。

Db.data：存放Btree indexs。

Db.redo：存放redo file，用於恢復Btree indexs。

寫入消息時，會將消息寫入日誌文件，由於是順序追加寫，性能很高。為了提升性能，創建消息主鍵索引，並且提供緩存機制，進一步提升性能。每個日誌文件的大小都是有限制的（默認32m，可自行配置）。當超過這個大小，系統會重新建立一個文件。當所有的消息都消費完成，系統會刪除這個文件或者歸檔（取決於配置）。主要的缺點是AMQ Message會為每一個Destination創建一個索引，如果使用了大量的Queue，索引文件的大小會佔用很多磁碟空間。而且由於索引巨大，一旦Broker崩潰，重建索引的速度會非常慢。

特點：類似KahaDB，也包含了事務日誌，每個destination都包含一個index文件，AMQ適用於高吞吐量的應用場景，但是不適合多個隊列的場景。

配置方式conf/activemq.xml：

1、AMQ內部結構：

Data logs：消息日誌包含了消息日誌

Cache：用於消息的快速檢索

Reference store indexes：用於引用datalogs中的消息，通過message ID 關聯

2、目錄結構：

Lock：保證同一時間只有一個borker訪問文件目錄

temp-storag：用於存儲非持久化消息（當不在被存儲在內存中），如等待慢消費者處理消息

Kr-store：用於存儲引用消息日誌數據

journal directory：包含了消息文件、消息日誌和消息控制信息

Archive：歸檔的數據日誌

支持通過JDBC將消息存儲到關係資料庫，性能上不如文件存儲，能通過關係型資料庫查詢到消息的信息。

MQ支持的資料庫：Apache Derby、MYsql、PostgreSQL、Oracle、SQLServer、Sybase、Informix、MaxDB。

存儲表結構：

A、ACTIVEMQ_MSGS：用於存儲消息，Queue和Topic都存儲在這個表中：

• ID：自增的資料庫主鍵
• CONTAINER：消息的Destination
• MSGID_PROD：消息發送者客戶端的主鍵
• MSG_SEQ：是發送消息的順序，MSGID_PROD+MSG_SEQ可以組成JMS的MessageID
• EXPIRATION：消息的過期時間，存儲的是從1970-01-01到現在的毫秒數
• MSG：消息本體的Java序列化對象的二進位數據
• PRIORITY：優先順序，從0-9，數值越大優先順序越高

B、ACTIVEMQ_ACKS：用於存儲訂閱關係。如果是持久化Topic，訂閱者和伺服器的訂閱關係在這個表保存：

• 主要的資料庫欄位如下：
• CONTAINER：消息的Destination
• SUB_DEST：如果是使用Static集群，這個欄位會有集群其他系統的信息
• CLIENT_ID：每個訂閱者都必須有一個唯一的客戶端ID用以區分
• SUB_NAME：訂閱者名稱
• SELECTOR：選擇器，可以選擇只消費滿足條件的消息。條件可以用自定義屬性實現，可支持多屬性AND和OR操作
• LAST_ACKED_ID：記錄消費過的消息的ID。

C、ACTIVEMQ_LOCK（消息鎖，保證同一時間只能有一個broker訪問這些表結構）： 表activemq_lock在集群環境中才有用，只有一個Broker可以獲得消息，稱為Master Broker，其他的只能作為備份等待Master Broker不可用，才可能成為下一個Master Broker。這個表用於記錄哪個Broker是當前的Master Broker。

配置方式：

1、配置數據源 conf/acticvemq.xml文件：

2、配置broke中的persistenceAdapter ：

dataSource指定持久化資料庫的bean，createTablesOnStartup是否在啟動的時候創建數據表，默認值是true，這樣每次啟動都會去創建數據表了，一般是第一次啟動的時候設置為true，之後改成false。

ps：資料庫activemq 需要手動創建。

內存消息存儲，會將所有的持久化消息存儲在內存中，必須注意JVM使用情況以及內存限制，適用於一些能快速消費的數據量不大的小消息，當MQ關閉或者宕機，未被消費的內存消息會被清空。

配置方式 設置 broker屬性值 persistent="false"：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！