RabbitMq雜記

• 前言

本文記錄一下關於Rabbitmq的一些優化選項的設置，固然優化配置有挺多的，目前收集的是一些經常使用的優化選項，後續有空再深刻研究一波。

• 確認機制

Rabbitmq的發佈者確認機制是AMQP的加強功能，對於發佈者發送的每條消息，服務器都會發送一個ack命令確認響應或者nack否認確認信息。該功能能夠做爲一種輕量級的事務功能，固然rabbitmq有select命令開啓基於事務的批量處理，可是這種會形成阻塞。

• 使用HA隊列避免節點故障

在設置HA隊列的時候，須要設置參數x-ha-policy爲all，固然也能夠指定集羣中的幾臺服務器爲一批獨立節點，設置x-ha-policy爲nodes，再加上x-ha-nodes配置節點位置信息。
HA隊列容許多個服務器上擁有冗餘副本，當發佈消息到設置爲高可用的隊列時，該消息會被髮送到集羣中的每臺服務器，該集羣管理着HA隊列。一旦消息在集羣中的任何節點都完成消費，那麼消息的全部副本將當即從其餘節點中刪除。
HA隊列有一個主節點，其餘的爲輔助節點，若是主節點發生故障，其餘節點切換爲主節點。

• 消息持久化

設置參數delivery-mode爲2（默認爲1，消息保存在內存中，不開啓持久化），同時設置queue的屬性爲durable。
消息持久化就像一把雙刃劍，一方面能夠保證消息的安全，能在消息被消費前發生宕機防止丟失消息。另一方面開啓消息持久化消耗服務器的io資源，可能會致使嚴重的性能問題，致使大大下降消息發佈速度。
固然io性能問題若是能在硬件上提供支持的話是能夠解決的，好比增長內存，增長寫入的硬盤，增長合適大小、帶有備用電池的raid卡，並配置大量的讀寫緩存。

• 消息回推

寫過RxJava的人應該知道背壓這個概念，或者netty的高水位設置，消息回推也是相同場景下的概念，回推是消息生產者發送消息太快到mq服務器了，形成mq服務器壓力太大，mq服務器將發送 Channel.FlowRPC讓消息生產者進行阻塞。
固然若是生產者忽視了Channel.FlowRPC這個命令，消息回推就無效了，rabbitmq爲了應對這種狀況，擴展了amqp，在rabbitmq內部，使用信用的概念來管理回推發佈消息的時機。在創建新的鏈接時，鏈接會被分配一個預訂數量的信用值，rabbitmq每接受一個rpc命令時，會扣除一個點的信用值，rpc請求處理完後，再返回被扣除的信用值，若是鏈接的信用值不足時會跳過鏈接指導有足夠的信用值。

• 消息的推拉模型

Rabbitmq提供了get和consume兩種命令來獲取消息，經過名稱能夠很容易的推測出對應的推拉模型。get是一種拉模型，經過輪詢來或許消息，可見效率會比較低，同時也可能由於沒法判斷當前消息的負載狀況，形成消費者荷載太重的狀況。consume是推模型，相似於消息回調的方式，性能會好不少。

• 1
• 1