2

我正处于 .NET 服务的规划阶段，该服务不断处理传入消息，其中涉及各种转换、数据库插入和更新等。作为一个整体，该服务庞大而复杂，但它执行的单个任务很小，简单，定义明确。

出于这个原因，并且为了便于将来扩展，我想将服务拆分为几个较小的服务，这些服务基本上执行部分处理，然后再将其传递给链中的下一个服务。

为了实现这一点，我需要某种中间消息传递系统，它将消息从一个服务传递到另一个服务。我希望以这样一种方式发生这种情况，即如果链中的链接崩溃或短暂脱机，则消息将开始排队并在目的地恢复联机后得到处理。

我一直对这类事情使用消息队列，但最近才知道 SQL Service Broker 似乎做了类似的事情。SQLSB 是这种情况的可行替代方案吗？如果是，我是否会通过使用它而不是标准消息队列来看到任何性能优势？

谢谢

4

3 回答 3

3

在我看来，您可能正在使用服务总线架构。这将为您提供您正在寻找的协调和容错。我最熟悉和偏爱 NServiceBus，但还有其他的，包括 Mass Transit 和 Rhino Service Bus。

于 2011-01-14T12:45:53.217 回答
2

如果这些步骤中的大多数从数据库状态开始并以数据库更新结束，那么将消息存储与数据存储合并就很有意义：

  • 要备份/恢复的单个产品
  • 一致的状态备份
  • 单一的高可用性/灾难恢复解决方案（数据库镜像、集群、日志传送等）
  • 数据库规模存储（IO 能力、大小和容量限制等根据数据库产品特性，而不是消息存储产品的限制）。
  • 用于调整、故障排除和管理的单一产品

此外，还有一些重要的性能考虑，因为让您的消息存储与数据存储相同意味着您不需要对每个消息交互进行两阶段提交。使用单独的消息存储需要您在分布式事务中注册消息存储和数据存储（即使在同一台机器上），这需要两阶段提交，并且比单独的数据库事务的单阶段提交慢得多。

此外，使用数据库中的消息存储而不是外部存储具有可查询性等优点（在消息队列上运行 SELECT）。

现在，如果我们将抽象术语“数据库中的消息存储”翻译为 Service Broker 并将“非数据库消息存储”翻译为 MSMQ，您就会明白为什么 SSB 会在 MSMQ 周围随时运行循环。

于 2011-01-15T20:14:31.653 回答
1

我最近对这两种方法的体验（从 Sql Server Service Broker 开始）导致我哭泣着要从 SQL Server 中获取消息。这个问题是准政治的，但您可能需要考虑一下：我的组织中的 SQL 服务器由专门的 DBA 管理，而应用程序服务器（即 NServiceBus 等消息传递）由开发人员和网络团队管理。对数据库服务器的任何更改都需要 DBA 进行痛苦的性能分析，并且担心我们可能会因我们的队列引擎位于同一空间中而降低标准 SQL 职责。

SSSB 很难管理（与消息传递中间件不同），但不同之处在于我更允许在消息传递世界中搞砸一些事情（可能发生的最坏情况是某处堆积了一堆消息并填满了日志），而我不能承受 SQL 世界中的任何错误，客户事务数据存在并且对业务至关重要（包括来自遗留系统的数据）。我真的不想再收到那些“意外的数据库增长”或“等待时间警报”或“为什么我的临时数据库不断增长”的电子邮件。

我了解到应用服务器很便宜。只需添加消息处理程序，添加机器......很容易。几乎没有许可证费用。使用 SQL Server 则完全相反。现在在我看来，使用 Service Broker 进行消息传递就像使用昂贵的汽车犁土豆地一样。这对其他事情要好得多。

于 2013-12-16T20:27:20.843 回答