柚子快報激活碼778899分享：ActiveMq學(xué)習(xí)⑧

http://yzkb.51969.com/

ActiveMQ的消息存儲和持久化

MQ的高可用

事務(wù)持久簽收可持久化 （類似于與mq消息的同步機(jī)制）

為了避免意外宕機(jī)以后丟失信息，需要做到重啟后可以恢復(fù)消息隊列，消息系統(tǒng)一半都會采用持久化機(jī)制。

ActiveMQ的消息持久化機(jī)制

ActiveMQ的消息持久化機(jī)制有

JDBCAMQKahaDBLevelDB無論使用哪種持久化方式，消息的存儲邏輯都是一致的。 邏輯

就是在發(fā)送者將消息發(fā)送出去后消息中心首先將消息存儲到本地數(shù)據(jù)文件、內(nèi)存數(shù)據(jù)庫或者遠(yuǎn)程數(shù)據(jù)庫等。再試圖將消息發(fā)給接收者成功則將消息從存儲中刪除，失敗則繼續(xù)嘗試嘗試發(fā)送。

消息中心啟動以后，要先檢查指定的存儲位置是否有未成功發(fā)送的消息，如果有，則會先把存儲位置中的消息發(fā)出去。

官網(wǎng)

ActiveMQ的消息持久化機(jī)制有哪些？

AMQ Message Store

基于文件的存儲方式，是以前的默認(rèn)消息存儲，現(xiàn)在不用了。具有寫入速度快和容易恢復(fù)的特點消息存儲在一個個文件中，文件默認(rèn)大小為32M，當(dāng)一個存儲文件中的消息已經(jīng)全部被消費，那么這個文件將被標(biāo)識為可刪除，在下一個清楚階段買這個文件可刪除AMQ適用于ActiveMQ5.3之前的版本 KahaDB (默認(rèn))

基于日志文件，從ActiveMQ5.4開始默認(rèn)的持久化插件，我們從配置文件 activemq.xml 中可以看到 KahaDB是一個基于文件的持久性數(shù)據(jù)庫，它是使用它的消息代理的本地數(shù)據(jù)庫。

db-.log 為 kahaDB 存儲消息的數(shù)據(jù)記錄文件，文件大小限定32M，大于32M就會遞增下一個數(shù)據(jù)文件，比如：log-2.log、log-3.log 以此類推。當(dāng)不再引用數(shù)據(jù)文件中的任何消息時，文件就會被刪除或歸檔。db.data 文件包含了持久化的 BTree 索引，是消息的索引文件，本質(zhì)上是 B-Tree 樹，使用 B-Tree 作為索引指向 db-.log 里面存儲的消息。 db.free 記錄 db.data 文件中哪些頁面是空閑的，后面建索引則優(yōu)先從空閑頁中創(chuàng)建。文件的具體內(nèi)容是所有空閑頁的IDdb.redo 用來進(jìn)行消息恢復(fù)，如果KahaDB消息存儲在強制退出后啟動，用于恢復(fù)BTree索引lock 文件為文件鎖，表示當(dāng)前獲得 kahaDB 讀寫權(quán)限的 broker 它已經(jīng)針對快速持久性進(jìn)行了優(yōu)化。它是自ActiveMQ 5.4以來的默認(rèn)存儲機(jī)制。KahaDB比其前身AMQ消息存儲使用更少的文件描述符，并提供更快的恢復(fù) LevelDB消息存儲

從 ActiveMQ 5.8 之后引進(jìn)的，和 KahaDB 非常相似基于文件的本地數(shù)據(jù)存儲形式，但是它提供比 KahaDB 更快的持久性。雖然還不是默認(rèn)的消息存儲，但我們希望此存儲實現(xiàn)在未來的版本中成為默認(rèn)的。但它不適用自定義 B-Tree 實現(xiàn)來索引預(yù)寫日志，而是使用基于 LevelDB 的索引。要使用 LevelDB 需要修改配置文件為：

JDBC消息存儲

原理圖 添加mysql數(shù)據(jù)庫的驅(qū)動包到lib文件夾 jdbcPersistenceAdapter配置 數(shù)據(jù)庫連接池配置 建倉sql和建表說明

ACTIVEMQ_MSGS queue和topic都存儲在里面 ACTIVEMQ_ACKS 存儲持久訂閱的信息和最后一個持久訂閱接收的消息ID ACTIVEMQ_LOCK 表ACTIVEMQ_LOCK在集群環(huán)境下才有用，只有一個Broker可以獲取消息，稱為Master Broker，其他的只能作為備份等待Master Broker不可用，才可能成為下一個Master Broker。這個表用于記錄哪個Broker是當(dāng)前的Master Broker 驗證和數(shù)據(jù)表變化

下面我先以 queue 為例，想要消息保存到數(shù)據(jù)庫生效，必須在創(chuàng)建消息生產(chǎn)者的時候開啟持久化模式（消費者無需改寫代碼）： 這樣，當(dāng)生產(chǎn)者發(fā)送消息成功后就可以在數(shù)據(jù)庫中的 activemq_msgs 表看到相應(yīng)的數(shù)據(jù)了。而當(dāng)消費者消費消息之后，數(shù)據(jù)庫的相應(yīng)記錄就會被刪除。 點到點(queue)

在點對點類型中當(dāng)DeliveryMode設(shè)置為NON_PERSISTENCE時，消息被保存在內(nèi)存中當(dāng)DeliveryMode設(shè)置為PERSISTENCE時，消息保存在broker的相應(yīng)的文件或者數(shù)據(jù)庫中。而且點對點類型中消息一旦被Consumer消費，就從數(shù)據(jù)中刪除 發(fā)布/訂閱(topic)

設(shè)置了持久訂閱數(shù)據(jù)庫里面會保存訂閱者的信息我們先啟動一下持久化topic 的消費者?？吹紸CTIVEMQ_ACKS 數(shù)據(jù)表多了一條消息。LAST_ACKED_ID記錄了CLIENT_ID最后簽收的一條消息. 我們啟動持久化生產(chǎn)6條數(shù)據(jù)，ACTIVE_MSGS數(shù)據(jù)表新增6條數(shù)據(jù)，消費者消費所有的數(shù)據(jù)后，表里的數(shù)據(jù)并沒有消失。持久化的topic的消息不管是否被消費，是否有消費者，產(chǎn)生的數(shù)據(jù)永遠(yuǎn)存在且只存儲一條。需要注意，持久化topic數(shù)據(jù)量太大會導(dǎo)致性能下降。 JDBC Message store with ActiveMQ Journal

這種方式克服了 JDBC 存儲的不足：JDBC 每次消息過來，都要去讀寫數(shù)據(jù)庫，比較消耗性能，所以引進(jìn)了 ActiveMQ Journal，使用高速緩存寫入技術(shù)，大大提高了性能要使用 ActiveMQ Journa 的話，需要修改配置文件，把持久化工廠修改為如下 當(dāng)消費者的速度能夠及時跟上生產(chǎn)者消息的生產(chǎn)速度時，journal文件能夠大大減少需要寫入到DB中的消息。 舉個例子：生產(chǎn)者生產(chǎn)了1000條消息，這1000條消息會保存到j(luò)ournal文件，如果消費者的消費速度很快的情況下，在journal文件還沒有同步到DB之前，消費者已經(jīng)消費了90%的以上消息，那么這個時候只需要同步剩余的10%的消息到DB。如果消費者的速度很慢，這個時候journal文件可以使消息以批量方式寫到DB?？偨Y(jié)： 以前是實時寫入mysql，在使用了journal后，數(shù)據(jù)會被journal處理，如果在一定時間內(nèi)journal處理（消費）完了，就不寫入mysql，如果沒消費完，就寫入mysql，起到一個緩存的作用。在慢慢的同步數(shù)據(jù)庫 持久化總結(jié)

柚子快報激活碼778899分享：ActiveMq學(xué)習(xí)⑧

http://yzkb.51969.com/

精彩文章