Question

我们使用一个简单的设置来使用Rebus订阅队列。我们需要确保，如果RabbitMQ队列不可用（例如服务已关闭），我们可以检测到该问题并稍后重试。我们还需要处理在成功建立连接后RabbitMQ掉线的可能性（订阅机制有可能对此进行处理吗？

这是我们的示例设置；

var activator = new BuiltinHandlerActivator();

_bus = Configure
    .With(activator)
    .Transport(t => t.UseRabbitMq(configuration["ConnectionStrings:RabbitMQ"], "QueueName"))
    .Routing(r => r.TypeBased().Map<Message>("QueueName"))
    .Options(b => b.SimpleRetryStrategy("QueueName_Error"))
    .Start();

activator.Register(() => messageHandler);
_bus.Subscribe<Message>().Wait();

请注意，我们使用的是.net核心。

Answer 1

如果Rebus无法成功连接到RabbitMQ，则拒绝启动。原因是，它需要先初始化自己的输入队列，然后才能开始接收消息。

有人可能会争辩说Rebus应该简单地启动并等待连接成功建立，然后进行初始化，但这会冒隐藏配置错误的风险，例如如果您部署的应用程序连接到错误的主机名。

因此，在您的应用程序启动时，经纪人需要在那儿。然后，建议您在启动过程中让所有错误冒出来，例如这样，无论您使用哪种托管机制来运行您的流程，都可以检测到。

一旦启动，Rebus将维护RabbitMQ连接（IModel）池，检测并丢弃关闭或错误的连接。除此之外，Rebus依靠RabbitMQ的驱动程序从连接错误中恢复，因此，如果您在high availability mode中运行RabbitMQ，则可以使用多个RabbitMQ连接字符串（由;分隔）配置Rebus，然后如果出现错误，它将自动故障转移到可用节点。

最后一件事：只要您正在处理消息，就可以安全：Rebus将在确认传入消息之前发送从Rebus处理程序发送和发布的所有传出消息。因此，at least once delivery guarantee可以始终存在。

唯一需要注意的是初始发送！也就是说，当您发送第一条消息时（例如，从Web请求处理程序中或可能在任何地方），如果Rebus无法连接到任何消息，则需要确保您有另一种存储消息数据的方式。完全是RabbitMQ节点。

如果Rebus无法发送初始消息，您将收到一个异常，然后由您自行处理。一种低调的实用解决方案（至少在许多第一版系统中，可能在以后的许多生产系统中也是如此）是将错误以及您打算在消息中发送的数据一起简单地记录到文件中。

我希望这可以解决您可能遇到的任何问题，请再问一些。

从失败中恢复以创建具有Rebus的RabbitMQ传输连接

1 个答案: