RabbitMQ 異常與任務分發

異常情況處理

上篇最后提到了這個問題， consumer異常退出、queue出錯、甚至rabbitMQ崩潰。因為它們都是軟件 ，軟件都會有bug，這是無法避免的。所以RabbitMQ在設計的時候也想到了這一點

在之前，消息分發給consumer后立即就會被標記為已消費，這時候如果consumber接到了一個消息但是還沒有來的及處理就異常退出,那么這個消息的狀態是已被消費的，於是就會造成消息丟失的問題。

可以看到在進行消費的方法里，第二個參數noAck（不進行確認）我們是設置為true。在這里我們應該把它改變成false,也就是 queue需要我們的consumer進行確認這個消息已被正常處理

處理的代碼也很簡單，一共有兩個步驟。第一個把noAck改成false

//消費結果需要進行確認
 channel.BasicConsume("firstTest", false, consumer);

第二部分就是在我們消費完成后進行交付

//進行交付,確定此消息已經處理完成
channel.BasicAck(deliveryTag: e.DeliveryTag, multiple: false);

那么 ，如果我們沒有進行交付會出現什么情況呢？  queue會把這個消息交給其它的consumer去處理，如果都沒有交付的代碼呢。那么這個消息會一直存在，所以，千萬不要忘了進行交付！

 

消息的處理部分已經結束，下面可以說隊列與消息的待久化。事實上關於隊列的我們已經有了，可以看聲明 queue的第二個參數durable已經是設置為true的。剩下的就是針對我們內容的，也就是消息的持久化

在發布消息的時候，可以看到第三個參數basicProperties傳的是null的。這時候我們就應該創建一個IBasicProperties了

//內容的基本屬性
 var properties = channel.CreateBasicProperties();
//設置內容的持久化
 properties.Persistent = true;

在發布消息的時候把perperties做成參數傳進去,這時我們的更改已經完成了

channel.BasicPublish("firstExchange", routingKey: "firstExchange_Demo_firstTest", basicProperties: properties, body: msg);

 

可以說到最后一個了，在之前queue的消息分發是第n個消息給第n個consumer的，這就會造成最開始處理消息的consumer在處理完成后會有閑置的可能性，而后面的一直在忙，消息分發的不均勻造成了很大的資源浪費，所以我們需要的是把消息分發給閑置的consumber。

這個操作是在consumer中完成的，在聲明頻道之后就指定這個consumer在同一時間內只處理一個消息，在上個消息未交付之前不要給我再分發消息。這個操作是容易完成的

 

//公平分發、同一時間只處理一個消息。
 channel.BasicQos(0, 1, false);