2011-05-27 65 views
0

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

我該如何執行此操作?

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

所以,這將是時間表:

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

出版者發送消息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.

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

回答

3

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

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

+0

我明白了。發佈者必須僅向一個隊列發送消息,並且不必爲每個訂閱者都發送消息。這些工作將由一名或多名工作人員完成。因爲發行商對所有用戶的每個訂閱者的速度太慢,數百或數千聽衆。 – Thomas 2011-05-27 20:24:53

+0

這是正確的。讓發佈者儘快發佈消息並堅持下去,並在生活中繼續前進。然後交付給用戶是解耦的,延期的,異步的......都很好。 :) – 2011-05-27 21:00:32

0

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

+0

看起來不錯。我會嘗試使用NServicebus運行一些示例。 – Thomas 2011-05-27 20:21:53