Sql server 在已有SQL Server和BizTalk时使用MSMQ

简单问题：是否有充分的理由将MSMQ添加到已有多个BizTalk和SQL Server节点的现有消息传递框架中

---

以下是背景：我们有一个消息传递框架来处理账单，目前负载相当低（每天最多10000），但它正在增加。我们使用BizTalk和SQL Server进行所有处理，并且在（同步）插入其中一个数据库（而不是BizTalk消息框）时开始注意到一些超时。我们的一位高级程序员建议我们使用MSMQ来保存（异步）导致超时的数据，并在以后进行处理；他设计的解决方案有效，即将部署，但考虑到我们可以使用BizTalk本身或SQL Server Service Broker（SSSB），我仍然怀疑这是否是正确的决定。关于这三种技术有很多讨论，但它们通常是关于必须选择其中一种而不是其他技术，我没有看到任何人已经使用BizTalk和SSSB并决定将MSMQ添加到组合中。在我们的例子中，我认为这是对我们的技术堆栈不必要的添加，但这可能是我自己的偏见（也是无知），因为我更了解SSSB，从来没有对MSMQ做过任何大事。你觉得怎么样？

听起来你应该弄清楚为什么插入要花这么长时间，然后改为修复。对于一个运行SQL Server的像样的盒子来说，10000/天算不了什么

编辑：

添加任何类型的异步处理都是一种扫兴的方式。假设你的插入需要一分钟（我知道他们可能不需要，但为了讨论的缘故）。如果您使插入异步，您仍然每天只能处理1440个插入，直到您开始落后。最终，您总是需要加快插入速度

---

话虽如此，我不认为在这种情况下使用MSMQ而不是SSSB有任何令人信服的好处（反之亦然）。有人可能会争辩说，使用MSMQ时，您需要手工编写一个执行插入的侦听器守护进程，而使用SSSB时，您可以在数据库中自动编写该守护进程。另一方面，使用MSMQ，您将消息存储卸载到另一台服务器，这可能会减轻SQL server的一些即时压力。

我认为，如果您只是想让数据库调用离线，那么您可以使用BizTalk实现这一点（例如，通过创建“离线”命令）主机-从而创建一个新的主机队列）

---

msmq真正擅长的是BizTalk的入站端。系统可以调用BizTalk而不关心BizTalk本身的可用性。消息将一直挂起，直到BizTalk再次可用。

我支持Hugh-我们已成功地将MSMQ（和IBM MQ系列）与BizTalk一起用于异步事务通信（主要是金融事务，其中对可跟踪、可靠的ACID类型消息传递的需求超过了对事务延迟的任何需求）

我们发现MSMQ的好处是：

• 事务传递—消息可以由目标系统提取，并在2阶段UOW下插入SQL
• Hugh关于交付与系统可用性脱钩的观点（如果目标系统在一段不合理的时间内停机，您仍然有死信队列）
• 负载平衡/限制-目标系统可以通过以更均匀的速度将消息从队列中拉出，从而防止过度的消息传递
• 审计-在MSMQ上使用日志记录允许额外的跟踪层
• 还请注意，MSMQ有一个WCF适配器-不需要自定义侦听器

我们通常不直接从BizTalk调用SQL：

• 对于读取，这等同于轮询数据库，希望有消息可以发送（这可能会产生与调用频率相关的问题，即冗余、诱导延迟、SQL上的负载以及争用（例如，在应用程序将数据添加到表中时进行轮询）。我们更希望每个应用程序决定何时向BizTalk/ESB提交消息
• 对于写操作，除非将数据卸载到暂存区域以供目标应用程序处理，否则会导致大部分“业务”处理转移到BizTalk中（即验证、应用业务规则等）-IMHO这对于BizTalk来说太细粒度了。正如您所发现的，很难控制消息传递到SQL的速率（例如，除非您开始使用单例或Hcetrations等），这会再次导致锁定/争用问题

---

这并不能回答我的问题，是吗？你的问题，就我所知，是“你怎么想的？”。我认为这意味着[MSMQ]“对我们的技术堆栈来说是不必要的补充。我的回答的含义是“可能，是的”，理由是你不需要花这么多时间来做一个简单的插入。明白了，但是要意识到db不仅仅用于那些插入，它被其他进程大量使用，插入的账单消息都带有图像。而且无论你对db做了多少调整，当负载增加时，问题可能会再次出现，为什么现在不要尝试修复它？异步处理是一种方法，我只是想问一下选择MSMQ而不是其他两种解决方案。是的，这就是为什么我要求有一个很好的理由不这样做，而是使用MSMQ。所以你可以说，你可以用现有的工具集以更低的成本实现相同的结果。我的意思是，我非常喜欢MSMQ一种技术，我不能给你一个好的理由去使用它。