EasyNetQ使用(九)【非泛型的发布&订阅扩展方法，发生错误的情况 】
自从EasyNetQ第一个版本开始，它就可以发布/订阅特定类型的消息。
bus.Subscribe<MyMessage>("subscriptionId",
x => Console.WriteLine(x.Text));
bus.Publish<MyMessage>(theMessage);
但是，在运行期间，你怎么去发现消息类型？例如：你可能有一些系统加载外部插件，希望能订阅他们自己的消息类型。EasyNetQ为了这个目标提供了非泛型的发布和订阅方法。
只要加上这个using语句：
using EasyNetQ.NonGeneric;
它将提供给你一些subscription扩展方法。
public static IDisposable Subscribe(
this IBus bus,
Type messageType,
string subscriptionId,
Action<object> onMessage)
public static IDisposable Subscribe(
this IBus bus,
Type messageType,
string subscriptionId,
Action<object> onMessage,
Action<ISubscriptionConfiguration> configure)
public static IDisposable SubscribeAsync(
this IBus bus,
Type messageType,
string subscriptionId,
Func<object, Task> onMessage)
public static IDisposable SubscribeAsync(
this IBus bus,
Type messageType,
string subscriptionId,
Func<object, Task> onMessage,
Action<ISubscriptionConfiguration> configure)
还包括发布扩展方法：
public static void Publish(
this IBus bus,
Type messageType,
object message)
public static void Publish(
this IBus bus,
Type messageType,
object message,
string topic)
public static Task PublishAsync(
this IBus bus,
Type messageType,
object message)
public static Task PublishAsync(
this IBus bus,
Type messageType,
object message,
string topic)
它们就像IBus上的Publish和Subscribe方法一样，除了提供一个Type参数，作为泛型参数的替代，消息处理器用Action替代了Action。
var messageType = typeof(MyMessage);
bus.Subscribe(messageType, "my_subscriptionId", x =>
{
var message = (MyMessage)x;
Console.Out.WriteLine("Got Message: {0}", x.Text);
});
这里有一个例子，使用了非泛型的Publish。
var messageType = typeof(MyMessage);
bus.Publish(messageType, theMessage);
这一篇文章让我们看看在消息系统中可能发生的各种错误的情况下，看下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
