1.jms訊息確認機制
jms訊息只有在被確認之後，才認為已經被成功地消費了。訊息的成功消費通常包含三個階段：客戶接收訊息、客戶處理訊息和訊息被確認。在事務性會話中，當乙個事務被提交的時候，確認自動發生。在非事務性會話中，訊息何時被確認取決於建立會話時的應答模式（acknowledgement mode）。該引數有以下三個可選值：
session.auto_acknowledge。當客戶成功的從receive方法返回的時候，或者從messagelistener.onmessage方法成功返回的時候，會話自動確認客戶收到的訊息。
session.client_acknowledge。 客戶通過訊息的acknowledge方法確認訊息。需要注意的是，在這種模式中，確認是在會話層上進行：確認乙個被消費的訊息將自動確認所有已被會話消 費的訊息。例如，如果乙個訊息消費者消費了10個訊息，然後確認第5個訊息，那麼所有10個訊息都被確認。
session.dups_acknowledge。 該選擇只是會話遲鈍第確認訊息的提交。如果jms provider失敗，那麼可能會導致一些重複的訊息。如果是重複的訊息，那麼jms provider必須把訊息頭的jmsredelivered欄位設定為true。
2.activemq訊息確認機制
activemqsession，實現了jms的session，queuesession, topicsession
activemqsession.individual_acknowledge 每條訊息都必須顯式呼叫acknowledge方法確認訊息。
3.訊息永續性
jms 支援以下兩種訊息提交模式：
deliverymode.persistent 指示jms provider持久儲存訊息，以保證訊息不會因為jms provider的失敗而丟失。 訊息持久化在硬碟中，activemq持久化有三種方式：amq、kahadb、jdbc。
deliverymode.non_persistent 不要求jms provider持久儲存訊息，訊息存放在記憶體中，讀寫速度快，在jms服務停止後訊息會消失，沒有持久化到硬碟。
啟用事務，消費者收到訊息後給服務端傳送乙個確認，服務端收到確認後才將訊息從伺服器刪除
connection#createsession(boolean transacted,int acknowledgemode)第乙個引數選擇true
收到message後，呼叫message上的acknowledge方法進行確認
ActiveMQ訊息的可靠性
我們在activemq訊息持久化訂閱中，介紹了對topic模式下的訊息進行持久化訂閱，使其在暫無消費者消費或activemq服務重啟的情況下，不會導致訊息的丟失，這裡其實就是保證了一定程度的訊息可靠性。那麼還會在其他地方傳送訊息不可靠的情況麼，首先我們從訊息的生產及消費的流程中來看，訊息有生產者傳送...
ActiveMQ可靠性機制
訊息的簽收 acknowledgment 客戶端成功接收一條訊息的標誌是這條訊息被簽收。成功接收一條訊息一般包括如下三個階段 1 客戶端接收訊息 2 客戶端處理訊息 3 訊息被簽收 簽收可以由activemq發起，也可以由客戶端發起，取決於session簽收模式的設定。在帶事務的session中，簽...
Kafka訊息可靠性
如果mq沒有類似資料庫事務結構和保證，是不可能達到訊息投遞100 可靠的，極端情況下訊息投遞要麼丟失或重複。下面咋們從producer，broker，consumer的角度分析一下kafka中會出現哪些情況。目前生產者傳送訊息 request.required.acks 有三種方式。acks 0 p...