共計(jì) 2229 個字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。
丸趣 TV 小編給大家分享一下如何規(guī)范地使用 RabbitMQ，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！
在 RabbitMQ 使用時，為了避免在開發(fā)中少出現(xiàn)問題，為了事半功倍，都需要提前規(guī)范好一些配置和事項(xiàng)。
1. 一個 RabbitMQ 應(yīng)用里建立多個 vhost，去對應(yīng)不同的開發(fā)項(xiàng)目
我們在使用數(shù)據(jù)庫的時候，會在一個數(shù)據(jù)庫應(yīng)用里建立多個不同的數(shù)據(jù)庫去給不同的項(xiàng)目使用，而不用在不同的服務(wù)器專門每個項(xiàng)目都安裝個數(shù)據(jù)庫應(yīng)用。
在 RabbitMQ 的 vhost，也是類似的理念。
vhost 本質(zhì)上是一個 mini 版的 RabbitMQ 服務(wù)器，擁有自己的隊(duì)列、綁定、交換器和權(quán)限控制，當(dāng)在 RabbitMQ 中創(chuàng)建一個用戶時，用戶通常會被指派給至少一個 vhost，并且只能訪問被指派 vhost 內(nèi)的隊(duì)列、交換器和綁定，vhost 之間是絕對隔離的。
所以，不同的 vhost 對應(yīng)不同的項(xiàng)目，互不影響，而這些 vhost 其實(shí)都是在一臺主機(jī)一個 RabbitMQ 應(yīng)用上。
但是，現(xiàn)在的狀況是大部分使用 RabbitMQ 的技術(shù)團(tuán)隊(duì)往往就使用默認(rèn)的 vhost：“/”，如果多出一個項(xiàng)目了，就再去創(chuàng)建一個 RabbitMQ 的進(jìn)程。這樣做，非常浪費(fèi)開發(fā)資源。
推薦一個項(xiàng)目對應(yīng)一個 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，消息才會丟棄這個特點(diǎn)。對于何時給 ACK，我們做開發(fā)的時候一定要在開發(fā)項(xiàng)目前提前規(guī)劃好、設(shè)計(jì)好。
我們使用 RabbitMQ 通常不想在收到消息就立即給回 ACK 的，也不會設(shè)置 autoACK 機(jī)制即消費(fèi)端收到自動返回一個 ACK 響應(yīng)。一般來講，我們都會根據(jù)業(yè)務(wù)邏輯的不同，會在不同的位置手動返回 ACK。
這時候，就可能出現(xiàn)問題：當(dāng)收到消息，有時候處理業(yè)務(wù)邏輯報錯了，往往在處理完業(yè)務(wù)邏輯就會忽略 ACK，這會導(dǎo)致消息始終卡死在 queue 里 hellip; hellip; 如果數(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。這個是有問題的。
我們得知道，有時候消息投遞出錯，并不總是在應(yīng)用接收的時候出了問題，會有很多非應(yīng)用的問題。比如：
消費(fèi)端有問題，發(fā)出的消息被拒絕了。并且我們也設(shè)置了 requeue=false;
消息可能因?yàn)闆]有收到 ACK 超時被刪除，或者消費(fèi)端消費(fèi)速度跟不上導(dǎo)致消息超時被刪除;
消息數(shù)量超過了隊(duì)列最大長度限制被拋棄;
消息總大小超過了隊(duì)列消息總大小限制被拋棄。
對于這些問題，設(shè)置 dead letter exchanges 算是一個解決辦法。
當(dāng)消息一旦出現(xiàn)我上面列舉出來的情況，就會被發(fā)送到我們設(shè)置的 dead letter exchanges。然后我們就可以對這些特殊情況的消息進(jìn)行單獨(dú)處理，這樣的做法可以讓我們的項(xiàng)目更健壯，更容易追蹤問題。
5. 盡量使用 Direct Exchange
RabbitMQ 的 Exchange 就是消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個隊(duì)列。
這家伙有四種類型：
Direct：處理路由鍵，需要將一個隊(duì)列綁定到交換機(jī)上，要求該消息與一個特定的路由鍵完全匹配。這是一個完整的匹配。如果一個隊(duì)列綁定到該交換機(jī)上要求路由鍵為“green”，則只有路由鍵為“green”的消息才被轉(zhuǎn)發(fā)，不會轉(zhuǎn)發(fā)路由鍵為 red，只會轉(zhuǎn)發(fā)路由鍵為“green”。
Topic：將路由鍵和某模式進(jìn)行匹配。此時隊(duì)列需要綁定要一個模式上。符號“#”匹配一個或多個詞，符號“*”只能匹配一個詞。
Fanout：不處理路由鍵。你只需要簡單的將隊(duì)列綁定到交換機(jī)上。一個發(fā)送到該類型交換機(jī)的消息都會被廣播到與該交換機(jī)綁定的所有隊(duì)列上。
Headers：不處理路由鍵，而是根據(jù)發(fā)送的消息內(nèi)容中的 headers 屬性進(jìn)行匹配。在綁定 Queue 與 Exchange 時指定一組鍵值對; 當(dāng)消息發(fā)送到 RabbitMQ 時會取到該消息的 headers 與 Exchange 綁定時指定的鍵值對進(jìn)行匹配; 如果完全匹配則消息會路由到該隊(duì)列，否則不會路由到該隊(duì)列。
在這四種類型里，Direct 類型的 Exchange 投遞消息是最快的。其他的 Exchange，MQ 還得花時間計(jì)算投遞的位置。
所以，能使用 Direct 類型的建議使用 Direct。
看完了這篇文章，相信你對“如何規(guī)范地使用 RabbitMQ”有了一定的了解，如果想了解更多相關(guān)知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝各位的閱讀！
