这一篇文章让我们看看在消息系统中可能发生的各种错误的情况下,看下EasyNetQ如何处理它们。
订阅服务挂了
当你写了一个windows 服务,用来订阅一个NewCustomerMessage消息。
如果这个服务失败时会发生什么呢?为了效率,EasyNetQ为订阅功能实现了一个基于内存的内部使用的队列。消息通过网络从RabbitMQ中接收到后,会把消息放到这个内存队列中。一个订阅者线程从这个内存队列拿走消息后,回调自己提供的消息处理代码。一旦这个回调完成后,EasyNetQ会发送'Ack'给RabbitMQ。没有收到'Ack'前,这个消息不会从RabbitMQ消息队列中被删除。如果你的服务在处理这个消息时挂掉了,这个消息(所有的消息都在EasyNetQ内存队列中)仍将呆在RabbitMQ队列中。直到你的服务再次连接上后,这些消息将会再次被发送。
我的订阅者消费消息的速度比消息发布速度慢
EasyNetQ利用了RabbitMQ服务的特性,设置prefetch-count值为一个比较可用的值(当前是50).这意味着,将最多不会超过50条消息在消费者的内存队列中。这样会防止在你的正在订阅的应用发生内存超出异常。一旦未Ack消息数累积到这个值后,RabbitMQ将停止发送消息,只是保留这些消息在EasyNetQ的内存队列中。当然,最终这个队列将会吃掉你的RabbitMQ服务器上的所有磁盘空间。你应该在这个地方做下监控,确保在发生这种情况发生前你能够得到警报。
在我的订阅者和RabbitMQ代理之间发生网络故障
如前面文章用EasyNetQ连接RabbitMQ所述,EasyNetQ实现了一个延迟连接策略。这个策略假设这个代理不会总是可用的。当你第一次通过使用RabbitHutch.CreateBus连接到这个代理时,EasyNetQ开启一个连接,不断循环尝试去连接代理,如果你指定的连接字符串地址的代理没有处于可用状态,你会从消息信息日志中看到'Trying to Connect'。订阅者能够使用bus.Subscribe方法去订阅,即使当这个代理不可用时。这个订阅的细节会被EasyNetQ缓存。 当代理恢复可用时,这个正在不断循环尝试连接将会成功连接到代理,并且所有缓存的订阅一同恢复。
同样,当EasyNetQ和代理连接中断时,它将返回到循环连接,你在日志中看'Trying to Connect'信息。一旦连接重新建立,被缓存的订阅者将再次被建立。最后结论就是,在正在运行环境中,无论在网络断开时,或是你需要在被你的RabbitMQ代理拒绝时,你能够保留你的订阅者。
当消费一个消息时,订阅回调抛出异常
如果你的订阅回调抛出异常,EasyNetQ将会拿到这个正在被消费的消息,包装这个消息到一个指定错误消息中。这个错误消息将会被发布到EasyNetQ的错误队列(名字是EasyNetQ_Default_Error_Queue)。你应该监控这个错误队列中的消息。这个错误消息包括所有必要的信息,例如需要重新发布的原始消息,以及异常的类型,异常信息和堆栈信息。你可能使用EasyNetQ.Hosepipe工具重新发布错误信息。参考下一篇文章EasyNetQ.Hosepipe
英文地址:https://github.com/EasyNetQ/EasyNetQ/wiki/Error-Conditions
本文地址:http://www.cnblogs.com/HuangLiang/p/EasyNetQ-Error-Conditions.html
我的微信订阅号:open_dotNET