active mq 事物以及ack模式 事務介紹

ACK模式與類型介紹

JMS API中約定了Client端可使用四種ACK_MODE,在javax.jms.Session接口中:

• AUTO_ACKNOWLEDGE = 1    自動確認
• CLIENT_ACKNOWLEDGE = 2    客戶端手動確認   
• DUPS_OK_ACKNOWLEDGE = 3    自動批量確認
• SESSION_TRANSACTED = 0    事務提交併確認

在與Spring MVC集成中  mq源碼默認 使用AUTO_ACKNOWLEDGE

Session.AUTO_ACKNOWLEDGE爲自動確認，客戶端發送和接收消息不須要作額外的工做。哪怕是接收端發生異常，也會被看成正常發送成功。
Session.CLIENT_ACKNOWLEDGE爲客戶端確認。客戶端接收到消息後，必須調用javax.jms.Message的acknowledge方法。jms服務器纔會看成發送成功，並刪除消息。
DUPS_OK_ACKNOWLEDGE容許副本的確認模式。一旦接收方應用程序的方法調用從處理消息處返回，會話對象就會確認消息的接收；並且容許重複確認。

mq消息確認設置如上。

 此外AcitveMQ補充了一個自定義的ACK_MODE: INDIVIDUAL_ACKNOWLEDGE = 4    單條消息確認

咱們在開發JMS應用程序的時候,會常常使用到上述ACK_MODE,其中"INDIVIDUAL_ACKNOWLEDGE "只有ActiveMQ支持,固然開發者也可使用它. ACK_MODE描述了Consumer與broker確認消息的方式(時機),好比當消息被Consumer接收以後,Consumer將在什麼時候確認消息。對於broker而言，只有接收到ACK指令,纔會認爲消息被正確的接收或者處理成功了,經過ACK，能夠在consumer與Broker之間創建一種簡單的「擔保」機制. 

Client端指定了ACK_MODE,可是在Client與broker在交換ACK指令的時候,還須要告知ACK_TYPE,ACK_TYPE表示此確認指令的類型，不一樣的ACK_TYPE將傳遞着消息的狀態，broker能夠根據不一樣的ACK_TYPE對消息進行不一樣的操做。

Client端指定了ACK_MODE,可是在Client與broker在交換ACK指令的時候,還須要告知ACK_TYPE,ACK_TYPE表示此確認指令的類型，不一樣的ACK_TYPE將傳遞着消息的狀態，broker能夠根據不一樣的ACK_TYPE對消息進行不一樣的操做。

 

    好比Consumer消費消息時出現異常,就須要向broker發送ACK指令,ACK_TYPE爲"REDELIVERED_ACK_TYPE",那麼broker就會從新發送此消息。在JMS API中並無定義ACT_TYPE,由於它一般是一種內部機制,並不會面向開發者。ActiveMQ中定義了以下幾種ACK_TYPE(參看MessageAck類):

• DELIVERED_ACK_TYPE = 0    消息"已接收"，但還沒有處理結束
• STANDARD_ACK_TYPE = 2    "標準"類型,一般表示爲消息"處理成功"，broker端能夠刪除消息了
• POSION_ACK_TYPE = 1    消息"錯誤",一般表示"拋棄"此消息，好比消息重發屢次後，都沒法正確處理時，消息將會被刪除或者DLQ(死信隊列)
• REDELIVERED_ACK_TYPE = 3    消息需"重發"，好比consumer處理消息時拋出了異常，broker稍後會從新發送此消息
• INDIVIDUAL_ACK_TYPE = 4    表示只確認"單條消息",不管在任何ACK_MODE下    
• UNMATCHED_ACK_TYPE = 5    BROKER間轉發消息時,接收端"拒絕"消息

    到目前爲止,咱們已經清楚了大概的原理: Client端在不一樣的ACK_MODE時,將意味着在不一樣的時機發送ACK指令,每一個ACK Command中會包含ACK_TYPE,那麼broker端就能夠根據ACK_TYPE來決定此消息的後續操做. 接下來,咱們詳細的分析ACK_MODE與ACK_TYPE.

事務

ActiveMQ有支持兩種事務，

• JMS transactions - the commit() / rollback() methods on a Session (which is like doing commit() / rollback() on a JDBC connection)
• XA Transactions - where the XASession acts as an XAResource by communicating with the Message Broker, rather like a JDBC Connection takes place in an XA transaction by communicating with the database.

在支持事務的session中，producer發送message時在message中帶有transaction ID。broker收到message後判斷是否有transaction ID，若是有就把message保存在transaction store中，等待commit或者rollback消息。因此ActiveMq的事務是針對broker而不是producer的，無論session是否commit，broker都會收到message。

若是producer發送模式選擇了persistent，那麼message過時後會進入死亡隊列。在message進入死亡隊列以前，ActiveMQ會刪除message中的transaction ID，這樣過時的message就不在事務中了，不會保存在transaction store中，會直接進入死亡隊列。具體刪除transaction ID的地方是在

org.apache.activemq.util.BrokerSupport的doResend，將transaction ID保存在了originalTransactionID中，刪除了transaction ID