按照官網提供的訂閱型寫法（ 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即可
var channel = Connect.CreateModel(); channel.BasicQos(0,1,false); //RabbitMQ客戶端接受消息最大數量
設置后的結果：
在開啟4個Consumer的情況下，每條消息處理要耗時2秒。然后問題解決了。Unacked的消息只有4個。