RabbitMQ
RabbitMQ 是一個由 Erlang 語言開發(fā)的 AMQP 的開源實現(xiàn)。
AMQP ：Advanced Message Queue，高級消息隊列協(xié)議。它是應(yīng)用層協(xié)議的一個開放標準，為面向消息的中間件設(shè)計，基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受產(chǎn)品、開發(fā)語言等條件的限制。
RabbitMQ 最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，在易用性、擴展 性、高可用性等方面表現(xiàn)不俗。
RabbitMQ優(yōu)缺點
優(yōu)點:
erlang語言開發(fā)，性能極其好，延時很低；
吞吐量到萬級，MQ功能比較完備;
而且開源提供的管理界面非常棒，用起來很好用;
社區(qū)相對比較活躍，幾乎每個月都發(fā)布幾個版本在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些;
缺點:
RabbitMQ相較kafka確實吞吐量會低一些，這是因為他做的實現(xiàn)機制比較重;
erlang語言本身帶來的問題。很難讀源碼，很難定制和掌控。
rabbitmq集群動態(tài)擴展會很麻煩，不過這個我覺得還好。
RabbitMQ架構(gòu)圖
強烈推薦大家看看rabbitmq的中文文檔
架構(gòu)圖解釋
RabbitMQServer： 也叫brokerserver，它是一種傳輸服務(wù)。
他的角色就是維護一條 從Producer到Consumer的路線，保證數(shù)據(jù)能夠按照指定的方式進行傳輸。
Producer： 消息生產(chǎn)者，如圖A、B、C，數(shù)據(jù)的發(fā)送方。
消息生產(chǎn)者連接RabbitMQ服務(wù)器然后將消息投遞到Exchange。
Consumer：消息消費者，如圖1、2、3，數(shù)據(jù)的接收方。
消息消費者訂閱隊列，RabbitMQ將Queue中的消息發(fā)送到消息消費者。
Exchange：生產(chǎn)者將消息發(fā)送到Exchange（交換器），由Exchange將消息路由到一個或多個Queue中（或者丟棄)。
Exchange并不存儲消息。RabbitMQ中的Exchange有
direct、fanout、topic、headers四種類型，每種類型對應(yīng)不同的路由規(guī)則。
Queue：（隊列）是RabbitMQ的內(nèi)部對象，用于存儲消息。
消息消費者就是通過訂閱隊列來獲取消息的，RabbitMQ中的消息都只能存儲在Queue中
生產(chǎn)者生產(chǎn)消息并最終投遞到Queue中消費者可以從Queue中獲取消息并消費。多個消費者可以`訂閱同一個Queue`，
這時Queue中的消息會被`平均分攤`給多個消費者進行處理，而不是每個消費者都收到所有的消息并處理。
RoutingKey：生產(chǎn)者在將消息發(fā)送給Exchange的時候，一般會指定一個routingkey，來指定這個消息的路由規(guī)則
而這個routingkey需要與ExchangeType及bindingkey聯(lián) 合使用才能最終生效。
在ExchangeType與bindingkey固定的情況下（在正常使用時一般這些內(nèi)容都是固定配置好的）
我們的生產(chǎn)者就可以在發(fā)送消息給Exchange時，通過 指定routingkey來決定消息流向哪里。
RabbitMQ為routingkey設(shè)定的長度限制為255 bytes。
__________________________________________________________________________________________________
*下面某方面比較重要.b比如Channels可以開啟confirm模式進而做數(shù)據(jù)維護
Connection： （連接）：Producer和Consumer都是通過TCP連接到RabbitMQServer 的。
以后我們可以看到，程序的起始處就是建立這個TCP連接.
Channels： （信道）：它建立在上述的TCP連接中。數(shù)據(jù)流動都是在Channel中進行
的。也就是說，一般情況是程序起始建立TCP連接，第二步就是建立這個Channel。
VirtualHost：權(quán)限控制的基本單位
一個VirtualHost里面有若干Exchange和MessageQueue，以及指定被哪些user使用
我來一句話總結(jié)下我理解消息中間件
類似于廚師做完菜只管把菜送給服務(wù)員就可以忙自己的事了,服務(wù)員再對這些菜進行配送,這樣做呢,廚師和顧客的耦合就降下來了,而且廚師做菜和配送也不再是一個處理流程,做了異步.當做的菜太多了,我們也可以把它放一會或者讓廚師別做了或做別的去或者增加服務(wù)員數(shù)量.
另外這里說一下我用RabbitMQ的原因
1.語言無關(guān),什么語言都可以,對我們這邊很多使用不同語言開發(fā)的項目比較友好,大家都可以用
2.低時延,并發(fā)能力高,他是基于erlang語言開發(fā),erlang內(nèi)部對多線程做了很多優(yōu)化,然后他對操作系統(tǒng)的調(diào)度優(yōu)化基本相當于實現(xiàn)了自己的進程管理一樣. 進程非常輕量，短時間能快速創(chuàng)建和銷毀，并且切換代價小；Erlang 進程間通訊使用消息，而不是多線程編程中常用的鎖機制，沒有等待鎖的時間消耗。
3.管理界面比較好看,功能強大
4.最主要的是文檔比較完善,我們之前團隊一直用的都是這個RabbitMQ
