RabbitMQ學習(九):AMQP 0-9-1 協議之Queues

說明

通過上篇博文翻譯了AMQP協議中有關交換機Exchange的相關介紹,本篇博文將繼續翻譯AMQP協議中有關隊列的內容,通過翻譯學習記錄AMQP模型中的另一實體Queue。

正文

Queues

AMQP 0-9-1模型中的隊列與其他消息任務隊列系統中的隊列十分相似:它們都存儲要被應用程序處理的消息。隊列和交換機共享一些屬性,同時它還有一些特別的屬性:

  • Name
  • Durable (持久化,若該屬性爲true,則在服務器重啓時隊列仍然存在)
  • Exclusive(獨佔性,當所屬的連接關閉時,隊列將會被刪除)
  • Auto-delete(當隊列的最後一個消費者取消訂閱時,隊列將會被自動刪除)
  • Arguments(可選,通常被插件或代理服務器的特定功能使用,比如消息的TTL, 隊列的長度限制等等)

在使用一個隊列之前,該隊列必須是已被聲明的。聲明一個不存在的隊列時,將會創建該隊列。如果聲明一個已存在的隊列,若使用與已存在隊列相同的屬性,則聲明不會對已存在的隊列造成任何影響,但屬性不一致時,會造成channel-leve(通道級別) 的異常PRECONDITION_FAILED,以code碼406表示。


Queue Names

應用程序會選擇一個隊列名稱或者讓代理服務器爲其生成一個名字。隊列名稱最多可以是255個字節的utf-8字符,一個AMQP 0-9-1代理服務器可以產生一個唯一表示應用程序的隊列名稱。爲使用此特性,可以設置隊列的名稱屬性爲空字符串。產生的名稱將會被返回到聲明隊列的客戶端。

以“amq*”開頭的隊列名稱已經被代理服務器保留用於內部使用,當聲明隊列時使用了該類型的名稱時,將會造成通道級別的異常ACCESS_REFUSED,以code碼403表示。


Queue Durability

持久化的隊列將會被保存到硬盤上,所以他們可以在服務器重啓時存活。未被持久化的隊列稱爲瞬時態。並不是所有的使用場景都要求隊列持久化。

持久化的隊列並不會把發送到該隊列的消息進行持久化。如果一個代理服務器宕機後恢復,持久化的隊列將會在服務器重啓時重新被聲明,然而,只有那些被持久化的消息纔可以被恢復,其他未被持久化的消息和隊列將會丟失


Bindings

綁定是交換機在路由消息時使用的規則。爲了使發送到名爲E的交換機的消息可以路由到名爲Q的隊列,Q必須綁定到E。綁定時有一個可選的屬性–routing key,該屬性被某些類型的交換機使用。使用路由關鍵字的目的是在被髮送到交換機中的消息中選擇一些特定的消息路由到已綁定到該交換機的隊列。換句話說,路由關鍵字就像一個過濾器。

可以做一個類比:

  • 隊列就好像你的目的地紐約
  • 交換機就像JFK機場
  • 綁定就是從JFK到紐約的所有路線,可以有零個或多個路線到達

有了這層間接性,就可實現在使用直接發送消息到隊列方式時,一些難以實現的路由方案,同時可以大量減少程序開發人員的工作量。

如果AMQP消息不能被路由到任何隊列(比如,交換機沒有綁定任何隊列),在這種情況下消息將被丟棄或返回給發送者,這取決於發送者設置的消息屬性。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章