大概從 2013 年開始，我就開始了自己和 RabbitMQ 的接觸，到現在已經有七年多了。
在這七年中，既有一些對 RabbitMQ 的深度體驗，更有無數的血淚史。
而根據我這麼多年的使用經驗，我將 RabbitMQ 的心得形成一些提醒或者規範分享給大家，這樣，大家以後使用 RabbitMQ 的時候，就不會再走我走過的彎路了。
我想把我這些關於 RabbitMQ 的經驗和心得，分成三篇來寫：
- 開發前的規範；
- 開發中的注意事項；
- 以及 MQ 本身的優化。
這次我們們先從開發前的規範開始談起。
我曾經一直都很奇怪，為何大家使用開發語言有開發規範，使用資料庫有資料庫規範，但是使用 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 的客戶端
3. 無論如何消費者必須給回 ACK 響應
ACK 機制就是消費者從 RabbitMQ 收到訊息並處理完成後，反饋給 RabbitMQ，然後 RabbitMQ 收到反饋後才將此訊息從佇列中刪除。
由於 ACK 機制本身必須回覆給 RabbitMQ，訊息才會丟棄這個特點。對於何時給 ACK，我們做開發的時候一定要在開發專案前提前規劃好、設計好。
我們使用 RabbitMQ 通常不想在收到訊息就立即給回 ACK 的，也不會設定 autoACK 機制即消費端收到自動返回一個 ACK 響應。一般來講，我們都會根據業務邏輯的不同，會在不同的位置手動返回 ACK。
這時候，就可能出現問題：當收到訊息，有時候處理業務邏輯報錯了，往往在處理完業務邏輯就會忽略 ACK，這會導致訊息始終卡死在 queue 裡……如果數量越來越多，後續處理非常麻煩。
4. 考慮設定 dead letter exchanges
為什麼那麼多人不設定 dead letter exchanges？這是我非常疑惑的點。
出去和各類使用 RabbitMQ 的專案團隊交流，發現很少人設定了 dead letter exchanges。這個是有問題的。
我們得知道，有時候訊息投遞出錯，並不總是在應用接收的時候出了問題，會有很多非應用的問題。比如：
-
消費端有問題，發出的訊息被拒絕了。並且我們也設定了 requeue=false；
-
訊息可能因為沒有收到 ACK 超時被刪除，或者消費端消費速度跟不上導致訊息超時被刪除；
-
訊息數量超過了佇列最大長度限制被拋棄；
-
訊息總大小超過了佇列訊息總大小限制被拋棄。
對於這些問題，設定 dead letter exchanges 算是一個解決辦法。
當訊息一旦出現我上面列舉出來的情況，就會被髮送到我們設定的 dead letter exchanges。然後我們就可以對這些特殊情況的訊息進行單獨處理，這樣的做法可以讓我們的專案更健壯，更容易追蹤問題。
5. 儘量使用 Direct Exchange
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 客戶端框架時，碰到的各種問題的總結。如果有些讀者所在的開發團隊恰好也有類似的經歷，那麼我說的所有問題，你會發現你可能都會遇到。
我們下篇文章見！
我準備了一些純手打的高質量PDF：
深入淺出Java多執行緒、HTTP超全彙總、Java基礎核心總結、程式設計師必知的硬核知識大全、簡歷面試談薪的超全乾貨。別看數量不多，但篇篇都是乾貨，看完的都說很肝。
領取方式：掃碼關注後，在公眾號後臺回覆：666
我最近建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
