RabbitMQ consumer的一些坑

坑

坑就像是惡夢，總是在最不設防的時候出現，打的你滿地找牙。這里記錄一些坑，遇到的朋友可以及時的跳出，避免帶來損失。

 

使用事件方式去獲取queue中的消息，然后再進行處理。這看起來沒什么問題，但是如果queue中的消息有幾萬條甚至才幾十萬條，一股腦的全丟給consumer會造成什么情況呢？

下面模擬一個例子，我們的queue中有着二千多條消息，每個消息處理的時間需要1s。為了消息的可靠性我們手動交付消息的處理狀態。

using (var channel = RabbitMqHelper.GetConnection().CreateModel())
            {
                var consumer = new EventingBasicConsumer(channel);

                consumer.Received += (sender, e) =>
                {
                    Console.WriteLine(Encoding.UTF8.GetString(e.Body));

                    //處理時間
                    Thread.Sleep(1000);
                    //手動交付
                    channel.BasicAck(e.DeliveryTag, false);
                };

                //不自動確認
                channel.BasicConsume("lazyqueue", false, consumer);

                Console.WriteLine("consumer啟動成功");

                Console.ReadKey();

            }

這里是queue，可以看到有2847條消息

后面把程序運行起來,短短的時間里可以看到內存占用了一個多G！而CPU占用率也很高。如果再跑一會，嘖嘖 怕是要爆掉了。

這時再看我們的隊列，什么？ 才處理了一條消息。-.- 還好用的是手動確認機制，不然可能會丟失所有的消息。

 

處理方式也很簡單，在之前的博文中也有說到，為了queue分發給consumer的消息是平均的，設置在同一時間一個consumer只處理一條消息，當處理完確認后再分發給consumer下一條消息，這聽起來很靠譜。我們設置一下，再把程序跑起來

這時候再看，內存只占用了幾M而已，這時候就顯的輕松無比了