2016-03-05 154 views
0

我會很感激你的想法。RabbitMQ用戶將消息發送回RabbitMQ隊列?

我有一個訂閱RabbitMQ隊列的節點應用程序。當它收到一條消息時,它會檢查它的內容並將其保存到數據庫中。

但是,如果郵件丟失,某些信息或其他條件尚未滿足,我希望訂閱者將郵件發佈回RabbitMQ隊列。

我從邏輯上理解這只是連接到隊列併發布消息,但這真的很簡單,或者這是一種不好的做法或潛在的危險?

感謝您的幫助。

+0

當消息丟失的東西,然後發佈到同一隊列接收消息從它?如果是這樣,你可以設置'autoack'爲'false',並且消息從隊列中移除,除非你給予確認。那麼如果消息缺少某些東西,則不會確認,並且此消息將保留在隊列中而不被刪除。如果消息是goo,給這個隊列ack,那麼這個消息將從隊列中移除。 – zangw

+0

@zangw是發佈到它從中獲取消息的同一隊列。 (這很難解釋,但是有一個時間元素的消息,所以它可能在5分鐘內而不是現在有效)。 –

回答

1

正如我在評論中指出的那樣,當您創建與隊列的連接並設置autoAck = true時,啓用消息確認。隊列中的消息將被刪除,直到收到確認。

當收到的消息符合要求時,發送確認消息到該隊列中,並且該消息將從隊列中刪除。否則,不向隊列發送確認消息,該消息將留在隊列中。

至於您在評論中提到的有效過程可能需要5分鐘,只需將發送確認消息設置爲驗證功能的回調函數即可。

0

在你的問題,你描述兩個標準時,可能沒有被處理的消息:

  1. 如果消息缺少某些信息或
  2. 其他一些標準尚未滿足

其中的第一個看起來是這個消息的一個問題,並且對重新排隊有問題的消息似乎沒有多大意義。適當的操作是記錄錯誤並放棄消息(或調用應用程序包含的任何錯誤處理邏輯)。

其中第二個比較含糊,但爲了這個答案的目的,我們將假設問題不在消息中,而與系統中的其他組件(例如網絡連接問題)有關。在這種情況下,消費應用程序可以發送一個Nack (negative acknowldegement),它可以選擇性地重新發送消息。

請記住,在第二種情況下,有必要關閉消費者,直到錯誤狀態解決,或者消息將被重新遞送並在系統備份之前被無限處理,直至系統備份,從而浪費資源在一個不可處理的消息。

爲什麼要用nack而不是簡單地重新發布?
這將在消息上設置「redelivered」標誌,以便您知道它已交付一次。有other options以及處理壞消息。