标签:关于 key icp test null rabbit tle first 技术
上篇最后提到了这个问题, consumer异常退出、queue出错、甚至rabbitMQ崩溃。因为它们都是软件 ,软件都会有bug,这是无法避免的。所以RabbitMQ在设计的时候也想到了这一点
在之前,消息分发给consumer后立即就会被标记为已消费,这时候如果consumber接到了一个消息但是还没有来的及处理就异常退出,那么这个消息的状态是已被消费的,于是就会造成消息丢失的问题。
可以看到在进行消费的方法里,第二个参数noAck(不进行确认)我们是设置为true。在这里我们应该把它改变成false,也就是 queue需要我们的consumer进行确认这个消息已被正常处理
处理的代码也很简单,一共有两个步骤。第一个把noAck改成false
//消费结果需要进行确认 channel.BasicConsume("firstTest", false, consumer);第二部分就是在我们消费完成后进行交付
//进行交付,确定此消息已经处理完成 channel.BasicAck(deliveryTag: e.DeliveryTag, multiple: false);那么 ,如果我们没有进行交付会出现什么情况呢? queue会把这个消息交给其它的consumer去处理,如果都没有交付的代码呢。那么这个消息会一直存在,所以,千万不要忘了进行交付!
消息的处理部分已经结束,下面可以说队列与消息的待久化。事实上关于队列的我们已经有了,可以看声明 queue的第二个参数durable已经是设置为true的。剩下的就是针对我们内容的,也就是消息的持久化
在发布消息的时候,可以看到第三个参数basicProperties传的是null的。这时候我们就应该创建一个IBasicProperties了
//内容的基本属性 var properties = channel.CreateBasicProperties(); //设置内容的持久化 properties.Persistent = true;在发布消息的时候把perperties做成参数传进去,这时我们的更改已经完成了
channel.BasicPublish("firstExchange", routingKey: "firstExchange_Demo_firstTest", basicProperties: properties, body: msg);
可以说到最后一个了,在之前queue的消息分发是第n个消息给第n个consumer的,这就会造成最开始处理消息的consumer在处理完成后会有闲置的可能性,而后面的一直在忙,消息分发的不均匀造成了很大的资源浪费,所以我们需要的是把消息分发给闲置的consumber。
这个操作是在consumer中完成的,在声明频道之后就指定这个consumer在同一时间内只处理一个消息,在上个消息未交付之前不要给我再分发消息。这个操作是容易完成的
//公平分发、同一时间只处理一个消息。 channel.BasicQos(0, 1, false);
标签:关于 key icp test null rabbit tle first 技术
原文地址:http://www.cnblogs.com/zxtceq/p/7567312.html