ActiveMQ是一種開源的，實(shí)現(xiàn)了JMS1.1規(guī)范的，面向消息(MOM)的中間件，為應(yīng)用程序提供高效的、可擴(kuò)展的、穩(wěn)定的和安全的企業(yè)級消息通信。
ActiveMQ的作用就是系統(tǒng)之間進(jìn)行通信。 當(dāng)然可以使用其他方式進(jìn)行系統(tǒng)間通信， 如果使用 ActiveMQ的話可以對系統(tǒng)之間的調(diào)用進(jìn)行解耦， 實(shí)現(xiàn)系統(tǒng)間的異步通信。 原理就是生產(chǎn)者生產(chǎn)消息， 把消息發(fā)送給ActiveMQ。 ActiveMQ接收到消息， 然后查看有多少個(gè)消費(fèi)者， 然后把消息轉(zhuǎn)發(fā)給消費(fèi)者， 此過程中生產(chǎn)者無需參與。 消費(fèi)者接收到消息后做相應(yīng)的處理和生產(chǎn)者沒有任何關(guān)系。
消息通信的基本方式有兩種：
1.同步方式
兩個(gè)通信應(yīng)用服務(wù)之間必須要進(jìn)行同步，兩個(gè)服務(wù)之間必須都是正常運(yùn)行的。發(fā)送程序和接收程序都必須一直處于運(yùn)行狀態(tài)，并且隨時(shí)做好相互通信的準(zhǔn)備。發(fā)送程序首先向接收程序發(fā)起一個(gè)請求，稱之為發(fā)送消息，發(fā)送程序緊接著就會(huì)堵塞當(dāng)前自身的進(jìn)程，不與其他應(yīng)用進(jìn)行任何的通信以及交互，等待接收程序的響應(yīng)，待發(fā)送消息得到接收程序的返回消息之后會(huì)繼續(xù)向下運(yùn)行，進(jìn)行下一步的業(yè)務(wù)處理。
2.異步方式
兩個(gè)通信應(yīng)用之間可以不用同時(shí)在線等待，任何一方只需各自處理自己的業(yè)務(wù)，比如發(fā)送方發(fā)送消息以后不用登錄接收方的響應(yīng)，可以接著處理其他的任務(wù)。也就是說發(fā)送方和接收方都是相互獨(dú)立存在的，發(fā)送方只管方，接收方只能接收，無須去等待對方的響應(yīng)。Java 中 JMS 就是典型的異步消息處理機(jī)制，JMS 消息有兩種類型：點(diǎn)對點(diǎn)、發(fā)布/訂閱。
1)publish(發(fā)布)-subscribe(訂閱)(發(fā)布-訂閱方式)
發(fā)布/訂閱方式用于多接收客戶端的方式.作為發(fā)布訂閱的方式，可能存在多個(gè)接收客戶端，并且接收端客戶端與發(fā)送客戶端存在時(shí)間上的依賴。一個(gè)接收端只能接收他創(chuàng)建以后發(fā)送客戶端發(fā)送的信息。作為subscriber ,在接收消息時(shí)有兩種方法，destination的receive方法，和實(shí)現(xiàn)message listener 接口的onMessage方法。
2)p2p(point-to-point)(點(diǎn)對點(diǎn))
p2p的過程則理解起來比較簡單。它好比是兩個(gè)人打電話，這兩個(gè)人是獨(dú)享這一條通信鏈路的。一方發(fā)送消息，另外一方接收，就這么簡單。在實(shí)際應(yīng)用中因?yàn)橛卸鄠€(gè)用戶對使用p2p的鏈路，相互通信的雙方是通過一個(gè)類似于隊(duì)列的方式來進(jìn)行交流。和前面pub-sub的區(qū)別在于一個(gè)topic有一個(gè)發(fā)送者和多個(gè)接收者，而在p2p里一個(gè)queue只有一個(gè)發(fā)送者和一個(gè)接收者。
工作模式：Topic是“訂閱-發(fā)布”模式，如果當(dāng)前沒有訂閱者，消息將會(huì)被丟棄，如果有多個(gè)訂閱者，那么這些訂閱者都會(huì)受到消息；Queue是“負(fù)載均衡”模式，如果當(dāng)前沒有消費(fèi)者，消息不會(huì)被丟棄；如果有多個(gè)消費(fèi)者，那么一條消息也只能發(fā)送給一個(gè)消費(fèi)者，并且要求消費(fèi)者ack信息。
有無狀態(tài)：Topic無狀態(tài)；Queue 數(shù)據(jù)默認(rèn)會(huì)在mq服務(wù)器上以文件的形式存儲(chǔ)，比如activemq一般保存在$AMQ_HOME\data\kr-store\data下面，也可以配置成DB存儲(chǔ)。
傳遞完整性：Topic模式如果沒有訂閱，消息就會(huì)被丟棄。Queue消息不會(huì)被丟棄。
處理效率：由于消息會(huì)隨著訂閱者的數(shù)量進(jìn)行復(fù)制，所以處理性能會(huì)隨著訂閱者的增加而明顯降低，并且還要結(jié)合不同的消息協(xié)議自身的性能差異；Queue模式由于一條消息只能被一個(gè)消費(fèi)者消費(fèi)，所以就算消費(fèi)者再多，性能也不會(huì)有明顯降低，當(dāng)然不同的消息協(xié)議的具體性能也是有差異的。
一般來說我們可以在業(yè)務(wù)段加一張表,用來存放消息是否執(zhí)行成功,每次業(yè)務(wù)事物commit之后,告知服務(wù)端,已經(jīng)處理過該消息,這樣即使你消息重發(fā)了,也不會(huì)導(dǎo)致重復(fù)處理。
為了避免意外宕機(jī)以后丟失信息，需要做到重啟后可以恢復(fù)消息隊(duì)列，消息系統(tǒng)一半都會(huì)采用持久化機(jī)制。ActiveMQ的消息持久化機(jī)制有JDBC，AMQ，KahaDB和LevelDB，無論使用哪種持久化方式，消息的存儲(chǔ)邏輯都是一致的。就是在發(fā)送者將消息發(fā)送出去后，消息中心首先將消息存儲(chǔ)到本地?cái)?shù)據(jù)文件、內(nèi)存數(shù)據(jù)庫或者遠(yuǎn)程數(shù)據(jù)庫等。再試圖將消息發(fā)給接收者，成功則將消息從存儲(chǔ)中刪除，失敗則繼續(xù)嘗試嘗試發(fā)送。消息中心啟動(dòng)以后，要先檢查指定的存儲(chǔ)位置是否有未成功發(fā)送的消息，如果有，則會(huì)先把存儲(chǔ)位置中的消息發(fā)出去。
如果一條消息不能被處理，會(huì)被退回服務(wù)器重新分配，如果只有一個(gè)消費(fèi)者，該消息又會(huì)重新被獲取，重新拋異常。如果有多個(gè)消費(fèi)者，往往在一個(gè)服務(wù)器上不能處理的消息，在另外的服務(wù)器上依然不能被處理。消息在重試 6 次后仍不能發(fā)送成功的，ActiveMQ 認(rèn)為這條消息是“有毒”的，將會(huì)把消息丟到死信隊(duì)列里。
官方微信
官方抖音
京公網(wǎng)安備 11030102010736號