按照官網提供的訂閱型寫法（ Retrieving Messages By Subscription ("push API")） 我發現，RabbitMQ服務器會在短時間內發送大量的消息給Consumer，然後，如果你沒有來得及Ack的話，那麼服務端會積壓大量的UnAcked消息，而Consumer如果來不急處理也會處於假死（也可能引起程序崩潰）。
僅有兩個Channel，結果積壓了大量的UnAcked消息。
這明顯是與我們的目的不一致，我們不能保證Consumer一 定會急時快速的處理消息。所以這種方式帶來的後果就是Consmer崩潰後，UnAcked消息又ReQueue，這肯定會消耗MQ的寶貴資源。
我試圖在官網上找到一種方法，讓每條消息明確的Ack後再接受下一條。但是好沒有。好在在 gitbooks.io/rabbitmq-quick/ 這兒找到了，通過設置Channel的QOS即可
1 2 | var channel = Connect.CreateModel();channel.BasicQos(0,1,false); //RabbitMQ客戶端接受消息最大數量 |
設置後的結果：
在開啓4個Consumer的情況下，每條消息處理要耗時2秒。然後問題解決了。Unacked的消息只有4個。
關注公衆號，分享乾貨，討論技術
