代码之家 › 专栏 › 技术社区 › mwigdahl

SQL Server事务中非锁定消息的选项

messaging message-queue msmq transactions sql-server

-1

mwigdahl · 技术社区 · 16 年前

我维护一个基于SQL Server的应用程序,它要求我们向连接的客户端发送某些数据库更改的通知。这些客户端是胖客户端C++应用程序,它们具有高带宽连接到服务器。

到目前为止,我们一直在SQL Server中使用一个专用的消息传递表,该表通过相关表上的触发器进行更新。这样做的巨大缺点是,如果有人将导致消息插入打开较长时间的事务保留下来,那么针对该公共消息传递表的锁定会导致其他客户端(以及一般的消息传递)突然停止。

我们尝试使用扩展存储过程来直接连接应用程序的套接字,但当连接不可避免地出现问题时,这会导致类似的阻塞问题。

我真正想要的是从SQLServer内部(理想情况下是SQLServer2000和更高版本,但也可以使用SQLServer2008)启动某种消息的良好机制。信息必须:

可由任意客户端程序从数据库事务中读取,
快点。

持久性/有保证的交付非常好,但不是绝对需要的。

MSMQ MSMQ ,并且可以从扩展存储过程或CLR proc发出消息,但在这种情况下,它的防弹性和速度有多快?

如果您能提供任何建议,我们将不胜感激。

编辑:为了澄清,我需要一种方式来发送到至少一个应用程序以外的呼叫应用程序。这是通知/广播要求,因此下面的错误建议不合适。

3 回复 | 直到 16 年前

1

4

Remus Rusanu 16 年前

MSMQ支持事务,正确,但使用MSMQ意味着您将本地SQL事务注册到MSQM manager的分布式事务中。这将是一个成熟的分布式事务,涉及MSDTC和twoo阶段提交。您的事务吞吐量将因此受到非常严重的性能影响。

我会在这里推荐服务经纪人。

ServiceBroker将以非常高的吞吐量异步可靠地向同一数据库、同一实例或不同SQL Server实例中的队列传递消息。Service Broker不能用于直接将通知传递到客户端应用程序(即套接字连接回调),而是将消息传递到队列(SQL Server对象),客户端通过正常连接进行连接,并发出接收语句以将挂起的通知排出队列。ServiceBrokerAPI完全是Transact-SQL,因此您可以轻松地将其添加到触发器中。它的事务性,完全包含在SQL Server数据库中,并且不会将本地事务提升为分布式事务,因此能够实现 throughput of thousands of messages per second . 最大的缺点是它的学习曲线非常陡峭。

ServiceBroker将使用数据库中的锁进行操作,但如果使用正确,将不会导致争用。当健忘的Fred让他的事务保持打开状态并去吃午饭时,不会导致队列阻塞。他将阻止他使用的频道被重复使用(即ServiceBroker术语中的“对话”),但其他用户使用的其他频道则保持开放。接收端(应用程序侦听传递的地方)根本不会阻塞。类似地,如果健忘的Fred运行一个应用程序并去吃午饭,而他有一个未提交的事务将通知排入队列,这将不会阻止其他应用程序接收通知的能力,也不会阻止更多通知进入队列的能力,包括在Fred退出队列的通道上。因此,应用程序无法阻止通知(慢速应用程序无法暂停触发器),反之亦然。ServiceBroker的设计和实现是解耦的。

[完全披露:我是Service Broker团队的前成员。]

2

3

dance2die 16 年前

sqlserver2005&2008年报价 Service Broker ,这是一个消息队列系统。

你可以用 Service Broker activation 因此,消息可以“由任意客户端程序从数据库事务中读取”。

而且,由于ServiceBroker是SQLServer数据库引擎的一部分,它“不会给数据库增加额外的锁定负担”,而且应该“快速”(这完全取决于ServiceBroker的实现方式)

3

0

Andy Shellam 16 年前

你的错误呢?

http://technet.microsoft.com/en-us/library/ms178592.aspx

您的客户机可以侦听该消息,而您的存储过程/查询可以引发严重性不被视为错误的消息。