性能和可靠性的權(quán)衡

3種消費方式:
事務(wù) , 拉取 , Qos

• 消費者一般使用推送, 不用拉取(太慢了)
• 批量機制可以極大提升性能
• 事務(wù) 機制一般會被遺棄
• 單隊列 一般用于順序消息，但是也喪失了高性能

拉取

就是輪詢, 很慢,一般不拉取 用推送

和推送一樣, 可以選手動和自動確認:

手動確認

上圖中把自動確認傳的false

有個ack的機制,如果設(shè)置的手動確認又沒有發(fā)ack, 下次還能get到這條
如果ack了 消息就會從隊列刪除

自動確認

正常還是推送, 以下的消費方法都是推送的 :

批量確認

極大提升性能

自定義Consumer,里面有批量確認

使用自定義Consumer

Qos預(yù)拉取+批量quere

在確認消息被接收之前，消費者可以預(yù)先要求接收一定數(shù)量的消息，在處理完一定數(shù)量的消息后，批量進行確認。

這種機制一方面可以實現(xiàn)限速（將消息暫存到 RabbitMQ 內(nèi)存中）的作用，一方面可以保證消息確認質(zhì)量（比如確認了但是處理有異常的情況）。

如果消費者應(yīng)用程序在確認消息之前崩潰，則所有未確認的消息將被重新發(fā)送給其他消費者。所以這里存在著一定程度上的可靠性風險。

注意：消費確認模式必須是非自動 ACK 機制（這個是使用 baseQos 的前提條件

使用就是比 批量 加一句
channel.basicQos(150,true);

第二個入?yún)lobal：true\false 是否將上面設(shè)置應(yīng)用于 channel，簡單點說，就是上面限制是 channel 級別的還是 consumer 級別。

一行開啟Qos預(yù)拉取

生產(chǎn)者這樣生產(chǎn)

確實有批量確認的效果