javaB2B2CSpringcloud電子商務平臺原始碼-RabbitMQ基礎概念

RabbitMQ是一個由erlang開發的AMQP的開源實現。

需要JAVA Spring Cloud大型企業分散式微服務雲構建的B2B2C電子商務平臺原始碼 一零三八七七四六二六

AMQP，即Advanced Message Queuing Protocol,一個提供統一訊息服務的應用層標準高階訊息佇列協議,是應用層協議的一個開放標準,為面向訊息的中介軟體設計。

AMQP 是一個線路協議，只要符合該資料格式的訊息傳送和接收元件都能相互相容，能夠輕易實現跨技術平臺架構。

RabbitMQ基礎概念：
ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的物件。Connection是RabbitMQ的socket連結，它封裝了socket協議相關部分邏輯。ConnectionFactory為Connection的製造工廠。
Channel是我們與RabbitMQ打交道的最重要的一個介面，我們大部分的業務操作是在Channel這個介面中完成的，包括定義Queue、定義Exchange、繫結Queue與Exchange、釋出訊息等。

Queue
Queue（佇列）是RabbitMQ的內部物件，用於儲存訊息。

Message acknowledgment
在實際應用中，可能會發生消費者收到Queue中的訊息，但沒有處理完成就當機（或出現其他意外）的情況，這種情況下就可能會導致訊息丟失。為了避免這種情況發生，我們可以要求消費者在消費完訊息後傳送一個回執給RabbitMQ，RabbitMQ收到訊息回執（Message acknowledgment）後才將該訊息從Queue中移除。

Message durability
如果我們希望即使在RabbitMQ服務重啟的情況下，也不會丟失訊息，我們可以將Queue與Message都設定為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ訊息不會丟失。

Prefetch count
前面我們講到如果有多個消費者同時訂閱同一個Queue中的訊息，Queue中的訊息會被平攤給多個消費者。這時如果每個訊息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閒的情況。我們可以通過設定prefetchCount來限制Queue每次傳送給每個消費者的訊息數，比如我們設定prefetchCount=1，則Queue每次給每個消費者傳送一條訊息；消費者處理完這條訊息後Queue會再給該消費者傳送一條訊息。

Exchange
生產者將訊息傳送到Exchange（交換器），由Exchange將訊息路由到一個或多個Queue中（或者丟棄）。

Routing key
生產者在將訊息傳送給Exchange的時候，一般會指定一個routing key，來指定這個訊息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。
在Exchange Type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在傳送訊息給Exchange時，通過指定routing key來決定訊息流向哪裡

Binding
RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將訊息路由到指定的Queue了。

Binding key
在繫結（Binding）Exchange與Queue的同時，一般會指定一個binding key；生產者將訊息傳送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，訊息將會被路由到對應的Queue中。
在繫結多個Queue到同一個Exchange的時候，這些Binding允許使用相同的binding key。 binding key 並不是在所有情況下都生效，它依賴於Exchange Type，比如fanout型別的Exchange就會無視binding key，而是將訊息路由到所有繫結到該Exchange的Queue。

Exchange Type
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種。

fanout
fanout型別的Exchange會把所有傳送到該Exchange的訊息路由到所有與它繫結的Queue中。

direct
direct型別的Exchange會把訊息路由到那些binding key與routing key完全匹配的Queue中。

topic
direct型別的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic型別的Exchange在匹配規則上進行了擴充套件，它與direct型別的Exchage相似，也是將訊息路由到binding key與routing key相匹配的Queue中。

routing key為一個句點號“. ”分隔的字串（我們將被句點號“. ”分隔開的每一段獨立的字串稱為一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
binding key與routing key一樣也是句點號“. ”分隔的字串
binding key中可以存在兩種特殊字元“”與“#”，用於做模糊匹配，其中“”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）

routingKey=”quick.orange.rabbit”的訊息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的訊息會路由到Q1，routingKey=”lazy.brown.fox”的訊息會路由到Q2，routingKey=”lazy.pink.rabbit”的訊息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的訊息將會被丟棄，因為它們沒有匹配任何bindingKey。

headers
headers型別的Exchange不依賴於routing key與binding key的匹配規則來路由訊息，而是根據傳送的訊息內容中的headers屬性進行匹配。
在繫結Queue與Exchange時指定一組鍵值對；當訊息傳送到Exchange時，RabbitMQ會取到該訊息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange繫結時指定的鍵值對；如果完全匹配則訊息會路由到該Queue，否則不會路由到該Queue。

RPC
MQ本身是基於非同步的訊息處理，前面的示例中所有的生產者（P）將訊息傳送到RabbitMQ後不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條訊息都不知道）。
但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的訊息處理完成後再進行下一步處理。這相當於RPC（Remote Procedure Call，遠端過程呼叫）。在RabbitMQ中也支援RPC。

從現在開始，我這邊會將近期研發的spring cloud微服務雲架構的搭建過程和精髓記錄下來，幫助更多有興趣研發spring cloud框架的朋友，大家來一起探討spring cloud架構的搭建過程及如何運用於企業專案。 Java B2B2C多使用者商城 springcloud架構