資訊專欄INFORMATION COLUMN
摘要：消息丟失分成三種情況，可能出現(xiàn)生產(chǎn)者消費者。生產(chǎn)者丟失數(shù)據(jù)生產(chǎn)者丟失數(shù)據(jù)首先要確保寫入的消息別丟，消息隊列通過請求確認(rèn)機(jī)制，保證消息的可靠傳輸。只有消息被持久化到磁盤以后，才會回傳消息。
消息丟失分成三種情況，可能出現(xiàn)生產(chǎn)者、RabbitMQ、消費者。
首先要確保寫入 RabbitMQ 的消息別丟，消息隊列通過請求確認(rèn)機(jī)制，保證消息的可靠傳輸。生產(chǎn)開啟 comfirm 模式，在生產(chǎn)者開啟 comfirm 模式之后，每次發(fā)送消息都會分配一個唯一的id。
一般在生產(chǎn)者這塊避免數(shù)據(jù)丟失，都是用 confirm 機(jī)制的
RabbitMQ 丟失數(shù)據(jù)，需要開啟 RabbitMQ 持久化，開啟持久化之后，生產(chǎn)者發(fā)送的消息會持久化到磁盤，RabbitMQ 就算是掛了，恢復(fù)啟動后也會讀取之前存儲的數(shù)據(jù)。
還有一種少見的情況，就是RabbitMQ還沒將消息持久化，自己就掛了。這種情況需要生產(chǎn)者那邊的確認(rèn)機(jī)制結(jié)合起來。只有消息被持久化到磁盤以后，才會回傳 ack 消息。生產(chǎn)者沒有接收到 ack，也可以自己重發(fā)。
消費丟失數(shù)據(jù)，剛消費到 RabbitMQ 發(fā)送的數(shù)據(jù)，消費進(jìn)程就掛了，重啟進(jìn)程后，RabbitMQ 也不會重新發(fā)送消息。
這個時候需要關(guān)閉 RabbitMQ 關(guān)閉自動的 ack 機(jī)制。每次在消費端處理后，再在程序里做 ack 確認(rèn)，這樣的話，如果沒有處理完，就沒有 ack 確認(rèn)，那 RabbitMQ 就認(rèn)為你還沒有處理完，這個時候 RabbitMQ 會重新發(fā)送消息給消費者。
如果覺得文章對你有幫助的話，請點個推薦吧!
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/124131.html
摘要：在全面兼容Apache Kafka生態(tài)的基礎(chǔ)上，消息隊列Kafka徹底解決ApacheKafka穩(wěn)定性不足的長期痛點，并且支持消息無縫遷移到云上。 近日，阿里云宣布正式推出消息隊列Kafka，全面融合開源生態(tài)。在全面兼容Apache Kafka生態(tài)的基礎(chǔ)上，消息隊列Kafka還具備了超易用，超高可用可靠性，擴(kuò)縮容不操心，全方位安全診斷，數(shù)據(jù)安全有保障的特點。可用行達(dá)99.9%，數(shù)據(jù)可靠行99...
摘要：為什么使用消息隊列消息隊列的優(yōu)缺優(yōu)點解耦異步消峰缺點系統(tǒng)的可用性降低，系統(tǒng)引入的外部依賴越多，越容易掛掉系統(tǒng)復(fù)雜性提高數(shù)據(jù)一致性問題常用消息隊列的優(yōu)缺點技術(shù)非常成熟，但是偶爾會出現(xiàn)較低概率的丟失消息，而且現(xiàn)在社區(qū)以及國內(nèi)應(yīng)用都越來越少社區(qū)相 為什么使用消息隊列消息隊列的優(yōu)缺 1優(yōu)點 （1） 解耦 （2） 異步 （3） 消峰 2 缺點 （1）系統(tǒng)的可用性降低，系統(tǒng)引入的外部依賴越多...
閱讀 3323·2021-11-22 12:04
閱讀 2705·2019-08-29 13:49
閱讀 482·2019-08-26 13:45
閱讀 2237·2019-08-26 11:56
閱讀 998·2019-08-26 11:43
閱讀 587·2019-08-26 10:45
閱讀 1265·2019-08-23 16:48
閱讀 2157·2019-08-23 16:07
