#說在前面

IT行業(yè)中的運維范疇，除了傳統(tǒng)運維再就是互聯(lián)網(wǎng)運維，這兩樣，UP楠哥都做過，特別是對互聯(lián)網(wǎng)運維的那段時間記憶猶新；主要是PAAS層的一些技術(shù)，例如使用到rabbitmq、kakfa、zookeeper、redis、flink等。消息隊列的集群化部署，通過Grafana做可視化的監(jiān)控。后來再做云計算如OpenStack以及SDN軟件定義網(wǎng)絡(luò)如VMware?NSX這樣的方案落地中發(fā)現(xiàn)，OpenStack的塊存儲Cinder 會使用到 RabbitMQ 與各組件的使用、消息的發(fā)送和接收；另外，VMware NSX中也會用到RabbitMQ已進程方式寄宿在管理平面中NSX?Manager中發(fā)送消息到各個ESXi中。

其實咱們的IT行業(yè)中，除了RabbitMQ之外還有很多的消息隊列的東東， ActiveMQ、Kafka 、ZeroMQ ，阿里捐贈給 Apache 的 RocketMQ以及Redis也支持MQ。但是縱觀行業(yè)幾個大佬，好像都對RabbitMQ情有獨鐘，把它納入自己的方案提供消息隊列。UP楠哥今天和大伙嘮一嘮消息隊列的概念、RabbitMQ以及與其它不同。Let’s go !

?

#消息隊列概念

消息（Message）是指在應(yīng)用間傳輸?shù)臄?shù)據(jù)。消息可以是簡單的比如只包含文本字符串，也可以自定義復(fù)雜的對象，只要能按設(shè)定格式解析出來就可以。

消息隊列（Message Queue）是一種應(yīng)用間的通信方式，消息發(fā)送后可以立即返回，由消息系統(tǒng)來確保消息的可靠傳遞。是一種先進先出數(shù)據(jù)結(jié)構(gòu)，它是存放消息的一個盒子或容器中，消息從隊尾入隊，從隊頭出隊，入隊即發(fā)消息的過程，出隊即收消息的過程。消息發(fā)布者只管把消息發(fā)布到消息隊列中而不用管誰來取，消息使用者只管從消息隊列中取消息而不管是誰發(fā)布的。

舉個實際點的例子，UP楠哥上大學的時候兼職某快餐店，腌制雞腿肉的大叔們(我們稱作為消息發(fā)布者)早上把腌制好的雞腿肉放到冷凍庫(我們成為消息隊列的盒子或容器)，冷凍庫里一定還有隔天晚上剩余的雞腿肉，此時大叔們會把它們放到冷凍庫架子上的最頂端，新腌制好的雞腿肉放在第二層或者最下層。這樣秉承FIFO(先進先出)的原則，作為廚房小能手的UP楠哥(我們成為消息使用者)會把冷凍庫中最頂端的雞肉拿出來進行處理，完成后再去拿第二層、第三層最頂端的腌制雞肉，此過程中一旦大叔們把新腌制好的雞肉拿到冷凍庫，都會按照這個邏輯，一直循環(huán)下去。

以上的發(fā)生在UP楠哥真實的例子，就可以很多好的體現(xiàn)出消息隊列的一個過程是怎樣的。簡單再畫個邏輯圖，如下：

以上的例子其實就是消息隊列中最原始的一個模型，消息按照什么順序?qū)戇M去，就按照什么順序讀出來。不過，隊列沒有 “讀” 這個操作，讀就是出隊(把雞肉從冷凍庫拿出)，從隊頭中刪除(處理)這個消息。

那么我們還需要在思考一個問題，快餐店有沒有可能只有一種雞腿肉可以賣，答案肯定不是，有什么香辣雞腿肉、不辣的雞腿肉，還有勁雞爆米花(額，不對，是勁爆雞米花^-^)，所以這個時候我們就要分門別類的區(qū)分(我們稱作主題Topic)，廚房員工的職責也會再細分(我們稱作為訂閱者)，例如UP楠哥和助教武教練(訂閱者)只負責香辣雞腿肉(主題Topic)?、我們的張Sir和Wiki老師(訂閱者)只負責不辣的雞腿肉(主題Topic)等。此時，演化出了另外一種消息模型叫做發(fā)布->訂閱模型，為了將一份消息數(shù)據(jù)分發(fā)給多個消息使用者，并且每個消息使用者都會收到完整的消息。

這種發(fā)布->訂閱模型，存放雞腿肉的冷凍庫變成了“主題“這個名詞，各個訂閱者在接收消息之前需要明確自己的負責范圍(訂閱主題)；每個訂閱者都可以收到同一個主題的完整消息。發(fā)布->訂閱模型和第一種模型不同點在于：一份消息信息可以被多次使用。

?

#RabbitMQ自身特點

RabbitMQ原生就支持上面提到的兩種消息模式，RabbitMQ是一套開源（MPL）的消息隊列服務(wù)軟件，是由 LShift 提供的一個 Advanced Message Queuing Protocol (AMQP) 的開源實現(xiàn)，是由以高性能、健壯以及可伸縮性出名的 Erlang 語言寫成。它的logo是一只橘色的小兔子，難道是表明自己處理消息會很快還是自己很可愛？？？(此時rapper身份的功底無疑又暴露了^-^)

RabbitMQ 最初起用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，具有易用性、擴展性、高可用性等，在金融行業(yè)都有很好的表現(xiàn)。

RabbitMQ特點是：

ü?可伸縮性：集群服務(wù)；

ü?消息持久化：從內(nèi)存持久化消息到硬盤，再從硬盤加載到內(nèi)存。

?

#RabbitMQ幾個概念

##?Producer:生產(chǎn)者

投遞消息的一方，就好比剛才提到的腌制雞肉的大叔，生產(chǎn)者創(chuàng)建消息發(fā)布到RabbitMQ中。這其中會包含兩個東西：消息體，比如字符串，帶有邏輯結(jié)構(gòu)的數(shù)據(jù)。另外一個就是標簽用來描述這條消息。

##?Consumer:消費方

接受消息一方，就好比剛才提到的廚房處理雞肉的員工，消費者連接到RabbitMQ服務(wù)器，并訂閱到隊列上。當消費者消費一條消息時，僅僅是消費消息的消息體。在消息路由的過程中，消息的標簽會丟棄，存入到隊列中的消息只有消息體，消費者也只會消費到消息體。

##?Broker:服務(wù)節(jié)點

我們就理解為一臺RabbitMQ的Server。

##?Queue:隊列

存儲消息的盒子或容器。

##Exchange:交換器

生產(chǎn)者將消息發(fā)送到交換器，交換器把消息通過路由的方式放到一個或多個隊列中。

##RoutingKey:路由鍵

生產(chǎn)者將消息發(fā)送給交換器的時候，會指定一個路由鍵RoutingKey，指定消息的路由規(guī)則，路由鍵RoutingKey需要與交換器類型和綁定鍵（BindingKey）一起使用才可以。

##Connection:連接

生產(chǎn)者還是消費者和RabbitMQ Broker 會建立TCP連接，我們稱作connection連接。

##Channel:信道

TCP 連接建立起來后，客戶端會創(chuàng)建一個信道的東西，每個信道指定唯一的ID號 。信道是建立在Connection的一種虛擬連接， RabbitMQ 處理的指令由信道完成。

#RabbitMQ和其它不同之處

我也問過之前做大數(shù)據(jù)的同事，他們也僅僅是對Kakfa比較了解，他們感覺Kafka在吞吐量上要比RabbitMQ要好一些；在可用性上，Kafka支持主備切換，RabbitMQ支持miror隊列；我也只是做了Kafka和RabbitMQ的對比，但是開源的消息隊列遠遠不止這兩個，時間有限也就沒有細看，未來在進行研究和討論。吞吐量較低的情況下，Kafka和RabbitMQ都可以。會選擇Kafka好一些。