MSMQ、WCF和健壮性

Question

不是MSMQ或WCF的专家，我读了很多关于它的文章，它听起来和看起来都很棒。我正在尝试开发一些东西，最终但首先是一些理论，它需要是健壮和持久的。

我猜MSMQ将被托管在一个单独的服务器上。

将有2个WCF服务。一个用于传入消息，另一个用于传出消息(接收消息，进行一些内部处理/验证，然后将其放入传出消息队列中，或者可能发送电子邮件/文本消息/任何内容)

据我所知，通过正确的配置，我们可以让系统具有事务性(不会丢失任何消息)，并且可以只发送一次，因此不会有重复消息的机会。

应用程序/服务将是多线程的，以处理数以百计的消息。

但是在消息处理期间或整个服务生命周期中，如果服务器崩溃怎么办？如果服务器重新启动怎么办？如果服务出于某种原因抛出异常怎么办？如何才能不丢失该消息，但如何将其放回队列中等待再次处理？另外，如何才能确保服务以一种健壮的方式再次生成呢？

如果有任何建议和细节，我将不胜感激。WCF/MSMQ提供了相当多的选项。

Answer 1

你的假设是：

我猜

MSMQ将被托管在一个独立的服务器上。

是不正确的。MSMQ安装在要参与消息队列的所有计算机上。

将会有2个WCF服务。一个用于传入消息，另一个用于传出消息

在最典型的配置中，目标队列是侦听服务的本地队列。

例如，您的ServiceA将有一个本地队列供其读取。ServiceB也有一个本地队列，可以从中读取数据。如果ServiceA想要调用ServiceB，它会将一条消息放入ServiceB的本地队列中。

据我所知，有了正确的配置，我们就可以让系统具有事务性(不会丢失任何消息)

这是正确的。这是因为MSMQ使用一种称为存储转发的消息传递模式。有关说明，请参阅here。

从本质上讲，假定没有消息丢失是安全的，因为消息从一台机器传输到另一台机器实际上是在三个不同的事务下进行的。

1. 第一个事务: ServiceA写入它自己的临时本地队列。如果失败，事务将回滚，ServiceA可以处理该异常。
2. Second transaction: ServiceA机器上的队列管理器将消息传输到ServiceB机器上的队列管理器。如果失败，则消息将保留在临时队列中。
3. Third transaction: ServiceB从本地队列中读取消息。如果ServiceB消息处理程序方法抛出异常，则事务将消息回滚到本地队列。

应用程序/服务将是多线程的，以处理消息

这很好，除非您需要在消息处理链中保留顺序。如果您需要有序处理，那么在不实现重新定序器以重新应用顺序的情况下，您不能拥有多个线程。

我认为MSMQ可以分开托管，让x台服务器共享那个队列？

所有希望参与消息交换的服务器都安装了MSMQ。然后，每个服务器都可以写入任何其他服务器上的任何队列。

我之所以这么想，是因为如果服务器宕机了怎么办？那么如何将消息发送/接收到MSMQ中

如果队列是事务性的，那么这意味着它们上的消息被持久化到磁盘。如果服务器宕机，那么当它重新启动时，消息仍然在那里。当服务器关闭时，它显然不能参与消息交换。但是，消息仍然可以“发送”到该服务器-它们只是对发送者来说是本地的(在临时队列中)，直到目标服务器恢复在线为止。

因此，通过拥有一台中央MSMQ服务器(并对其进行镜像/故障切换)，就可以保证正常运行时间。

使用消息队列的全部意义在于它是一种容错传输，因此您不需要保证正常运行时间。如果您有100%的可用性，那么就没有什么理由使用消息队列。

将如何通知WCF传入的消息？

每个服务将侦听其自己的本地队列。当消息到达时，WCF运行时会调用处理方法并处理该消息。

如何通知服务发送消息失败

如果ServiceA无法向ServiceB传输消息，则ServiceB将永远不会收到该失败的通知。它也不应该是。ServiceA将处理传输失败，而不是ServiceB。在这种情况下，您的期望在服务之间创建了硬耦合，这是消息队列应该删除的东西。

Answer 2

即使临时关闭服务或重新启动计算机，MSMQ也可以存储消息。

WCF的主要目标是将消息从源传输到目的地。不管是什么交通工具。在您的例子中，MSMQ是用于WCF的传输，且不明显同时具有客户端和服务的在线/可用。但是当接收到消息时，您有责任正确地处理它，而不管使用什么传输来发送消息。