分布式系统：sql服务器代理实现

Question

我有一个由8个服务器组成的分布式应用程序，所有服务器都运行.NET windows服务。每个服务都会查询数据库以查找可用的工作包。

轮询机制对于其他原因很重要（现在太无聊了）。

我在考虑这个轮询机制最好在队列中实现，因为.NET服务都将定期轮询数据库，并且在负载不足时我不想死锁。

我在想我会希望每个.NET服务都将消息放入输入队列。数据库服务器将一次一个地弹出输入队列的每条消息，对其进行处理，并将回复消息放在另一个队列中。

我遇到的问题是SQL Server Broker（SSB）的大多数示例都位于数据库服务之间，而不是从.NET客户端启动。我想知道SQL Server Broker是否只是这项工作的错误工具。我发现代理T-SQL DML可从.NET获得，但我认为这应该起作用的方式似乎不适合SSB。

我认为我需要一个带有2个队列（进出）和单个激活存储过程的SSB服务。

这似乎不是SSB的工作方式，我错过了什么吗？

Answer 1

你得到的画面非常正确的，但也有一些缺失的拼图在图片：

• SSB主要是一种通信技术，旨在通过网络与恰好一次-IN-传递消息命令语义学（EOIO），以完全交易的方式。它处理网络连接（身份验证，流量机密性和完整性）以及传输的确认和重试逻辑。
• Internal Activation是一项独特的技术，它消除了居民服务轮询队列的要求。轮询无法实现低负载下低延迟和低资源消耗所需的动态平衡。轮询强制实施高延迟（不频繁轮询以节省资源）或高资源利用率（提供低延迟所需的频繁轮询）。内部激活还具有自我调节功能，能够增加更多处理器以应对负载尖峰（通过max_queue_readers），同时仍能够通过停用处理器来调低低负载下的处理能力。内部激活机制常常被忽视的一个优点是完全包含在数据库中的事实，即。它通过集群或数据库镜像故障切换进行故障切换，并在备份和复制附加操作中与数据库一起传输。还有一个External Activation机制，但总体上我更倾向于内部一个任何适合的内部环境（例如，不和HTTP请求，必须在引擎进程之外处理...）
• Conversation Group Locking又是唯一的，并且是提供对相关消息处理的独占访问的手段。应用程序可以利用conversation_group_id作为业务逻辑密钥，即使在繁重的多线程中，也可以完全消除死锁。

还有一个问题是您错误地了解Service Broker：需要将响应放入单独的队列中。与大多数您可能熟悉的排队产品不同，SSB原语不是消息，而是“对话”。一个对话是一个全双工的双向通信通道，你可以把它想象成一个TCP套接字。 SSB服务不需要'将响应放在队列中'，而是可以简单地在接收到的消息的对话句柄上发送响应（很像你如何在TCP套接字服务器中响应，通过在上发出send你得到了请求的套接字，而不是通过打开一个新套接字并发送响应）。此外SSB会照顾固有消息相关，使发送者就会知道到底响应属于要求寄给其，由于响应会回来同一个会话处理请求的（发送很像一个TCP套接字的情况下，客户端从它发送请求的同一套接字上的服务器接收到响应）。当涉及相关会话组的关联锁定时，此对话句柄又很重要，请参阅上面的链接。

可以经由SQLCLR嵌入.NET逻辑到服务代理处理。几乎所有的SSB applciations在至少一个端部具有非SSB服务，直接或间接地（例如经由触发），分布式应用程序完全包含在数据库中是用处不大的。