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而已，这时候就显的轻松无比了