2017-09-24 55 views
0

我正在評估NATS以遷移現有的基於msg的軟件 我沒有找到有關msg超時異常和過載的文檔。 例如:Nats.io隊列訂閱行爲超時

  • 認購後一直選擇,是不是意識到發表出版商超時設置?是否可以通知額外的時間延長?
  • 如果當選用戶注意到某些DBMS連接丟失,無法完成,便有可能反彈的消息

NATS服務器將皮卡另一個用戶,並重新發布了同樣的信息?

僑 迭戈

+0

我注意到NATS Streaming Server也有Queue,並且有一個名爲* ManualAck *和重新傳遞行爲的選項(請參閱https://github.com/nats-io/nats-streaming-server/issues/186 ) –

回答

1

關於第一個問題:在我看來,你要發佈一個請求消息超時(使用nc.Request)。如果是這樣,則超時由客戶端管理。客戶有效地發佈請求消息並在回覆主題上創建訂閱。如果訂閱在超時時間內沒有收到任何消息,它會通知您超時條件並取消訂閱回覆主題。

關於你的第二個問題 - 你在使用隊列組嗎? NATS中的隊列組是指定隊列組名稱的預訂。具有相同隊列組名稱的所有訂閱都由服務器專門處理。服務器將選擇其中一個隊列組訂閱,以便在消息到達時發送消息以在它們之間旋轉。然而,服務器的責任僅僅是傳遞信息。

要做你所描述的,使用請求/應答使用超時和最大數量的消息等於1來實現你的功能。如果超時後沒有收到響應,你的客戶端可以在延遲一段時間後重新發送請求消息或執行一些其他類型的恢復邏輯。回覆消息應該是你的'協議',以知道消息處理正確。請注意,這將進入消息體系結構的設計。例如,在請求收件人收到消息並處理它之後,但在客戶端或服務器能夠發佈響應之前,可能會觸發超時。在這種情況下,請求發送者將無法區分差異並最終重新發布。這暗示了這種類型的交互需要使這些請求具有冪等性以防止重複的副作用。

+1

另外NATS Streaming是完全不同的事情。 NATS流媒體服務器捕獲日誌中的所有消息。 NATS流媒體服務器將日誌重放到NATS流媒體訂戶。與NATS類似,用戶可以是隊列組的成員,並且日誌中的消息將在隊列組成員之間分配。 –

+0

非常感謝您的建議!我同意你的最後一句話:_...使這些請求具有冪等性,以防止重複的副作用...... _這正是我必須在當前pub/sub體系結構中編碼的關鍵代碼塊。我會將我的測試環境克隆到一個簡單的NATS pub sub中,然後我將重新測試所有恢復場景。 –