①生產(chǎn)階段，生產(chǎn)者創(chuàng)建消息，經(jīng)過網(wǎng)絡(luò)發(fā)送到rabbit服務(wù)器

②消息存儲(chǔ)階段，首先被發(fā)送到交換器然后經(jīng)過路由算法，到達(dá)隊(duì)列，等待被拉取消費(fèi)

③消費(fèi)階段，消費(fèi)者經(jīng)過網(wǎng)絡(luò)從rabbit服務(wù)器拉取消息進(jìn)行消費(fèi) 

這三個(gè)階段都有可能消息丟失，下面一一分析。

消息存儲(chǔ)階段

發(fā)送階段

 有。）

channel.BasicAcks += (sender, ev) =>                {                    Console.WriteLine("消息已經(jīng)確認(rèn)收到" + ev.DeliveryTag);
                };
                channel.BasicNacks += (sender, ev) =>                {                    Console.WriteLine("消息未確認(rèn)" + ev.DeliveryTag);                };

消費(fèi)階段

通過把AutoAck設(shè)置為false，手工確認(rèn)，告知服務(wù)器，消息已經(jīng)處理了，可以進(jìn)行消息出隊(duì)刪除。

 channel.BasicConsume(queue: queueName,                                     autoAck: false,                                     consumer: consumer);

 consumer.Received += (model, ea) =>                {                    //dosometing                    channel.BasicAck(ea.DeliveryTag, false);//確認(rèn)                };

小結(jié)：如果做了以上的處理，那么消息就不會(huì)跟你躲貓貓了。這里有性能的問題，消息持久化，是要刷到磁盤上的會(huì)影響投遞速度，并且消息確認(rèn)也會(huì)影響到消息投遞速度。不基本上能夠滿足需求了。如果不能滿足性能需求，可以使用其他方法，比如 在每次發(fā)送消息的時(shí)候，都包含應(yīng)答隊(duì)列的名稱，這樣消費(fèi)者就可以回發(fā)應(yīng)答以確認(rèn)接受到了。如果消息應(yīng)答未在合理時(shí)間范圍內(nèi)到達(dá)，生產(chǎn)者就重新發(fā)送消息。