MSMQ 作为 SQL Server 插入的缓冲区
我正在学习 MSMQ，并成功使用它对来自面向消费者的 ASP.NET MVC 网站的电子邮件和文本消息进行排队，由单独的客户端应用程序处理。
如果缺少 SQL Server 数据库，也许在交换驱动器或损坏的数据库部署时，将非时间关键型插入放入本地 MSMQ 队列中以提高正常运行时间是否有意义？
理论上，我可以在进行数据库更改时暂停/恢复队列处理（持久性）。有没有人尝试过这个或者有更好的方法吗？
I'm learning about MSMQ and am successfully using it to queue email and text messages from a consumer-facing ASP.NET MVC website, to be handled by a separate client application.
In the event of a missing SQL Server database, perhaps while swapping drives or a broken database deploy, would it make sense to queue non time-critical inserts in a local MSMQ queue to improve up-time?
Theoretically, I can then pause/resume queue processing (persistence) while making database changes. Has anyone tried this or is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您希望通过本地排队来获得更高的可用性，那么您应该考虑 Service Broker 部署在与 IIS/ASP 实例并置的 SQL Express 实例上。与 MSMQ 相比，使用 SSB 的优点是消息存储和数据存储之间具有一致性（一个一致的备份/恢复，一个一致的故障转移单元），它在负载下的扩展性比 MSMQ 好得多，不需要双阶段-commit DTC 协调 MSMQ 出队与数据库插入（可以使用一个本地数据库事务来出队/插入），它提供待处理消息的可查询性（
SELECT .. FROM 队列），与这DB HA/DR 解决方案（集群故障转移/镜像），您将获得包含数据库激活 这一切都可以在熟悉的 T-SQL 编程环境中进行。 MSMQ 的主要优点是支持客户端 C#/.Net API。If you're looking at higher availability by queueing locally then you should consider Service Broker deployed on SQL Express instances collocated with your IIS/ASP instance. The advantage of using SSB over MSMQ is that you have consistency between your message store and your data store (one consistent backup/restore, one consistent failover unit), it does scale much better than MSMQ under load, it does not require tw-phase-commit DTC to coordinate the MSMQ dequeue with the DB insert (can use one local DB transaction to dequeue/insert), it offers queryability of the pending messages (
SELECT .. FROM queue), is integrated with the DB HA/DR solution (cluster failover/mirroring), you get DB contained activation and it all works from the familiar T-SQL programming environment. MSMQ's main advantage is support of a client side C#/.Net API.我所在的团队为了保证交付而实施了这一点。我们使用 MSMQ 将插入请求转发到数据库服务器，数据库服务器运行着自己的服务，该服务使请求出队并运行插入，然后确认消息（以确保传递）。它已经运行了一年多了，我们从未被要求找出它不起作用的原因......对我来说似乎很可靠。
I was on a team that implemented this for purposes of guaranteed delivery. We used MSMQ to forward the insert requests to the database server, which had its own service running that dequeued the requests and ran the inserts, then acknowledged the message (to ensure delivery). It's been running for over a year now, and we've never been asked to come figure out why it isn't working...seems pretty solid to me.
这是非常主观的，因为它取决于您的应用程序的用途和方式。一般来说，像 MSMQ 这样的东西不用于此目的，而是您希望在您选择的数据库上设置某种高可用性集群。在大多数情况下，数据库完全关闭的情况很少见，对于大多数 LOB 应用程序来说，这通常是一个更大的问题，而不仅仅是在数据库因某种原因关闭时存储输入的数据。
还有一些开销需要考虑。对数据库的 INSERT 操作相对较快（在更大的方案中）；将序列化的某物写入队列并让某物拾取它并执行插入操作会给您的应用程序增加大量滞后，更不用说以下事实：您必须考虑到现在一切都是异步的这一事实。
也就是说，MSMQ可以用于确保将内容从应用程序的一端传送到另一端，因此我认为在某些情况下这种情况可能是理想的。大多数时候，您最好信任您的数据库并使用 MSMQ 来启用异步处理并执行进程间和机器间通信。
This is very subjective because it depends on what your application does and how. Generally, something like MSMQ is not used for this purpose, rather you want to set up some kind of high-availability clustering on your database of choice. The occurrence of a database going completely down is rare in most cases, and generally a bigger problem for most LOB applications than just having somewhere to store data entered while the DB is down for whatever reason.
There's also overhead to think about. An INSERT operation to a database is relatively quick (in the larger scheme of things); writing a serialized something into a queue and having something pick it up and do that insert operation is going to add large amounts of lag to your application, not to mention the fact that you'll have to account for the fact that now everything is asynchronous.
That said, MSMQ can be used to ensure delivery of stuff from one end of an application to another, so I suppose there are instances where this scenario might be desirable. Most of the time though you're just better off trusting your DB and using MSMQ to enable asynchronous processing and performing interprocess and intermachine communication.