使用RabbitMQ的方法有哪些

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

1. 一個(gè) RabbitMQ 應(yīng)用里建立多個(gè) vhost，去對(duì)應(yīng)不同的開(kāi)發(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，并且只能訪問(wèn)被指派 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)開(kā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ò)連接的處理，比如異常的處理，比如消息失敗的處理等等等。這些，如果手頭沒(méi)有一套成熟的框架，那么很可能由于一些細(xì)節(jié)處理不到位，導(dǎo)致非常多的問(wèn)題，這都是不必要的成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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的方法有哪些”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)使用RabbitMQ的方法有哪些這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！