在完美情況下，我們無需額外的配置或步驟，rabbitmq就可以可靠的投遞訊息。但是，完美的情況是不存在的，我們在訊息發布的時候總會出現各種問題，如網路或硬體帶來的問題，使得訊息可靠性降低。
而rabbitmq又給我們提供了不同的保障機制：
使用這些機制會對效能產生一定的影響，我們只有執行過自己的效能基準測試，才能找到在效能於可靠投遞之間的平衡點。
mandatory標誌是乙個與basic.publishrpc命令一起投遞的引數，它是用來告訴rabbitmq如果訊息不可路由，它應該通過basic.returnrpc命令將訊息返回給發布者。設定mandatory標誌可以讓rabbitmq向你通知失敗。
發布者確認作為事務的輕量級替代方法，發布任何訊息之前，訊息發布者必須向rabbitmq傳送confirm.select請求，並等待confirm.selectok響應以獲知投遞確認已經被啟動。在這一點上，對於發布者傳送給rabbitmq的每條訊息，伺服器會傳送乙個確認響應（basic.ack）或否定確認響（basic.nack）。
備用交換機是用來處理一些無法被交換機路由的訊息，如果一些訊息無法被路由，那麼他將會被路由到這個新的備用交換機上。 如果將訊息傳送到具有備用交換器的交換器（設定了mandatory=true）上， 那麼一旦預期的交換器無法正常路由訊息，basic.return就不會發給發布者。因為訊息成功的發布到了備用交換器
amqp事務提供了一種機制，通過這種機制，訊息可以批量發布到rabbitmq，然後提交到佇列或者回滾。
在協議層，當rabbitmq由於錯誤而無法路由時，它將傳送乙個basic.return響應，希望終止事務的發布者應該傳送tx.rollback請求，並等待tx.rollbackok響應，然後繼續工作。
需要注意的是,如果使用事務或訊息確認機制，則訊息需要在ha佇列中所有活動節點確定後，rabbitmq才會傳送成功響應。
ha佇列是rabbitmq團隊建立的一項增強功能，它允許佇列在多個伺服器上擁有冗餘副本，但他需要集群環境。ha佇列有乙個主服務節點，其他節點都是輔助節點。
如果rabbitmq**伺服器在消費訊息之前因某種故原因發生宕機，那麼訊息將會永遠丟失。但是設定delivery-mode為2將訊息持久化到硬碟可以解決這一問題。但是對於沒有足夠的io能力的伺服器來說，訊息持久化可能會導致嚴重的效能問題。
發布者傳送訊息會對rabbitmq造成一定壓力，當rabbitmq感受到壓力時會傳送channel.flowrpc方法來讓你的發布者發生阻塞。從rabbitmq3.2開始，rabbitmq新增了在達到連線信用閾值傳送通知的機制connection.blocked和connection.unblocked。我們可以使用rabbitpy來檢測連線狀態。
RabbitMQ訊息的處理
訊息的確認，是指生產者投遞訊息後，如果broker收到訊息，則會給我們生產這乙個應答。生產者進行接收應答，用來確定這條訊息是否正常的傳送到broker，這種方式也是訊息的可靠性投遞的核心保障。確認機制流程圖 如何實現confirm確認訊息？第一步 在channel上開啟確認模式 channel.co...
RabbitMQ 訊息廣播
rabbitmq訊息模型的核心理念是 發布者 producer 不會直接傳送任何訊息給佇列。事實上，發布者 producer 甚至不知道訊息是否已經被投遞到佇列。發布者 producer 只需要把訊息傳送給乙個交換機 exchange 交換機非常簡單，它一邊從發布者方接收訊息，一邊把訊息推送到佇列。...
RabbitMQ 廣播訊息
定義 廣播訊息是指生產者產生的訊息將分發給所有訂閱這個訊息的消費者,而普通的模式是 一批訊息可以被多個人共同消費,如consumer1可能消費1,3,5記錄,而consumer2可能消費的是2,4,6這種模組就是共同消費模組 而今天說的是廣播訊息,它是指一些訊息同時被推送到多個訂閱者,而這些訂閱者收...