大概從 2013 年開始，我就開始了自己和 RabbitMQ 的接觸，到現(xiàn)在已經(jīng)有七年多了。

在這七年中，既有一些對(duì) RabbitMQ 的深度體驗(yàn)，更有無數(shù)的血淚史。

而根據(jù)我這么多年的使用經(jīng)驗(yàn)，我將 RabbitMQ 的心得形成一些提醒或者規(guī)范分享給大家，這樣，大家以后使用 RabbitMQ 的時(shí)候，就不會(huì)再走我走過的彎路了。

我想把我這些關(guān)于 RabbitMQ 的經(jīng)驗(yàn)和心得，分成三篇來寫：

• 開發(fā)前的規(guī)范；
• 開發(fā)中的注意事項(xiàng)；
• 以及 MQ 本身的優(yōu)化。

這次咱們先從開發(fā)前的規(guī)范開始談起。

我曾經(jīng)一直都很奇怪，為何大家使用開發(fā)語言有開發(fā)規(guī)范，使用數(shù)據(jù)庫(kù)有數(shù)據(jù)庫(kù)規(guī)范，但是使用 MQ 卻很少見一些規(guī)范。

使用 MQ 缺少規(guī)范，這是普遍的問題？還只是我身邊的個(gè)例？

不管答案是哪個(gè)，在 RabbitMQ 使用時(shí)，為了避免在開發(fā)中少出現(xiàn)問題，為了事半功倍，都需要提前規(guī)范好一些配置和事項(xiàng)。

1. 一個(gè) RabbitMQ 應(yīng)用里建立多個(gè) vhost，去對(duì)應(yīng)不同的開發(fā)項(xiàng)目

我們?cè)谑褂脭?shù)據(jù)庫(kù)的時(shí)候，會(huì)在一個(gè)數(shù)據(jù)庫(kù)應(yīng)用里建立多個(gè)不同的數(shù)據(jù)庫(kù)去給不同的項(xiàng)目使用，而不用在不同的服務(wù)器專門每個(gè)項(xiàng)目都安裝個(gè)數(shù)據(jù)庫(kù)應(yīng)用。

在 RabbitMQ 的 vhost，也是類似的理念。

vhost 本質(zhì)上是一個(gè) mini 版的 RabbitMQ 服務(wù)器，擁有自己的隊(duì)列、綁定、交換器和權(quán)限控制，當(dāng)在 RabbitMQ 中創(chuàng)建一個(gè)用戶時(shí)，用戶通常會(huì)被指派給至少一個(gè) vhost，并且只能訪問被指派 vhost 內(nèi)的隊(duì)列、交換器和綁定，vhost 之間是絕對(duì)隔離的。

所以，不同的 vhost 對(duì)應(yīng)不同的項(xiàng)目，互不影響，而這些 vhost 其實(shí)都是在一臺(tái)主機(jī)一個(gè) RabbitMQ 應(yīng)用上。

但是，現(xiàn)在的狀況是大部分使用 RabbitMQ 的技術(shù)團(tuán)隊(duì)往往就使用默認(rèn)的 vhost：“/”，如果多出一個(gè)項(xiàng)目了，就再去創(chuàng)建一個(gè) RabbitMQ 的進(jìn)程。這樣做，非常浪費(fèi)開發(fā)資源。

推薦一個(gè)項(xiàng)目對(duì)應(yīng)一個(gè) vhost。

2. 不直接使用 RabbitMQ 自己的客戶端

很多公司使用 RabbitMQ 都是直接使用 RabbitMQ 自己的 java 版本客戶端，但是由于 RabbitMQ 本身內(nèi)在的復(fù)雜性和多樣性，有很多技術(shù)細(xì)節(jié)需要獨(dú)自處理。

比如網(wǎng)絡(luò)連接的處理，比如異常的處理，比如消息失敗的處理等等等。這些，如果手頭沒有一套成熟的框架，那么很可能由于一些細(xì)節(jié)處理不到位，導(dǎo)致非常多的問題，這都是不必要的成本。

所以，要么使用一套已有的 RabbitMQ 客戶端框架（比如 Spring 的 RabbitMQ 框架），要么自己封裝出一套底層 RabbitMQ 客戶端框架，而不是單獨(dú)使用 RabbitMQ 的客戶端

3. 無論如何消費(fèi)者必須給回 ACK 響應(yīng)

ACK 機(jī)制就是消費(fèi)者從 RabbitMQ 收到消息并處理完成后，反饋給 RabbitMQ，然后 RabbitMQ 收到反饋后才將此消息從隊(duì)列中刪除。

由于 ACK 機(jī)制本身必須回復(fù)給 RabbitMQ，消息才會(huì)丟棄這個(gè)特點(diǎn)。對(duì)于何時(shí)給 ACK，我們做開發(fā)的時(shí)候一定要在開發(fā)項(xiàng)目前提前規(guī)劃好、設(shè)計(jì)好。

我們使用 RabbitMQ 通常不想在收到消息就立即給回 ACK 的，也不會(huì)設(shè)置 autoACK 機(jī)制即消費(fèi)端收到自動(dòng)返回一個(gè) ACK 響應(yīng)。一般來講，我們都會(huì)根據(jù)業(yè)務(wù)邏輯的不同，會(huì)在不同的位置手動(dòng)返回 ACK。

這時(shí)候，就可能出現(xiàn)問題：當(dāng)收到消息，有時(shí)候處理業(yè)務(wù)邏輯報(bào)錯(cuò)了，往往在處理完業(yè)務(wù)邏輯就會(huì)忽略 ACK，這會(huì)導(dǎo)致消息始終卡死在 queue 里……如果數(shù)量越來越多，后續(xù)處理非常麻煩。

4. 考慮設(shè)置 dead letter exchanges

為什么那么多人不設(shè)置 dead letter exchanges？這是我非常疑惑的點(diǎn)。

出去和各類使用 RabbitMQ 的項(xiàng)目團(tuán)隊(duì)交流，發(fā)現(xiàn)很少人設(shè)置了 dead letter exchanges。這個(gè)是有問題的。

我們得知道，有時(shí)候消息投遞出錯(cuò)，并不總是在應(yīng)用接收的時(shí)候出了問題，會(huì)有很多非應(yīng)用的問題。比如：

1. 消費(fèi)端有問題，發(fā)出的消息被拒絕了。并且我們也設(shè)置了 requeue=false；

2. 消息可能因?yàn)闆]有收到 ACK 超時(shí)被刪除，或者消費(fèi)端消費(fèi)速度跟不上導(dǎo)致消息超時(shí)被刪除；

3. 消息數(shù)量超過了隊(duì)列最大長(zhǎng)度限制被拋棄；

4. 消息總大小超過了隊(duì)列消息總大小限制被拋棄。

對(duì)于這些問題，設(shè)置 dead letter exchanges 算是一個(gè)解決辦法。

當(dāng)消息一旦出現(xiàn)我上面列舉出來的情況，就會(huì)被發(fā)送到我們?cè)O(shè)置的 dead letter exchanges。然后我們就可以對(duì)這些特殊情況的消息進(jìn)行單獨(dú)處理，這樣的做法可以讓我們的項(xiàng)目更健壯，更容易追蹤問題。

5. 盡量使用 Direct Exchange

RabbitMQ 的Exchange 就是消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列。

這家伙有四種類型：

1. Direct：處理路由鍵，需要將一個(gè)隊(duì)列綁定到交換機(jī)上，要求該消息與一個(gè)特定的路由鍵完全匹配。這是一個(gè)完整的匹配。如果一個(gè)隊(duì)列綁定到該交換機(jī)上要求路由鍵為“green”，則只有路由鍵為“green”的消息才被轉(zhuǎn)發(fā)，不會(huì)轉(zhuǎn)發(fā)路由鍵為"red"，只會(huì)轉(zhuǎn)發(fā)路由鍵為“green”。

2. Topic：將路由鍵和某模式進(jìn)行匹配。此時(shí)隊(duì)列需要綁定要一個(gè)模式上。符號(hào)“#”匹配一個(gè)或多個(gè)詞，符號(hào)“*”只能匹配一個(gè)詞。

3. Fanout：不處理路由鍵。你只需要簡(jiǎn)單的將隊(duì)列綁定到交換機(jī)上。一個(gè)發(fā)送到該類型交換機(jī)的消息都會(huì)被廣播到與該交換機(jī)綁定的所有隊(duì)列上。

4. Headers：不處理路由鍵，而是根據(jù)發(fā)送的消息內(nèi)容中的 headers 屬性進(jìn)行匹配。在綁定 Queue 與 Exchange 時(shí)指定一組鍵值對(duì)；當(dāng)消息發(fā)送到 RabbitMQ 時(shí)會(huì)取到該消息的 headers 與 Exchange 綁定時(shí)指定的鍵值對(duì)進(jìn)行匹配；如果完全匹配則消息會(huì)路由到該隊(duì)列，否則不會(huì)路由到該隊(duì)列。

在這四種類型里，Direct 類型的 Exchange 投遞消息是最快的。其他的 Exchange，MQ 還得花時(shí)間計(jì)算投遞的位置。

所以，能使用 Direct 類型的建議使用 Direct。

以上就是在使用 RabbitMQ 前，需要考慮使用的規(guī)范，有了這些規(guī)范，很多程序員就能據(jù)此寫出比較穩(wěn)定健壯的程序，而不會(huì)導(dǎo)致各種莫名其妙的問題。

強(qiáng)烈建議大家在團(tuán)隊(duì)使用之前，先弄一份規(guī)范。否則，如果很多程序員使用 RabbitMQ 非常隨意，容易導(dǎo)致出現(xiàn)各種幺蛾子問題。

在下一篇文章里，我將寫一些開發(fā)中需要注意的事項(xiàng)。

雖說是開發(fā)需要注意的事項(xiàng)，其實(shí)就是我在開發(fā)一套成熟的 RabbitMQ 客戶端框架時(shí)，碰到的各種問題的總結(jié)。如果有些讀者所在的開發(fā)團(tuán)隊(duì)恰好也有類似的經(jīng)歷，那么我說的所有問題，你會(huì)發(fā)現(xiàn)你可能都會(huì)遇到。