高负载服务器负载均衡，使用WCF和MSMQ

Question

目前我正在开发一个空间数据处理服务器。 以下是要求：

1. 服务器必须能够每秒接收和处理大约150-200条小邮件（gps修复，一些其他数据）。
2. 必须具有可扩展性。例如，在多台机器上运行并平衡负载（无nlb）

目前我已经测试过这种架构：

1. 传入消息服务，仅负责获取消息（不带msmqwcf绑定）
2. 邮件解析器服务。从msmq获取消息，解析它们并写入db，同时向下一个服务发送通知（再次使用普通的MSMQ互操作）。这个可以在多台PC上运行
3. 数据发布商服务。包含小缓存并负责从db获取请求的数据。通过wcf使用TCP绑定向客户端发送通知。

此外，所有服务都有配置方法和其他通过WCF TCP绑定调用的任务。

小的性能测试表明它的工作速度非常快，但我想知道这是将这些MSMQ和WCF一起用于这个特定应用程序的最佳方式。或者也许有人可以给我一个指导方向？

Answer 1

我不确定你有什么具体的问题，看起来更像是一个一般的设计问题，但是因为我喜欢MSMQ，我会在这里说话。

MSMQ确实有一些缺点，特别是关于负载平衡事务性消息，但整体而言非常棒。

但是，您的要求都没有提到使用MSMQ的任何具体原因：持久性，可恢复的消息传递，断开连接的客户端等等。所以我假设您有一些这些要求，但它们没有被明确地调出。

要求＃1应该很容易满足/击败，特别是如果这些是小消息并且没有明显的逻辑被执行（例如只是香草插入/更新），MSMQ很好地处理竞争的消费者。

要求＃2除非您使用MSMQ进行事务性消息传递，否则不可能对MSMQ进行负载均衡以启用扩展，但它有一些警告。你如何负载平衡MSMQ？如果您还没有这些详细信息，请参阅How to Load-Balancing MSMQ: A Brief Discussion。

除了负载平衡MSMQ的潜在问题，其中没有一个是不可克服的，这种方法没有任何问题。

扩展MSMQ
MSMQ在垂直（相同的机器）和中等水平（许多机器）上非常好地扩展。然而，很难使MSMQ真正高度可用，这可能是也可能不是一个问题。请参阅本答案中已有的链接，了解如何使其高度可用。

垂直缩放
在垂直扩展MSMQ时，有许多队列读取器在单个机器上运行，从单个队列读取。 MSMQ处理得非常好。我们所有的队列数据都在本地计算机的临时存储中。

如果我们丢失了托管队列的机器会怎样？
客户端可以发送并且消息将堆叠在客户端的传出队列中，但在服务器恢复之前我们无法接收它们。

队列中的消息会怎样？
如果没有引入某种高可用性的支持磁盘子系统，它们很可能会消失。即便如此，将另一个队列“连接”到该数据文件也是一个挑战。理论上，你可以让他们回来。实际上，它可能更容易从边缘系统重新发送消息。

根据事务量，队列在大多数情况下可能是空的，因此需要权衡数据丢失的风险，以及使其高度可用的工作量/成本。

横向缩放
在水平扩展MSMQ时，每个处理机器上都有一个队列实例。每台机器可能有[n]个读取器，用于在机器上运行从队列接收消息的队列。我们所有的队列数据都在几台机器上的临时存储中。

您可以使用文档中描述的任何方法来进行负载平衡MSMQ，但是，我的经验几乎总是与应用程序负载平衡有关，描述为软件负载平衡：客户端有可用的msmq端点列表交付给。托管队列的每台服务器都会遇到与单个队列相同的可用性问题。

也可能想查看Nine Tips to Enterprise-proof MSMQ以获取一些其他MSMQ相关信息。

Answer 2

感谢您的回答和链接。我正在寻找msmq作为大量消息的可靠传输。每天1-2毫克。另外，保证服务器端的那些消息在服务器工作期间不会丢失是非常重要的。所以我认为我需要耐久性，可恢复的消息传递，断开连接的客户端等。
至于负载平衡：主要负载将是数据解析和数据发布服务。并且想法是将原始消息推送到一个队列中，并且例如在不同PC上具有3个数据解析服务实例以解析来自它的消息并将它们存储在单个数据库中。与数据发布服务相同。或者像在StockTrader中一样，将通道缓存到节点并使用wcf向它们发送消息。

此外，我无法找到有关msmq wpf绑定的性能和可扩展性的信息。尝试过StockTrader，但是为了测试目的和快速分析，它有点过于复杂。

再次感谢您的回答。

Answer 3

真正倾听对话，但我认为MSMQ实际上会通过缓冲消息来帮助解决并发问题。那么从队列中读取的服务器永远不会被淹没？这将改变处理混乱的组件的问题，从基于“事件的”并发（如在Web服务器上）到更简单的拉动机制。

如果您还处于绿地设计阶段，您可能还想看看CCR＆amp; DSS，这些也可以帮助实现并发性。非常令人印象深刻的东西，但如果你只需要将消息存储在数据库中，它可能不会对你有太多帮助。