RabbitMQ 使用QOS（服务质量）+Ack机制解决内存崩溃的状况

当消息有几万条或者几十万条的时候，若是消费的方式不对，会形成内存崩溃的状况

一：consumer

1. 短连接：basicget 独自去获取message。。。 request 的方式去获取，断开式。。。

 

2. 长链接：eventbasicconsumer。。。 【订阅式】

1. eventbasicconsumer + noack....

consumer端处理一条数据须要耗费 1s钟。。。。

《1》 确认机制。。。 无论你是否却不确认，消息都会一股脑所有打入到你的consumer中去。。。

《2》 QOS =》 服务质量。。。 【QOS + Ack】机制，解决这个问题。。。
我但愿是一条一条从broke中打过来。。。

解决办法就是在channel设置好通道。。。

channel.BasicQos(0, 1, false);////这样RabbitMQ就会使得每一个Consumer在同一个时间点最多处理一个Message。换句话说，在接收到该Consumer的ack前，他它不会将新的Message分发给它。
EventingBasicConsumer consumer = new EventingBasicConsumer(channel);

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

Console.WriteLine(msg);
};

channel.BasicConsume("mytest", true, consumer);

eventbasicconsumer : noack=true， 直连 =》 会形成application内存暴涨 + 可能丢失数据【application挂了】

noack=false, 直连 =》 形成【application】可能会挂掉。。

noack + QOS 直连 =》 没问题。。。 【咱们能够想象的】

 

BasicGet: 获取redis中的操做模式是同样的。。。。 不利的地方，就是每次都会建立一个channel。。。。 【最安全 + 性能不算太差】