这一篇文章让我们看看在消息系统中可能发生的各种错误的情况下，看下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
