消息的TTL（Time To Live）

消息的TTL就是消息的存活時間。

? RabbitMQ可以對隊列和消息分別設(shè)置TTL。

? 對隊列設(shè)置就是隊列沒有消費(fèi)者連著的保留時間，也可以對每一個單獨(dú)的消息做單獨(dú)的 設(shè)置。超過了這個時間，我們認(rèn)為這個消息就死了，稱之為死信。

? 如果隊列設(shè)置了，消息也設(shè)置了，那么會取小的。所以一個消息如果被路由到不同的隊 列中，這個消息死亡的時間有可能不一樣（不同的隊列設(shè)置）。這里單講單個消息的TTL，因?yàn)樗攀菍?shí)現(xiàn)延遲任務(wù)的關(guān)鍵。可以通過設(shè)置消息的expiration字段或者x- message-ttl屬性來設(shè)置時間，兩者是一樣的效果。

?RabbitMQ運(yùn)行機(jī)制

AMQP 中的消息路由

? AMQP 中消息的路由過程和 Java 開 發(fā)者熟悉的 JMS 存在一些差別， AMQP 中增加了 Exchange 和 Binding 的角色。生產(chǎn)者把消息發(fā)布 到 Exchange 上，消息最終到達(dá)隊列 并被消費(fèi)者接收，而 Binding 決定交 換器的消息應(yīng)該發(fā)送到那個隊列。

Exchange 類型?

Exchange分發(fā)消息時根據(jù)類型的不同分發(fā)策略有區(qū)別，目前共四種類型：direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由鍵， headers 交換器和 direct 交換器完全一致，但性能差很多，目前幾乎用不到了，所以直接 看另外三種類型：

?

消息中的路由鍵（routing key）如果和 Binding 中的 binding key 一致， 交換器 就將消息發(fā)到對應(yīng)的隊列中。路由鍵與隊 列名完全匹配，如果一個隊列綁定到交換 機(jī)要求路由鍵為“dog”，則只轉(zhuǎn)發(fā) routing key 標(biāo)記為“dog”的消息，不會轉(zhuǎn)發(fā) “dog.puppy”，也不會轉(zhuǎn)發(fā)“dog.guard”等等。它是完全匹配、單播的模式。

?

每個發(fā)到 fanout 類型交換器的消息都會分到所有綁定的隊列上去。fanout 交換器不處理路由鍵，只是簡單的將隊列綁定到交換器上，每個發(fā)送到交換器的消息都會被轉(zhuǎn)發(fā)到與該交換器綁定的所有隊列上。很像子網(wǎng)廣播，每臺子網(wǎng)內(nèi)的主機(jī)都獲得了一份復(fù)制的消息。fanout 類型轉(zhuǎn)發(fā)消息是最快的。

?

topic 交換器通過模式匹配分配消息的路由鍵屬性，將路由鍵和某個模式進(jìn)行匹配，此時隊列需要綁定到一個模式上。它將路由鍵和綁定鍵的字符串切分成單詞，這些單詞之間用點(diǎn)隔開。它同樣也會識別兩個通配符：符號“#”和符號“*”。#匹配0個或多個單詞，*匹配一個單詞。

Docker安裝RabbitMQ?

docker run -d --name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 rabbitmq:management

?4369, 25672 (Erlang發(fā)現(xiàn)&集群端口)

5672, 5671 (AMQP端口)

15672 (web管理后臺端口)

61613, 61614 (STOMP協(xié)議端口)

1883, 8883 (MQTT協(xié)議端口)

https://www.rabbitmq.com/networking.html

?

?