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。。。。 【最安全 + 性能不算太差】