channel 

有了TCP連接后,還需要channel的原因如下:

• 創(chuàng)建和銷毀TCP連接很耗時;
• 打開太多TCP連接,耗操作系統(tǒng)資源，并發(fā)量大到一定程度,系統(tǒng)的吞吐量會降低；
• 使用一個connection多channel的方式,可以提升連接的利用率。

因此采用多個channel多路復(fù)用一個TCP連接的方式才比較合理

exchange（交換機）

生產(chǎn)者發(fā)消息發(fā)往交換機，交換機會自己投遞消息到綁定的queue隊列

1.exchange根據(jù)什么規(guī)則把消息投遞到哪些queue中？

exchange有4種類型

• direct： 對routing_key進行嚴(yán)格匹配，當(dāng)消息來到的時候，只有exchange與某queue綁定的routing_key完全匹配才將消息投遞到該queue
• topic： 對routing_key進行通配符模糊匹配，滿足條件的queue都能收到消息，這里的routing_key以"."分隔，*匹配一個單詞，#匹配多個單詞，如果同一個queue滿足多個條件不會被投遞多次

如果消息的routingkey是quick.orange.rabbit，那么Q1 Q2都會收到這條消息。

如果消息的routingkey是quick.orange.fox，那么Q1會收到這條消息

• headers： 根據(jù)消息體內(nèi)的headers屬性匹配，綁定的時候可以制定鍵值對。不依賴routing_key匹配。

大致邏輯與direct差不多，只不過不是用的routing_key來匹配

• fanout： 轉(zhuǎn)發(fā)消息到所有綁定隊列，不依賴routing_key匹配

在不需要路由的時候，一般是使用的這個類型的exchange。

1. 發(fā)布訂閱：兩個queue綁定到同一個exchange上，那么同一個消息被發(fā)送到exchange后，exchange會把這個消息發(fā)給綁定的所有隊列，兩個消費者，一人消費一個隊列，這就在這兩個消費者之間達(dá)到了發(fā)布訂閱的效果
2.  競爭消費：兩個消費者消費同一個隊列，這就達(dá)到了這兩個消費者之間的競爭消費效果。

注意，實際上在寫代碼的時候不顯示指定exchange的數(shù)據(jù)是發(fā)送到一個默認(rèn)的exchange上的。

2.exchange持久化怎么搞？

如果不設(shè)置持久化，broker掛了，再重啟，這個exchange就不存在了。

在客戶端聲明exchange的時候有個入?yún)砜刂剖欠癯志没?/p>

而autoDelete則是，當(dāng)沒有queue綁定的時候是否自動刪除這個exchange

3.生產(chǎn)者ACK機制？

事務(wù)或者confirm機制：

rabbitmq生產(chǎn)者確保消息一定送達(dá)

這個需要借助Server和MQ的交互實現(xiàn)（tx-select/commit, ok/fail)

4.投遞方法

basicPublish中的mandatory和immediate mandatory

當(dāng)mandatory標(biāo)志位設(shè)置為true時如果exchange根據(jù)自身類型和消息routeKey無法找到一個符合條件的queue，那么會調(diào)用basic.return方法將消息返回給生產(chǎn)者

（Basic.Return + Content-Header + Content-Body）；

當(dāng)mandatory設(shè)置為false時，出現(xiàn)上述情形broker會直接將消息扔掉。

immediate 當(dāng)immediate標(biāo)志位設(shè)置為true時，如果exchange在將消息路由到queue(s)時發(fā)現(xiàn)對于的queue上沒有消費者，那么這條消息不會放入隊列中。

當(dāng)與消息routeKey關(guān)聯(lián)的所有queue（一個或者多個）都沒有消費者時，該消息會通過basic.return方法返還給生產(chǎn)者。

換句話說，無法找到一個消費者時，消息返還給生產(chǎn)者

到此這篇關(guān)于RabbitMQ中的Channel和Exchange詳解的文章就介紹到這了,更多相關(guān)RabbitMQ的Channel和Exchange內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論