這篇文章主要講解了“使用RabbitMQ的方法有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“使用RabbitMQ的方法有哪些”吧！

鹿寨網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)從2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

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

我們在使用數(shù)據(jù)庫的時候，會在一個數(shù)據(jù)庫應(yīng)用里建立多個不同的數(shù)據(jù)庫去給不同的項目使用，而不用在不同的服務(wù)器專門每個項目都安裝個數(shù)據(jù)庫應(yīng)用。

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

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

所以，不同的 vhost 對應(yīng)不同的項目，互不影響，而這些 vhost 其實都是在一臺主機(jī)一個 RabbitMQ 應(yīng)用上。

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

推薦一個項目對應(yīng)一個 vhost。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 消息可能因為沒有收到 ACK 超時被刪除，或者消費端消費速度跟不上導(dǎo)致消息超時被刪除；

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

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

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

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

5. 盡量使用 Direct Exchange

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

這家伙有四種類型：

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

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

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

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

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

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

感謝各位的閱讀，以上就是“使用RabbitMQ的方法有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對使用RabbitMQ的方法有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

當(dāng)前題目：使用RabbitMQ的方法有哪些
網(wǎng)站URL：http://www.chinadenli.net/article48/gpsiep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、用戶體驗、企業(yè)建站、App設(shè)計、自適應(yīng)網(wǎng)站、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)