名詞解釋
connection
客戶端和伺服器建立的TCP連結
channels 通道
網路通道,幾乎所有操作都在channel中進行,同一個TCP連結可以建立多個channel,多路複用
message 訊息
傳遞資料,由body和properties組成,body是訊息實體內容
properties的值如下
'content_type' => '型別',
'content_encoding' => '編碼',
'application_headers' => 'headers',
'delivery_mode' => '',
'priority' => '',
'correlation_id' => '',
'reply_to' => '',
'expiration' => '',
'message_id' => '',
'timestamp' => '',
'type' => '',
'user_id' => '',
'app_id' => '',
'cluster_id' => '',
Virtual host 虛擬主機
用於邏輯隔離,最上層的路由,相當於mysql的資料庫
一個virtual host可以有多個exchange和queue,同一個virtual host不能有重名的exchange和queue
Exchange 交換機
接收訊息,根據routing key分發訊息到繫結的佇列上
每個virtual host都有一個預設的exchange:AMQP default
預設的exchange會繫結全部佇列,不能進行binding操作,可以直接使用Queue名作為routing key繫結,如果不存在queue則拋棄訊息
交換機4個型別:
-direct:
將訊息中的routing key與該exchange關聯的所有binding中的routing key進行比較，如果相等，則傳送到該binding對應的queue中。
-topic:
上面那個是等值匹配,這個是模糊匹配
*匹配一個單詞
#配置0個或多個字元
*,# 只能寫在.左右,且不能挨著字元
單詞和單詞之間需要用.隔開
也可以不用*,#,直接指定一個queue名,實現direct效果
-fanout:
直接把訊息轉發到所有binding的對應queue中,這種exchange忽略routing key,效率最高 fanout>direct>topic
-headers:
訊息中的headers和該exchange關聯的binding中引數進行匹配,如果匹配上了,則傳送到該binding對應的queue中
queue 佇列
存放訊息的佇列,供消費者消費
routing key 路由規則
binding
exchange和queue之間的繫結,可以包括routing key
Dead-Letter Queue 死信佇列
1.訊息被否定確認
2.訊息在佇列存活時間超過設定的TTL時間
3.訊息佇列的訊息數量已經超過最大佇列長度
那麼該訊息將成為死信,如果配置了死信佇列,訊息將會丟進死信佇列中,如果沒有配置,則該訊息將會被丟棄
配置過程:
1.建立一個死信Exchange:ex_dlx,一個死信Queue:queue_dlx,透過Routing Key:route_dlx繫結
2.建立一個業務Exchange,一個業務Queue,透過Routing Key繫結,其中業務Queue新增屬性
x-dead-letter-exchange:ex_dlx
x-dead-letter-routing-key:route_dlx
搭配x-message-ttl屬性可以實現延時佇列,可以實現下訂單15分鐘未付款關閉訂單的功能
mandatory 強制性
傳送訊息的時候，當mandatory引數設為true時，交換器無法根據自身的型別和路由鍵找到一個符合條件的佇列，那麼RabbitMQ會呼叫Basic.Return命令將訊息返回給生產者
Alternate exchange 備份交換器
建立Exchange的時候可以設定備份交換器,當訊息不可達的時候會傳送這個備份交換器,優先順序別比mandatory高
訊息TTL 過期時間
新增佇列和釋出訊息的時候都可以設定TTL,如果兩者都設定,那麼以時間較小那個為準,訊息超過TTL設定的值時,就會變成死信
屬性值:x-message-ttl
佇列TTL 過期時間
和訊息一樣,佇列也有過期時間,時間到了自動刪除
屬性值:x-expires
持久化
交換機持久化:設定durable:true
佇列持久化:設定durable:true
訊息持久化:傳送訊息的時候設定屬性deliveryMode:2
事務機制
- channel.txSelect用於將當前通道設定成事務模式
- channel.txCommit用於提交事務
- channel.txRollback用於事務回滾
但是使用事務機制會吸乾RabbitMQ的效能,所以有了下面的傳送方確認機制
傳送方確認機制
channel.confirmSelect();
訊息分發basicQos 允許限制通道上的消費者所能保持的最大未確認訊息的數量
channel.basicQos(5, false);
channel.basicQos(5, true);
如何提高訊息可靠性
設定mandatory引數或者備份交換器
設定publisher confirm機制或者事務機制
設定交換器,佇列,訊息都為持久化
設定消費端的autoAck為false,並在消費完訊息之後再進行訊息確認
本作品採用《CC 協議》，轉載必須註明作者和本文連結