帶訂閱緩存的WCF Pub/Sub

Question

問題：如何使用WCF提供分佈式，可擴展和抗災難的pub/sub服務。

詳情：

注意，這種方法除了消息/中間件解決方案，如TIBCO EMS正在考慮中。

我一直在尋找到WCF，特別是它如何被用來提供酒吧/分。在這個問題上，這篇文章非常好：WCF pub-sub。

在這篇文章中，作者嘗試解決多個發佈者的問題（正如人們將服務層縮放到幾個盒子一樣）。問題是，如果客戶A向發佈者A註冊但發佈者B希望發佈事件，則發佈者B將不知道客戶端A.即沒有人告訴發佈者B客戶端A想要被通知事件。作者建議將pub/sub服務作爲解決方案。發佈/訂閱服務將集中存儲訂閱。但是，如果我想通過輔助/雙重發布/訂閱服務來使發佈/訂閱服務具有抗災能力，那麼我有相同的原始問題。

所以，我認爲有一對夫婦的問題的解決方案：

1. 在分佈式緩存存儲的用戶信息（見問題：q1和q2）。
2. 將訂戶詳細信息存儲在數據庫/中央文件系統中。

任何人都可以想到任何其他解決方案（即我沒有錯過WCF的一些奇妙的神奇功能？） 任何意見讚賞。

Answer 1

我有同樣的問題，我在這個問題上做了大量的研究。問題其實很簡單。你想保持一些集中的狀態，但分散的方式。我發現實現這一點的最佳方式是使用分佈式緩存。以速度爲例。我不知道可以解決州管理問題的本地WCF解決方案。我甚至研究過持久服務，其中狀態管理由WCF處理，但不適合發佈/訂閱服務，因爲狀態需要集中於所有客戶端連接。將數據存儲在數據庫中也是一種選擇，但成本是數據庫的需求，即使數據庫沒有羣集數據庫也會導致多臺計算機出現單點故障。最後，我認爲實現具有零故障點的東西實際上很昂貴，如果您決定去那裏，那麼看看Azure，存儲的未來就在雲端，Azure服務將會是完全可擴展和分佈式，但我們還沒有。

Answer 2

我認爲WCF還沒有。你需要的是一個經紀人，爲你處理所有這些細節，以便你可以實現你的業務邏輯。有一些非常好的例如ActiveMQ。如果你需要編排，那麼你可能想要使用一輛也可以坐在經紀人之上的公共汽車。我認爲WCF很棒，但嘗試將它變成不是的東西，這不是一個好主意。