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

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

  1. 服务器必须能够每秒接收和处理大约150-200条小消息(gps修复,一些其他数据)。
  2. 它必须是可扩展的。 例如,在多台机器上运行并平衡负载本身(没有nlb)

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

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

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

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

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

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

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

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

要求#2除非您使用MSMQ进行事务性消息传递,否则不可能对MSMQ进行负载均衡以实现扩展,但它有一些警告。 你如何负载平衡MSMQ? 请参阅如何负载平衡MSMQ:如果您还没有它们,请参阅一些简要讨论 。

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

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

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

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

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

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

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

您可以使用文档中描述的任何方法来实现MSMQ的负载平衡,但是,我的经验几乎总是与应用程序负载平衡有关,称为软件负载平衡:客户端有一个可用的msmq端点列表。 。 托管队列的每个服务器都受到与单个队列相同的可用性问题的影响。

也可能想要查看有关企业certificateMSMQ的九个提示,以获取一些其他MSMQ相关信息。

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

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

再次感谢您的回答。

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

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