RabbitMq 基本概念

rabbitmq是乙個基於amqp的訊息佇列，訊息佇列的主要目的實現訊息的生產者和消費者之間的解耦，支援多應用之間的非同步協調工作。開發語言：erlang – 面向併發的程式語言。

首先來一張訊息佇列的經典圖，可以劃分為三個角色: producer, queue, consumer

看到這個模型，如果對jdk的容器有一定的了解，很容易可以想到借助arrayblockingqueue或者listblockingqueue就可以實現簡易的訊息佇列（也就是我們常說的生產者-消費者模型）

其實在生活中，這種模型用得非常多，就比如我們都會接觸的網購快遞，可以說是乙個典型的訊息佇列的case了：

商家不斷的把商品扔給快遞公司（注意不是直接將商品給買家），而快遞公司則將商品根據地質分發對應的買家

對上面這個過程進行拆解，可以對映扮演的角色

那麼快遞公司時怎麼知道要把商品給對應的買家呢？根據包裹上的位址+**

通過上面的例項對比，發現基本的訊息佇列定義的元素太少，這裡則正好可以看一下rabbitmq是怎麼具體來實現訊息佇列的

內部結構圖

上面是一些專業的概念，那麼可以怎麼對映到前面的快遞上呢？

生產者，將訊息投遞給exchange，然後由exchange將訊息路由到對應的queue上，供消費者消費，那麼這個路由有哪些方式呢？

訊息中的路由鍵（routing key）如果和 binding 中的 binding key 一致，交換器就將訊息發到對應的佇列中

簡單來講，就是路由鍵與佇列名完全匹配

舉例說明

exchange和兩個佇列繫結在一起：

從上圖也可以看出，這種策略，將忽略所謂的routing key,將訊息分發到所有繫結的queue上，更加類似我們理解的廣播模式

topic 交換器通過模式匹配分配訊息的路由鍵屬性，將路由鍵和某個模式進行匹配，此時佇列需要繫結到乙個模式上

可以理解為直接策略的高階版，直接策略是完全精確匹配，而topic則支援正則匹配，滿足某類指定規則的（如以***開頭的路由鍵），可以鍵訊息分發過去

乙個更直觀的例項如下

producer傳送訊息時需要設定routing_key,

這個實際上用得不多，它是根據message的一些頭部資訊來分發過濾message，忽略routing key的屬性，如果header資訊和message訊息的頭資訊相匹配

主要使用的訊息分發策略有三個，直接，路由和扇形，簡單的小結下應用場景和區別

a. direct exchange

直接完全匹配模式，適用於精準的訊息分發

b. topic exchange

routing key的匹配模式，支援routing key的模糊匹配方式，更適用於多類訊息的聚合

c. fanout exchange

忽略routing key, 將訊息分配給所有的queue，廣播模式，適用於訊息的復用場景

訊息佇列的乙個重要指標，當有消費者獲取了訊息之後，對這個訊息我應該怎麼辦？是直接刪除還是等某個合適的機會再刪除？又或者是乾脆不刪除，就留著了？

在實際的應用場景中，訊息正常消費之後，我們希望的是這個訊息就不要了，但是消費的過程中如果出現了bug，則希望不要刪除訊息，等我修復這個bug後，可以把這個訊息重新的投遞給我

consumer接收到了訊息之後，必須返回乙個ack的標誌，表示訊息是否成功消費，如果返回true，則表示消費成功了，然後這個訊息就會從rabbitmq的佇列中刪掉；如果返回false，且設定為重新入隊，則這個訊息可以被重新投遞進來

通常實際編碼中，預設是自動ack的，如果訊息的重要性程度較高，我們應該設定為主動ack，在接收到訊息之後，自主的返回對應的ack資訊