1. 訊息順序

場景：比如下單操作，下單成功之後，會發布建立訂單和扣減庫存訊息，但扣減庫存訊息執行會先於建立訂單訊息，也就說前者執行成功之後，才能執行後者。

不保證完全按照順序消費，在 MQ 層面支援訊息的順序處理開銷太大，為了極少量的需求，增加整體上的複雜度得不償失。

所以，還是在應用層面處理比較好，或者業務邏輯進行處理。

應用層解決方式：

• 1. 訊息實體中增加：版本號 & 狀態機 & msgid & parent_msgid，通過 parent_msgid 判斷訊息的順序（需要全域性儲存，記錄訊息的執行狀態）。
• 2. “同步執行”：當一個訊息執行完之後，再發佈下一個訊息。

2. 訊息冪等、訊息重複、訊息事務

訊息重複

造成訊息重複的根本原因是：網路不可達。只要通過網路交換資料，就無法避免這個問題。所以解決這個問題的辦法就是繞過這個問題。那麼問題就變成了：如果消費端收到兩條一樣的訊息，應該怎樣處理？

消費端處理訊息的業務邏輯保持冪等性。

保證每條訊息都有唯一編號且保證訊息處理成功與去重表的日誌同時出現。

第 1 條很好理解，只要保持冪等性，不管來多少條重複訊息，最後處理的結果都一樣。第 2 條原理就是利用一張日誌表來記錄已經處理成功的訊息的 ID，如果新到的訊息 ID 已經在日誌表中，那麼就不再處理這條訊息。

第 1 條解決方案，很明顯應該在消費端實現，不屬於訊息系統要實現的功能。第 2 條可以訊息系統實現，也可以業務端實現。正常情況下出現重複訊息的概率其實很小，如果由訊息系統來實現的話，肯定會對訊息系統的吞吐量和高可用有影響，所以最好還是由業務端自己處理訊息重複的問題，這也是 RabbitMQ 不解決訊息重複的問題的原因。

RabbitMQ 不保證訊息不重複，如果你的業務需要保證嚴格的不重複訊息，需要你自己在業務端去重。

AMQP 消費者確認機制

AMQP 定義了消費者確認機制（message ack），如果一個消費者應用崩潰掉（此時連線會斷掉，broker 會得知），但是 broker 尚未獲得 ack，那麼訊息會被重新放入佇列。所以 AMQP 提供的是“至少一次交付”（at-least-once delivery），異常情況下，訊息會被重複消費，此時業務要實現冪等性（重複訊息處理）。

AMQP 生產者事務

對於生產者，AMQP 定義了事務（tx transaction）來確保生產訊息被 broker 接收併成功入隊。TX 事務是阻塞呼叫

TX 的阻塞呼叫使 broker 的效能非常差，RabbitMQ 使用 confirm 機制來優化生產訊息的確認。Confirm 模式下，生產者可以持續傳送訊息，broker 將訊息批量寫磁碟後回覆確認，生產者通過確認訊息的ID來確定哪些已傳送訊息被成功接收。Confirm 模式下生產者傳送訊息和接受確認是非同步流程，生產者需要快取未確認的訊息以便出錯時重新發送。

總結

• 1. 訊息重複釋出：不存在，因為 AMQP 定義了事務（tx transaction）來確保生產訊息被 broker 接收併成功入隊。TX 事務是阻塞呼叫，生產者需等待 broker 寫磁碟後返回的確認，之後才能繼續傳送訊息。事務提交失敗時（如 broker 宕機場景），broker 並不保證提交的訊息全部入隊。RabbitMQ 使用 confirm 機制來優化生產訊息的確認（可以持續釋出訊息，但會批量回復確認）。
• 2. 訊息重複消費：AMQP 提供的是“至少一次交付”（at-least-once delivery），異常情況下，訊息會被重複消費，此時業務要實現冪等性（重複訊息處理）。

應用層解決方式：

• 1. 專門的 Map 儲存：用來儲存每個訊息的執行狀態（用 msgid 區分），執行成功之後更新 Map，有另外訊息重複消費的時候，讀取 Map 資料判斷 msgid 對應的執行狀態，已消費則不執行。
• 2. 業務邏輯判斷：訊息執行完會更改某個實體狀態，判斷實體狀態是否更新，如果更新，則不進行重複消費。

特別說明：AMQP 協議中的事務僅僅是指生產者傳送訊息給 broker 這一系列流程處理的事務機制，並不包含消費端的處理流程。

3. 叢集

原 RabbitMQ 叢集：manager1、manager2、manager3 節點均為磁碟儲存，manager1 為主節點，HAProxy 負載三個節點。

現 RabbitMQ 叢集更新（更合理的配置）：

• 1. RabbitMQ 叢集更新：manager1、manager2 節點型別改為 ram（記憶體儲存），manager3 節點型別為 disc（磁碟儲存，用於儲存叢集配置和元資料），主節點變更為 manager3。
• 2. HAProxy 負載更新：移除 manager3 負載（5672 埠），只保留 manage2、manager2 負載。

4. Kafka 和 RabbitMQ 對比

Kafka 應對場景：訊息持久化、吞吐量是第一要求、狀態由客戶端維護、必須是分散式的。Kafka 認為 broker 不應該阻塞生產者，高效的磁碟順序讀寫能夠和網路 IO 一樣快，同時依賴現代 OS 檔案系統特性，寫入持久化檔案時並不呼叫 flush，僅寫入 OS pagecache，後續由 OS flush。

這些特性決定了 Kafka 沒有做“確認機制”，而是直接將生產訊息順序寫入檔案、訊息消費後不刪除（避免檔案更新），該實現充分利用了磁碟 IO，能夠達到較高的吞吐量。代價是消費者要依賴 Zookeeper 記錄佇列消費位置、處理同步問題。沒有消費確認機制，還導致了 Kafka 無法瞭解消費者速度，不能採用 push 模型以合理的速度向消費者推送資料，只能利用 pull 模型由消費者來拉訊息（消費者承擔額外的輪詢開銷）。

如果在 Kafka 中引入消費者確認機制，就需要 broker 維護訊息消費狀態，要做到高可靠就需要寫檔案持久化並與生產訊息同步，這將急劇降低 Kafka 的效能，這種設計也極類似 RabbitMQ。如果不改變 Kafka 的實現，而是在 Kafka 和消費者之間做一層封裝，還是需要實現一套類似 RabbitMQ 的消費確認和持久化機制。

參考資料：