大概從 2013 年開始，我就開始了本身和 RabbitMQ 的接觸，到如今已經有七年多了。java

在這七年中，既有一些對 RabbitMQ 的深度體驗，更有無數的血淚史。程序員

而根據我這麼多年的使用經驗，我將 RabbitMQ 的心得造成一些提醒或者規範分享給你們，這樣，你們之後使用 RabbitMQ 的時候，就不會再走我走過的彎路了。數據庫

我想把我這些關於 RabbitMQ 的經驗和心得，分紅三篇來寫：服務器

此次我們先從開發前的規範開始談起。網絡

我曾經一直都很奇怪，爲什麼你們使用開發語言有開發規範，使用數據庫有數據庫規範，可是使用 MQ 卻不多見一些規範。框架

使用 MQ 缺乏規範，這是廣泛的問題？還只是我身邊的個例？優化

無論答案是哪一個，在 RabbitMQ 使用時，爲了不在開發中少出現問題，爲了事半功倍，都須要提早規範好一些配置和事項。設計

1. 一個 RabbitMQ 應用裏創建多個 vhost，去對應不一樣的開發項目

咱們在使用數據庫的時候，會在一個數據庫應用裏創建多個不一樣的數據庫去給不一樣的項目使用，而不用在不一樣的服務器專門每一個項目都安裝個數據庫應用。隊列

在 RabbitMQ 的 vhost，也是相似的理念。進程

vhost 本質上是一個 mini 版的 RabbitMQ 服務器，擁有本身的隊列、綁定、交換器和權限控制，當在 RabbitMQ 中建立一個用戶時，用戶一般會被指派給至少一個 vhost，而且只能訪問被指派 vhost 內的隊列、交換器和綁定，vhost 之間是絕對隔離的。

因此，不一樣的 vhost 對應不一樣的項目，互不影響，而這些 vhost 其實都是在一臺主機一個 RabbitMQ 應用上。

可是，如今的情況是大部分使用 RabbitMQ 的技術團隊每每就使用默認的 vhost：「/」，若是多出一個項目了，就再去建立一個 RabbitMQ 的進程。這樣作，很是浪費開發資源。

推薦一個項目對應一個 vhost。

2. 不直接使用 RabbitMQ 本身的客戶端

不少公司使用 RabbitMQ 都是直接使用 RabbitMQ 本身的 java 版本客戶端，可是因爲 RabbitMQ 自己內在的複雜性和多樣性，有不少技術細節須要獨自處理。

好比網絡鏈接的處理，好比異常的處理，好比消息失敗的處理等等等。這些，若是手頭沒有一套成熟的框架，那麼極可能因爲一些細節處理不到位，致使很是多的問題，這都是沒必要要的成本。

因此，要麼使用一套已有的 RabbitMQ 客戶端框架（好比 Spring 的 RabbitMQ 框架），要麼本身封裝出一套底層 RabbitMQ 客戶端框架，而不是單獨使用 RabbitMQ 的客戶端

ACK 機制就是消費者從 RabbitMQ 收到消息並處理完成後，反饋給 RabbitMQ，而後 RabbitMQ 收到反饋後纔將此消息從隊列中刪除。

因爲 ACK 機制自己必須回覆給 RabbitMQ，消息纔會丟棄這個特色。對於什麼時候給 ACK，咱們作開發的時候必定要在開發項目前提早規劃好、設計好。

咱們使用 RabbitMQ 一般不想在收到消息就當即給回 ACK 的，也不會設置 autoACK 機制即消費端收到自動返回一個 ACK 響應。通常來說，咱們都會根據業務邏輯的不一樣，會在不一樣的位置手動返回 ACK。

這時候，就可能出現問題：當收到消息，有時候處理業務邏輯報錯了，每每在處理完業務邏輯就會忽略 ACK，這會致使消息始終卡死在 queue 裏……若是數量愈來愈多，後續處理很是麻煩。

爲何那麼多人不設置 dead letter exchanges？這是我很是疑惑的點。

出去和各種使用 RabbitMQ 的項目團隊交流，發現不多人設置了 dead letter exchanges。這個是有問題的。

咱們得知道，有時候消息投遞出錯，並不老是在應用接收的時候出了問題，會有不少非應用的問題。好比：

對於這些問題，設置 dead letter exchanges 算是一個解決辦法。

當消息一旦出現我上面列舉出來的狀況，就會被髮送到咱們設置的 dead letter exchanges。而後咱們就能夠對這些特殊狀況的消息進行單獨處理，這樣的作法可讓咱們的項目更健壯，更容易追蹤問題。

RabbitMQ 的Exchange 就是消息交換機，它指定消息按什麼規則，路由到哪一個隊列。

這傢伙有四種類型：

Direct：處理路由鍵，須要將一個隊列綁定到交換機上，要求該消息與一個特定的路由鍵徹底匹配。這是一個完整的匹配。若是一個隊列綁定到該交換機上要求路由鍵爲「green」，則只有路由鍵爲「green」的消息才被轉發，不會轉發路由鍵爲"red"，只會轉發路由鍵爲「green」。
Topic：將路由鍵和某模式進行匹配。此時隊列須要綁定要一個模式上。符號「#」匹配一個或多個詞，符號「*」只能匹配一個詞。
Fanout：不處理路由鍵。你只須要簡單的將隊列綁定到交換機上。一個發送到該類型交換機的消息都會被廣播到與該交換機綁定的全部隊列上。
Headers：不處理路由鍵，而是根據發送的消息內容中的 headers 屬性進行匹配。在綁定 Queue 與 Exchange 時指定一組鍵值對；當消息發送到 RabbitMQ 時會取到該消息的 headers 與 Exchange 綁定時指定的鍵值對進行匹配；若是徹底匹配則消息會路由到該隊列，不然不會路由到該隊列。

在這四種類型裏，Direct 類型的 Exchange 投遞消息是最快的。其餘的 Exchange，MQ還得花時間計算投遞的位置。

因此，能使用 Direct 類型的建議使用 Direct。

以上就是在使用 RabbitMQ 前，須要考慮使用的規範，有了這些規範，不少程序員就能據此寫出比較穩定健壯的程序，而不會致使各類莫名其妙的問題。

強烈建議你們在團隊使用以前，先弄一份規範。不然，若是不少程序員使用 RabbitMQ 很是隨意，容易致使出現各類幺蛾子問題。

在下一篇文章裏，我將寫一些開發中須要注意的事項。

雖然說是開發須要注意的事項，其實就是我在開發一套成熟的 RabbitMQ 客戶端框架時，碰到的各類問題的總結。若是有些讀者所在的開發團隊剛好也有相似的經歷，那麼我說的全部問題，你會發現你可能都會遇到。

咱們下篇文章見！