分佈式系統：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服務，直接或間接地（例如經由觸發），分佈式應用程序完全包含在數據庫中是用處不大的。