實現耐用的pub/sub？

Question

比方說，我有一個發佈者和多個聽衆。發佈者發送消息時，必須由所有聽衆接收。如果其中一個聽衆倒閉了，他應該在他再次回來的時候收到留言。

我該如何執行此操作？

我正在考慮使用隊列： 每個偵聽器都使用它自己的隊列，並使用隊列的位置向發佈者發送子郵件消息。發佈者將位置保存到文件或數據庫，並開始將其消息發送到該隊列。

所以，這將是時間表：

出版商開始。還沒有聽衆。

出版者發送消息1.

出版者發送消息2

出版者發送消息3

監聽器1開始，並與發佈者所預訂。

出版者發送消息4

監聽器1接收消息4

監聽器2開始並與發佈者所預訂。

出版者發送消息5

監聽器1接收消息5

監聽器2接收消息5

監聽器2 chrashes。

出版者發送消息6

監聽器1接收消息6

出版者發送消息7.

監聽器1接收消息7.

監聽器2恢復時，沒有必要再次訂閱。

監聽器2接收消息6

監聽器2接收消息7.

底線是我需要每一個監聽器隊列中，和一個隊列或信道來發送和接收關於「開始聽」消息和'停止聆聽'。 我在正確的方向思考，還是我完全錯了？

Answer 1

你不應該需要一個單獨的隊列每個用戶，但你至少需要兩個隊列。可擴展性的最初關鍵在於確保當發行商提供初始信息時，您不會在當時及時向所有用戶「扇出」它。相反，您將其放在收到的隊列中，並立即返回，讓發佈商知道它已成功。從那裏你有由主接收隊列饋送的工作人員，他們的責任是將消息「扇出」給各個用戶。它通過計算出這些訂閱者是誰，並通過每個偵聽器的地址/綁定信息生成包含來自發布者的原始郵件的N條消息並將其放到傳遞隊列中來實現。最後，您有負責將消息從交付隊列中拉出並嘗試使用地址/綁定信息進行交付的工作人員。

處理傳遞錯誤的方式可能是將郵件移動到重試隊列中，郵件在傳遞隊列中被重新替換之前將被放置X個時間。那麼你當然必須處理重試5次的有害信息，而聽衆每次都會給你帶來錯誤。那些需要移動到某種錯誤報告的死信隊列中。

Answer 2

你是對的，這正是NServiceBus（例如）在MSMQ之上實現pub-sub的方式。在這裏閱讀更多關於它：http://docs.particular.net/samples/pubsub/。