本身消息的發送就是異步發送的，所以在任何時候，channel上肯定不止只有一個消息另外來自消費者的手動確認本質上也是異步的。因此這里就存在一個未確認的消息緩沖區，因此希望開發人員能限制此緩沖區的大小，以避免緩沖區里面無限制的未確認消息問題。這個時候就可以通過使用basic.gos.方法設置“預取計數”值來完成的。該值定義通道上允許的未確認消息的最大數量。一旦數量達到配置的數量，RabbitMQ將停止在通道上傳遞更多消息，除非至少有一個未處理的消息被確認，例如，假設在通道上有未確認的消息5、6、7，8，并且通道的預取計數設置為4，此時RabbitMQ.將不會在該通道上再傳遞任何消息，除非至少有一個未應答的消息被ack。比方說tag=6這個消息剛剛被確認ACK，RabbitMQ將會感知這個情況到并再發送一條消息。消息應答和QoS預取值對用戶吞吐量有重大影響。通常，增加預取將提高向消費者傳遞消息的速度。雖然自動應答傳輸消息速率是最佳的，但是，在這種情況下已傳遞但尚未處理的消息的數量也會增加，從而增加了消費者的RAM消耗(隨機存取存儲器)應該小心使用具有無限預處理的自動確認模式或手動確認模式，消費者消費了大量的消息如果沒有確認的話，會導致消費者連接節點的內存消耗變大，所以找到合適的預取值是一個反復試驗的過程，不同的負載該值取值也不同100到300范圍內的值通?？商峁┳罴训耐掏铝?#xff0c;并且不會給消費者帶來太大的風險。預取值為1是最保守的。當然這將使吞吐量變得很低，特別是消費者連接延遲很嚴重的情況下，特別是在消費者連接等待時間較長的環境中。對于大多數應用來說，稍微高一點的值將是最佳的。

?

總結

以上是生活随笔為你收集整理的RabbitMQ预取值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。