2010-07-15 65 views
1

我剛開始評估ServiceBroker以確定它是否可以在特定上下文中作爲可靠隊列執行。下面是這種情況:將SQL 2008 ServiceBroker用於大容量線程安全FIFO隊列

(1)需要在隊列中預先計算耗費計算值和存儲的大(幾百萬)人口。 (2)多個進程將嘗試在運行時根據需要讀取/出隊這些值。每秒可能有數百次讀取。

(3)的監視器處理偶爾會輪詢隊列和確定是否人口最小閾值已達到,並隨後將重新填充隊列。

由於一些基礎設施/成本的限制,工業強度隊列(websphere)可能不是一個選項。我目前看到的Service Broker並不令人鼓舞,因爲它似乎與2個端點的「對話」隔離開來,在我的場景中,我的閱讀完全獨立於我的寫作。有沒有人有任何洞察力,這是否可以使用SQL Service Broker?

回答

0

雖然服務代理並沒有被設計爲這樣的場景,我覺得有一點扭捏它可以在你的情況下工作。

一種方法是預先創建一個會話的池,然後有論文對話之間的計算處理循環存儲值時。由於從隊列接收會話對會話鎖定,因此對話數量本質上設置了有多少進程可同時出列值的上限。我不確定這一點,但是您可能需要接收端的一些邏輯來明確地告訴接收來自哪個對話(以實現比默認接收行爲更好的負載平衡)。

如果PERF的不關心,那麼你可能甚至有所下降,談話池想法,在一個單獨的對話,這將使在顯著PERF命中的成本實現更簡單的方式發送每封郵件。

所有上述據說這種假定可能以隨機順序出列的值,否則,你需要使用一個單一的談話,以保證接受訂貨。