#說在前面
IT行業中的運維範疇，除了傳統運維再就是網際網路運維，這兩樣，UP楠哥都做過，特別是對網際網路運維的那段時間記憶猶新；主要是PAAS層的一些技術，例如使用到rabbitmq、kakfa、zookeeper、redis、flink等。訊息佇列的叢集化部署，透過Grafana做視覺化的監控。後來再做雲計算如OpenStack以及SDN軟體定義網路如VMware NSX這樣的方案落地中發現，OpenStack的塊儲存Cinder 會使用到 RabbitMQ 與各元件的使用、訊息的傳送和接收；另外，VMware NSX中也會用到RabbitMQ已程序方式寄宿在管理平面中NSX Manager中傳送訊息到各個ESXi中。
其實咱們的IT行業中，除了RabbitMQ之外還有很多的訊息佇列的東東， ActiveMQ、Kafka 、ZeroMQ ，阿里捐贈給 Apache 的 RocketMQ以及Redis也支援MQ。但是縱觀行業幾個大佬，好像都對RabbitMQ情有獨鍾，把它納入自己的方案提供訊息佇列。UP楠哥今天和大夥嘮一嘮訊息佇列的概念、RabbitMQ以及與其它不同。Let’s go ！
#訊息佇列概念
訊息（Message）是指在應用間傳輸的資料。訊息可以是簡單的比如只包含文字字串，也可以自定義複雜的物件，只要能按設定格式解析出來就可以。
訊息佇列（Message Queue）是一種應用間的通訊方式，訊息傳送後可以立即返回，由訊息系統來確保訊息的可靠傳遞。是一種先進先出資料結構，它是存放訊息的一個盒子或容器中，訊息從隊尾入隊，從隊頭出隊，入隊即發訊息的過程，出隊即收訊息的過程。訊息釋出者只管把訊息釋出到訊息佇列中而不用管誰來取，訊息使用者只管從訊息佇列中取訊息而不管是誰釋出的。
舉個實際點的例子，UP楠哥上大學的時候兼職某快餐店，醃製雞腿肉的大叔們（我們稱作為訊息釋出者）早上把醃製好的雞腿肉放到冷凍庫（我們成為訊息佇列的盒子或容器），冷凍庫裡一定還有隔天晚上剩餘的雞腿肉，此時大叔們會把它們放到冷凍庫架子上的最頂端，新醃製好的雞腿肉放在第二層或者最下層。這樣秉承FIFO（先進先出）的原則，作為廚房小能手的UP楠哥（我們成為訊息使用者）會把冷凍庫中最頂端的雞肉拿出來進行處理，完成後再去拿第二層、第三層最頂端的醃製雞肉，此過程中一旦大叔們把新醃製好的雞肉拿到冷凍庫，都會按照這個邏輯，一直迴圈下去。
以上的發生在UP楠哥真實的例子，就可以很多好的體現出訊息佇列的一個過程是怎樣的。簡單再畫個邏輯圖，如下：
以上的例子其實就是訊息佇列中最原始的一個模型，訊息按照什麼順序寫進去，就按照什麼順序讀出來。不過，佇列沒有 “讀” 這個操作，讀就是出隊（把雞肉從冷凍庫拿出），從隊頭中刪除（處理）這個訊息。
那麼我們還需要在思考一個問題，快餐店有沒有可能只有一種雞腿肉可以賣，答案肯定不是，有什麼香辣雞腿肉、不辣的雞腿肉，還有勁雞爆米花（額，不對，是勁爆雞米花^-^），所以這個時候我們就要分門別類的區分（我們稱作主題Topic），廚房員工的職責也會再細分（我們稱作為訂閱者），例如UP楠哥和助教武教練（訂閱者）只負責香辣雞腿肉（主題Topic） 、我們的張Sir和Wiki老師（訂閱者）只負責不辣的雞腿肉（主題Topic）等。此時，演化出了另外一種訊息模型叫做釋出->訂閱模型，為了將一份訊息資料分發給多個訊息使用者，並且每個訊息使用者都會收到完整的訊息。
這種釋出->訂閱模型，存放雞腿肉的冷凍庫變成了“主題“這個名詞，各個訂閱者在接收訊息之前需要明確自己的負責範圍（訂閱主題）；每個訂閱者都可以收到同一個主題的完整訊息。釋出->訂閱模型和第一種模型不同點在於：一份訊息資訊可以被多次使用。
#RabbitMQ自身特點
RabbitMQ原生就支援上面提到的兩種訊息模式，RabbitMQ是一套開源（MPL）的訊息佇列服務軟體，是由 LShift 提供的一個 Advanced Message Queuing Protocol （AMQP） 的開源實現，是由以高效能、健壯以及可伸縮性出名的 Erlang 語言寫成。它的logo是一隻橘色的小兔子，難道是表明自己處理訊息會很快還是自己很可愛？？？（此時rapper身份的功底無疑又暴露了^-^）
RabbitMQ 最初起用於在分散式系統中儲存轉發訊息，具有易用性、擴充套件性、高可用性等，在金融行業都有很好的表現。
RabbitMQ特點是：
ü 可伸縮性：叢集服務；
ü 訊息持久化：從記憶體持久化訊息到硬碟，再從硬碟載入到記憶體。
#RabbitMQ幾個概念
## Producer：生產者
投遞訊息的一方，就好比剛才提到的醃製雞肉的大叔，生產者建立訊息釋出到RabbitMQ中。這其中會包含兩個東西：訊息體，比如字串，帶有邏輯結構的資料。另外一個就是標籤用來描述這條訊息。
## Consumer：消費方
接受訊息一方，就好比剛才提到的廚房處理雞肉的員工，消費者連線到RabbitMQ伺服器，並訂閱到佇列上。當消費者消費一條訊息時，僅僅是消費訊息的訊息體。在訊息路由的過程中，訊息的標籤會丟棄，存入到佇列中的訊息只有訊息體，消費者也只會消費到訊息體。
## Broker：服務節點
我們就理解為一臺RabbitMQ的Server。
## Queue：佇列
儲存訊息的盒子或容器。
##Exchange：交換器
生產者將訊息傳送到交換器，交換器把訊息透過路由的方式放到一個或多個佇列中。
##RoutingKey：路由鍵
生產者將訊息傳送給交換器的時候，會指定一個路由鍵RoutingKey，指定訊息的路由規則，路由鍵RoutingKey需要與交換器型別和繫結鍵（BindingKey）一起使用才可以。
##Connection：連線
生產者還是消費者和RabbitMQ Broker 會建立TCP連線，我們稱作connection連線。
##Channel：通道
TCP 連線建立起來後，客戶端會建立一個通道的東西，每個通道指定唯一的ID號 。通道是建立在Connection的一種虛擬連線， RabbitMQ 處理的指令由通道完成。
#RabbitMQ和其它不同之處
我也問過之前做大資料的同事，他們也僅僅是對Kakfa比較瞭解，他們感覺Kafka在吞吐量上要比RabbitMQ要好一些；在可用性上，Kafka支援主備切換，RabbitMQ支援miror佇列；我也只是做了Kafka和RabbitMQ的對比，但是開源的訊息佇列遠遠不止這兩個，時間有限也就沒有細看，未來在進行研究和討論。吞吐量較低的情況下，Kafka和RabbitMQ都可以。會選擇Kafka好一些。