rabbitmq使用筆記

1、RabbitMQ的幾個關鍵概念

一、Connection和Channel

生產者/消費者都須要和RabbitMQ Broker創建鏈接，每一個鏈接都是一條TCP鏈接，也就是Connection。

一旦TCP鏈接創建起來後，客戶端就建立一個AMQP信道（Channel），每一個信道都會被指派一個惟一的ID。Channel是創建在Connection之上的虛擬鏈接，RabbitMQ處理的每條AMQP指令都是經過信道完成的。

咱們徹底可使用 Connection 就能完成客戶端和rabbitmq的通信，爲何還要引入信道呢？

由於，在一般的應用場景下，可能會有多個線程（生產者/消費者）須要同時和RabbitMQ通訊，那麼必然會建立多個Connection，也就是多個TCP鏈接。但創建和銷燬TCP鏈接都會有很大的系統開銷。

因此，RabbitMQ 採用相似NIO（Non-blocking I/O）的方法，選擇TCP鏈接複用。在connection上創建channel，不只能夠減小性能開銷，同時也便於管理。

 

 

每一個線程把持一個信道，因此信道複用了 Connection 的 TCP 鏈接。同時 RabbitMQ 能夠確保每一個線程的私密性，就像擁有獨立的鏈接同樣。當每一個信道的流量不是很大時，複用單一的 Connection 能夠在產生性能瓶頸的狀況下有效地節省 TCP 鏈接資源。可是信道自己的流量很大時，多個信道繼續複用一個 Connection 的話就會產生性能瓶頸。此時，就須要開闢多個 Connection，將這些信道平均分配到這些 Connection 中，至於這些相關的調優策略須要根據業務自身的實際狀況進行調節。

信道在 AMQP 中是一個很重要的概念，大多數操做都是在信道這個層面展開的。

好比 channel.exchangeDeclare、channel.queueDeclare、channel.basicPublish、channel.basicConsume 等方法。

RabbitMQ 相關的 API 與 AMQP 緊密相連，好比 channel.basicPublish 對應 AMQP 的 Basic.Publish 命令。

二、Exchange、Queue、Route

Broker：就是消息隊列服務器實體，指rabbitmq實例。
Channel：消息通道，在客戶端的每一個鏈接connection上，可創建多個channel，每一個channel表明一個會話任務。
Exchange：消息交換機，它指定消息按什麼規則路由到哪一個隊列。
Queue：消息隊列載體，存放消息的地方，每一個消息都會被投入到一個或多個隊列中。
Binding：綁定，它的做用就是把exchange和queue按照路由規則綁定起來。
Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost：虛擬主機，一個broker裏能夠開設多個vhost，用做不一樣用戶的權限分離。
Producer：消息生產者，生產投遞消息的程序。
Consumer：消息消費者，接受處理消息的程序。

2、使用Tracing日誌記錄消息

RabbitMQ 的 Tracing能跟蹤RabbitMQ中消息的流入流出狀況。rabbitmq_tracing插件會對流入流出的消息作封裝，而後將封裝後的消息日誌存入相應的trace文件之中。

可使用 rabbitmq-plugins enable rabbitmq_tracing 命令來啓動rabbitmq_tracing插件。若是是使用docker部署的，先進入docker環境，再開啓。

在rabbitmq 的GUI 管理界面 「Admin」 選項右側本來只有 」Users」、」Virtual Hosts」和 」Policies「 三項，在添加rabbitmq_tracing 插件以後，會多出」Tracing」選項。

　

Name：自定義日誌名稱，建議標準點容易區分。

Format：表示輸出的消息日誌格式，有Text和JSON兩種，Text格式的日誌方便人類閱讀，JSON的方便程序解析。Text相比JSON格式佔用空間稍大點。

JSON格式的payload（消息體）默認會採用Base64進行編碼。

Max payload bytes：表示每條消息的最大限制，單位爲B。好比設置了了此值爲10，那麼當有超過10B的消息通過Rabbit MQ時會被截斷。如消息「trace test payload.」會被截斷成「trace test」。

Pattern：用來設置匹配模式，如「#」 匹配全部消息流入流出的狀況，即當有客戶端生產消息或消費消息的時候，都會把相應的消息日誌記錄下來。「publish.#」 匹配全部消息流入的狀況；「deliver.#」 匹配全部消息流出的狀況；「publish.exchange.b2b.gms.ass」只匹配發送者(Exchanges)爲exchange.b2b.gms.ass的全部消息流入的狀況。

3、持久化

RabbitMQ默認是不持久Exchange、Queue、Binding以及隊列中消息的，這意味着一旦MQ服務器重啓，全部已聲明的隊列，Exchange，Binding以及隊列中的消息都會丟失。爲了防止丟失，須要實現持久化。但持久化會對RabbitMQ的性能形成很大的影響，可能會降低10倍不止。因此，爲了提升rabbitmq的性能，沒有必要持久化的能夠不用設置爲持久化。

一、Exchange 和 Queue 持久化

把Exchange 和 Queue 的durable 屬性置爲true，能夠實現Queue 和Exchange 的持久化。但這裏須要注意的是，只有Exchange 和Queues 的durable都爲true 時才能綁定，不然在綁定時，RabbitMQ會報錯的。也就是說，

二、Message 持久化

消息的持久化須要在消息投遞的時候設置delivery mode值爲2。消息持久化必須同時要求exchange和queue也是持久化的。
持久化的代價就是性能損失,磁盤IO遠遠慢於RAM(使用SSD會顯著提升消息持久化的性能) , 持久化會大大下降RabbitMQ每秒可處理的消息.二者的性能差距可能在10倍以上。

- exchange持久化，在聲明時指定durable => 1 - queue持久化，在聲明時指定durable => 1 - 消息持久化，在投遞時指定delivery_mode => 2（1是非持久化）