ActiveMQ訊息傳送機制：

Producer客戶端使用來發送訊息的， Consumer客戶端用來消費訊息；
它們的協同中心就是ActiveMQ broker,broker也是讓producer和consumer呼叫過程解耦的工具，最終實現了非同步RPC/資料交換的功能。
隨著ActiveMQ的不斷髮展，支援了越來越多的特性，也解決開發者在各種場景下使用ActiveMQ的需求。
比如producer支援非同步呼叫；
使用flow control機制讓broker協同consumer的消費速率；
consumer端可以使用prefetchACK來最大化訊息消費的速率；
提供"重發策略"等來提高訊息的安全性等。
 

一條訊息從producer端發出之後，一旦被broker正確儲存，那麼它將會被consumer消費，然後ACK，broker端才會刪除；
不過當訊息過期或者儲存裝置溢位時，也會終結它。

網上一張圖：詳細說明了這個過程：

上面的圖裡面寫的很清晰。

上半部分是producer的流程，下半部分consumer的流程分為兩塊，同步的consumer.receive和非同步的MessageListener。從圖中可以看出非同步的MessageLister也是一條一條處理的，由delivered佇列控制的。

這張圖片中簡單的描述了:1)producer端如何傳送訊息 2) consumer端如何消費訊息 3) broker端如何排程。
如果用文字來描述圖示中的概念，恐怕一言難盡。
圖示中，提及到prefetchAck，以及訊息同步、非同步傳送的基本邏輯；這對你瞭解下文中的ACK機制將有很大的幫助。

ACK模式與型別介紹：

Consumer消費訊息的風格有2種: 同步/非同步. 使用consumer.receive()就是同步，使用messageListener就是非同步。

在同一個consumer中，我們不能同時使用這2種風格，比如在使用listener的情況下，當呼叫receive()方法將會獲得一個Exception。

兩種風格下，訊息確認時機有所不同。

同步呼叫時，在訊息從receive方法返回之前，就已經呼叫了ACK；因此如果Client端沒有處理成功，此訊息將丟失(可能重發，與ACK模式有關)。

基於非同步呼叫時，訊息的確認是在onMessage方法返回之後，如果onMessage方法異常，會導致訊息不能被ACK，會觸發重發
 
。

ACK模式詳解：

AUTO_ACKNOWLEDGE :

自動確認,這就意味著訊息的確認時機將有consumer擇機確認.
"擇機確認"似乎充滿了不確定性,這也意味著,開發者必須明確知道"擇機確認"的具體時機,否則將有可能導致訊息的丟失,或者訊息的重複接收.

當我們使用messageListener方式消費訊息時，通常建議在onMessage方法中使用try-catch,這樣可以在處理訊息出錯時記錄一些資訊，
而不是讓consumer不斷去重發訊息；
如果你沒有使用try-catch,就有可能會因為異常而導致訊息重複接收的問題,需要注意你的onMessage方法中邏輯是否能夠相容對重複訊息的判斷。

CLIENT_ACKNOWLEDGE : 

客戶端手動確認，這就意味著AcitveMQ將不會“自作主張”的為你ACK任何訊息，開發者需要自己擇機確認。
無論是“同步”/“非同步”，ActiveMQ都不會發送STANDARD_ACK_TYPE，直到message.acknowledge()呼叫。
如果在client端未確認的訊息個數達到prefetchSize * 0.5時，會補充發送一個ACK_TYPE為DELIVERED_ACK_TYPE的確認指令，
這會觸發broker端可以繼續push訊息到client端。

DUPS_OK_ACKNOWLEDGE :

"訊息可重複"確認，意思是此模式下，可能會出現重複訊息，並不是一條訊息需要傳送多次ACK才行。
它是一種潛在的"AUTO_ACK"確認機制，為批量確認而生，而且具有“延遲”確認的特點。
對於開發者而言，這種模式下的程式碼結構和AUTO_ACKNOWLEDGE一樣，不需要像CLIENT_ACKNOWLEDGE那樣呼叫acknowledge()方法來確認訊息。

SESSION_TRANSACTED :

當session使用事務時，就是使用此模式。

在事務開啟之後，和session.commit()之前，所有消費的訊息，要麼全部正常確認，要麼全部redelivery。
這種嚴謹性，通常在基於GROUP(訊息分組)或者其他場景下特別適合。

INDIVIDUAL_ACKNOWLEDGE :

很少使用，它的確認時機和CLIENT_ACKNOWLEDGE幾乎一樣

當訊息消費成功之後，需要呼叫message.acknowledege來確認此訊息(單條)，
而CLIENT_ACKNOWLEDGE模式先message.acknowledge()方法將導致整個session中所有訊息被確認(批量確認)。