RabbitMQ 的五種工作模式

RabbitMQ主要使用場景

1. 程式解耦利器
2. 流量消峰
3. 非同步處理

5種模式的GO 程式碼實現： https://github.com/guohewei123/rabbitmq_worker_mode

一. Simple模式

• 生產者傳送訊息到佇列中，消費中從佇列中獲取訊息。每個訊息只能被一個消費著消費，即：當訊息被消費者獲取後，該訊息將會在佇列中移除。這中模式也可以成為“閱後即焚”。

• 隱患: 訊息可能沒有被消費者正確處理，已經從佇列中消失了，造成訊息的丟失

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode

二. 工作模式

• 一個生產者、多個消費者；一個訊息只能被一個消費者獲取。
• 在這種模式中又可以分為兩種模式，
  • 輪詢模式：每個消費者均分訊息
  • 公平分發模式（能者多勞）：按能力分發，處理速度快的分發的多，處理速度慢的分發的少

1. 輪詢模式

輪詢模式無論有多少個消費者，不管每個消費者處理訊息的效率，都會將所有訊息平均的分發給每一個消費者，也就是說，大家最後各自消費的訊息數量都是一樣多的。

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode

2. 訊息丟失

• 開啟了自動應答，如果訊息佇列將訊息分發給消費者，那麼就會從佇列中刪除，如果在我們處理任務的過程中，處理失敗或者伺服器宕機，那麼這條訊息肯定得不到執行，就會出現丟失。
• 如果任務在處理的過程中，如果伺服器宕機等原因造成訊息未被正常消費，那麼必須分發給其他的消費者再次進行消費，這樣即使伺服器宕機也不會丟失任何的訊息了。
• 所以ACK，就是訊息應答機制，如果程式碼是開啟了自動應答，我們的訊息沒被正常消費，就會丟失。
• 要想確保訊息不丟失，就必須將ACK自動應答關閉掉，在我們處理訊息的流程中，如果訊息正常被處理，那麼最後進行手動應答，告訴佇列我們正常消費了訊息。
• RabbitMQ它是沒有我們平常所見到的超時時間限制的，只要當消費者服務宕機，訊息才會被重新分發，哪怕處理這條訊息需要花費很長的時間。

3. 公平分發訊息與訊息應答（ACK）

• 我們提供多個消費者，目的就是為了提高系統的效能，提升系統處理任務的速度，如果將訊息平均的分發給每個消費者，那麼處理訊息快的服務是不是會空閒下來，而處理慢的服務可能會阻塞等待處理，這樣的場景是我們不願意看到的。

• 所謂的公平分發，其實用能者多勞描述更為貼切，根據名字就可以知道，誰有能力處理更多的任務，那麼就交給誰處理，防止訊息的擠壓。

• 那麼想要實現公平分發，那麼必須要將自動應答改為手動應答。這是公平分發的前提。

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode

三. Publish/Subscribe, 訂閱模式

• 訊息被路由投遞給多個佇列，一個訊息被多個消費者獲取。

• 相關場景：郵件群發，群聊天，廣播 (廣告)

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode

四. Routing, 路由模式

• 一個訊息被多個消費者獲取。並且訊息的目標佇列可被生產者指定。

• 交換機的型別是 direct 型別 在訂閱模式下是 faout 廣播型別

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode

五. Topic, 話題模式

• 一個訊息被多個消費者獲取。訊息的目標queue可用BindingKey，以萬用字元的方式指定。（#：匹配一個或多個詞，*：匹配一個詞）

• Go實現程式碼：https://github.com/guohewei123/rabbitmq_worker_mode