RabbitMQ RabbitMQ的一些基礎概念

工作中使用的是rabbitmq，需要對其進行熟悉。使用之前，弄清楚它是什麼東西，解決什麼問題。

開發中，有一些任務並無須實時執行，比如：

如上，儲存日誌表、傳送郵件等任務的實時性並不強，在系統繁忙時有可能阻塞，堵塞容易導致任務失敗。

如果我們把它們放入佇列中，輪候執行，減低耦合的同時，是不是也緩解了系統壓力。

系統開發中，快取的運用緩解了資料庫原始資料讀的壓力。一般來說，系統有多份快取。如果資料庫記錄發生更新，需要通知各快取更新最新記錄時，佇列發布和訂閱模式就發揮作用了。

生產：將訊息傳送到佇列。傳送訊息的程式，稱為生產者。

生產者傳送的訊息到達佇列，佇列是乙個緩衝區，暫存訊息，訊息最終會**給消費者。

可以想象佇列就是郵局，只不過郵局處理的是信件，rabbitmq處理的是二進位制的訊息。

消費，從佇列中獲取訊息，並處理訊息。消費訊息的程式，稱為消費者。

交換器是介於生產者、佇列之間，交換器按「路由策略」將訊息路由到佇列中，而路由策略有幾種：direct、fanout、topic、headers。

簡要介紹前兩個：

訊息的流向：生產者》交換器》佇列》消費者。

任務佇列，為了避免實時執行資源密集型的任務，我們把要做的任務，封裝成訊息放入佇列，工作執行緒在後台執行並執行這些任務。

在發布/訂閱模式中，有乙個生產者和兩個消費者，生產者傳送a訊息，兩個消費者均需接受到訊息。

生產者向佇列傳送訊息，消費者監聽佇列等待訊息，所以，在傳送訊息和消費訊息前要宣告佇列。

大多數情況，我們不能確定生產者還是消費者誰先啟動，所以，我們在兩者中都作宣告，rabbitmq允許對相同佇列相同引數作重複宣告，即對於二次宣告動作不做操作。

如果對同一佇列名不同引數作二次宣告，會返回錯誤。

為了保證訊息不丟失，rabbitmq有訊息確認機制，訊息確認機制預設是開啟的。

當消費者接收訊息並處理完畢，需傳送乙個確認給rabbitmq，rabbitmq就會從佇列中刪除此訊息。

rabbitmq允許消費者處理訊息任意長的時間，只有消費者退出了，rabbitmq才會將訊息重新輪候，不存在超時重新輪候的情況。

如果忘了確認，或確認過程中失敗了，訊息會在消費者退出後，rabbitmq才將訊息重新輪候。rabbitmq會因不能釋放未確認的訊息而消耗更多空間，如何檢視未確認的訊息，請搜尋messages_unacknowledged。

如果消費者宕機，我們通過訊息確認機制尋回訊息，如果rabbitmq宕機，為了避免丟失訊息，我們要設定訊息持久化：

注意：此方法嚴格來說不能完全保證訊息不會丟失，仍存在很短的時間間隙於rabbitmq接收了訊息但未寫磁碟。如果需要更強的機制保證，要使用publisher confirms（本文不作討論）。

預設情況下，rabbitmq採用迴圈的方式將訊息傳送給消費者。

有時，每個訊息對系統的消耗不同，有些訊息很快處理，有些則需花相當一段時間，所以，我們經常用basicqos(int n)方法告訴rabbitmq不要同時分配多於n個訊息給同一消費者。比如設定basicqos(1)，就是在消費者未確認訊息前，不要給它分配下乙個訊息。