sql-server - 消息队列的好策略？

Question

我目前正在设计一个应用程序，我最终希望将其迁移到 Windows Azure。然而，短期内，它将在我自己托管的服务器上运行。

该应用程序涉及许多独立的 Web 应用程序 - 其中一些本质上是接收数据的 WCF 服务，一些是供用户管理数据的站点。此外，还需要有一个在后台运行的工作服务，它将以各种方式处理数据。

我非常热衷于为此使用解耦架构。理想情况下，我希望组件(即网络应用程序和辅助服务)彼此了解得尽可能少。看起来使用消息队列将是最好的解决方案 - Web 应用程序可以将带有工作单元的消息排入队列，并且工作服务可以将它们挑选出来并根据需要进行处理。

但是，我想制定一套良好的技术来实现此目的，同时记住我最终将迁移到 Azure，并希望最大程度地减少迁移时需要执行的返工量到云端。 Azure 内置了一个队列组件，它看起来非常适合我的需求。我想做的是自己创建一些尽可能模仿的东西。

看起来有几个选项(我在 Windows 上使用 .NET，后端是 SQL Server 2005) - 目前我发现的选项是:

• MSMQ
• SQL Server 服务代理
• 使用数据库表和一些存储过程来滚动我自己的

我想知道是否有人对此有任何建议 - 或者是否有人做过类似的事情并就要做/避免的事情提出建议。我意识到每种情况都是不同的，但在这种情况下，我认为我的排队要求非常通用，因此我很想听听其他人关于最佳方法的想法。

提前致谢，

约翰

Answer 1

如果您考虑的是 Azure，也许您应该直接从 Azure 开始，因为 Azure 队列与任何 MSMQ 或 SSB 之间的 API 和语义都显着不同。

MSMQ 与 SSB 的快速 3048 米比较(我将保留自定义表队列不进行比较，因为这实际上取决于您如何实现它......)

• 部署:MSMQ 是 Windows 组件，SSB 是 SQL 组件。 SSB 需要 SQL 实例来存储任何消息，因此断开连接的客户端需要访问实例(可以是 Express)。 MSMQ 需要在客户端部署 MSMQ(操作系统的一部分，但可选安装)。
• 可编程性:MSMQ 提供成熟的、受支持的 WCF channel 。 SSB 仅提供实验性 WCF channel http://ssbwcf.codeplex.com
• 性能:在事务处理模式下，SSB 将明显快于 MSMQ。如果让 MSMQ 在非事务模式下运行(尽力而为、无序、交付)，速度会更快
• 可查询性:可以对 SSB 队列进行 SELECTE 操作(查看任何消息，完整的 SQL JOIN/WHERE/ORDER/GROUP 功能)，可以查看 MSMQ 队列(仅查看下一条消息)
• 可恢复性:SSB 队列集成在数据库中，因此可以与数据库一起备份和恢复，从而与应用程序状态保持一致。 MSMQ 队列在 NT 文件备份子系统中进行备份，因此为了保持备份同步(一致)，必须暂停队列和数据库。
• 事务(因为每次入队/出队总是伴随着数据库更新):SSB 完全集成在 SQL 中，因此出队和入队是本地事务操作。 MSMQ 是一个单独的 TM(事务管理器)，因此队列/出队必须是分布式事务操作才能在事务中注册 SQL 和 MSMQ。
• 管理和监控:两者都同样糟糕。没有任何工具。
• 相关消息处理:SSB 可以通过内置 Conversation Group Locking 阻止并发线程处理相关消息。 .
• 事件驱动:SSB 有 Activation要启动存储过程，MSMQ 使用 Windows Activation服务。相似的。不过，由于 WAITFOR(RECEIVE) 和 MAX_QUEUE_READERS 交互的方式，SSB 具有 self 负载平衡功能。
• 可用性:SSB 依托 SQL Server 高可用性故事，它可以在集群或数据库镜像环境中工作。 MSMQ 仅适用于 Windows 集群故事。作为 HA 解决方案，数据库镜像比集群便宜得多。

此外，我还要补充一点，SSB 和 MSMQ 在它们提供的原语级别上存在显着差异:SSB 原语是对话，而 MSMQ 原语是消息。考虑 TCP 与 UDP 语义。