背景
RabbitMQ現(xiàn)在用的也比較多，但是沒(méi)有過(guò)去那么多啦。現(xiàn)在很多的流行或者常用技術(shù)或者思路都是從過(guò)去的思路中演變而來(lái)的。了解一些過(guò)去的技術(shù)，對(duì)有些人來(lái)說(shuō)可能會(huì)產(chǎn)生眾里尋他千百度的頓悟，加深對(duì)技術(shù)的理解，更好的應(yīng)用于工作中去。
本篇整體采用從淺到深的邏輯結(jié)構(gòu)來(lái)描述。
入門部分
什么是MQ
MQ全稱是Message Queue，消息的隊(duì)列。因?yàn)槭顷?duì)列，所以遵循FIFO先進(jìn)先出原則。因?yàn)榇娣诺氖窍ⅲ允且环N跨進(jìn)程的通信機(jī)制。
為什么使用MQ
流量削峰
這個(gè)跟很火的小吃店門口的排隊(duì)原理是一樣的。實(shí)時(shí)調(diào)用就好像是大家蜂擁而至，如果系統(tǒng)處理能力不夠，就會(huì)讓店家手忙腳亂，說(shuō)不定會(huì)在冰激凌上澆上可樂(lè)。排隊(duì)能保證有條不紊，代價(jià)是整體處理速度會(huì)慢些。
異步處理
當(dāng)A調(diào)用B，B可能要花很長(zhǎng)一段時(shí)間來(lái)完成。這時(shí)候一般有三種方式來(lái)異步處理。A調(diào)用B，B返回A說(shuō)收到調(diào)用請(qǐng)求了。同步請(qǐng)求已經(jīng)完成，但B的執(zhí)行才剛開(kāi)始。這時(shí)候，第一種方式是A每隔一段時(shí)間來(lái)查詢一次，看B是否執(zhí)行完，這是拉的方式；第二種方式是A提供一個(gè)回調(diào)地址，B執(zhí)行完之后回調(diào)A，這是推的方式；第三種就是使用MQ，A使用MQ給B發(fā)消息，B處理完再回一個(gè)消息，好處是上面提到的同時(shí)可以流量削峰。
應(yīng)用解耦
MQ實(shí)現(xiàn)了邏輯解耦+物理解耦。邏輯上，將請(qǐng)求和結(jié)果處理分開(kāi)了；物理上，系統(tǒng)只用與MQ通信。聽(tīng)起來(lái)，MQ要優(yōu)雅很多，但是上面提到異步處理的三種方式的前兩種，現(xiàn)在也多很常見(jiàn)。那是因?yàn)镸Q是有代價(jià)的，那就是需要一套MQ設(shè)施。做開(kāi)放平臺(tái)，用戶之間的唯一設(shè)施就是互聯(lián)網(wǎng)，這時(shí)候更依賴雙方的協(xié)議約定，所以前兩種異步處理方式不會(huì)被MQ取代。
MQ的分類
ActiveMQ是早期的MQ，倚老賣老一下，我那個(gè)年代用過(guò)，目前優(yōu)勢(shì)已經(jīng)不太明顯了。
Kafka號(hào)稱是大數(shù)據(jù)的殺手锏，以百萬(wàn)級(jí)TPS吞吐量名聲大噪。時(shí)效是ms級(jí)別，分布式的可用性高。消費(fèi)者采用拉的方式獲取消息，消息有序，通過(guò)控制可以保證消息僅被消費(fèi)一次。但是單機(jī)超過(guò)64個(gè)分區(qū)，load會(huì)明顯飆高；實(shí)時(shí)性取決于輪詢時(shí)間間隔，關(guān)鍵是有可能丟消息，不適合訂單業(yè)務(wù)中使用。
RocketMQ是國(guó)貨，用Java語(yǔ)言實(shí)現(xiàn)，在設(shè)計(jì)時(shí)參考了Kafka，單機(jī)吞吐量達(dá)到十萬(wàn)級(jí)別，分布式架構(gòu)可用性高，消息可以0丟失，擴(kuò)展性高。但是支持的客戶端成熟的也就是Java，核心代碼沒(méi)有實(shí)現(xiàn)JMS，遷移需要修改大量代碼。
RabbitMQ是erlang開(kāi)發(fā)的，吞吐量達(dá)到萬(wàn)級(jí)別，穩(wěn)定、健壯、跨平臺(tái)，支持多種語(yǔ)言，企業(yè)間通信中常用。
JMS支持
RabbitMQ不支持JMS協(xié)議。這個(gè)很好理解。因?yàn)镴MS是Java消息服務(wù)，提供了消息傳遞的Java標(biāo)準(zhǔn)API。而RabbitMQ是Erlang寫的，對(duì)Java的支持會(huì)弱一些。但是RabiitMQ實(shí)現(xiàn)了AMQP標(biāo)準(zhǔn)協(xié)議。AMQP只是統(tǒng)一了數(shù)據(jù)交換的標(biāo)準(zhǔn)格式，與語(yǔ)言無(wú)關(guān)。
核心部分
核心概念
所有的MQ都由生產(chǎn)者、消費(fèi)者和broker(隊(duì)列)三部分組成。但是不同的實(shí)現(xiàn)，根據(jù)核心思想不同，內(nèi)部結(jié)構(gòu)也各有特色。
比如銀行系統(tǒng)中常用的跨銀行間通信的MQ，相當(dāng)于兩組MQ拼起來(lái)的。
普通MQ
跨企業(yè)MQ
這樣做的好處是任何一端網(wǎng)絡(luò)出現(xiàn)問(wèn)題，都可以暫存消息，等待網(wǎng)絡(luò)恢復(fù)，不丟失消息。消息的重試放在broker端，減少了應(yīng)用端的復(fù)雜度。為什么這里舉例時(shí)提到銀行間使用呢，因?yàn)槭褂眠@種模式的MQ，最重要的是有錢。因?yàn)橄脒_(dá)到理想效果，要拉專線，并使用高配機(jī)器。
RabbitMQ和Kafka是一樣的
再回來(lái)考慮普通MQ的場(chǎng)景，如果這個(gè)MQ是RabbitMQ。組件細(xì)化一下是這樣：
這張圖上來(lái)看，其實(shí)RabbitMQ和Kafka是一樣的。來(lái)看Kafka的：
表面上來(lái)看，RabbitMQ的服務(wù)器(Broker)端由Exchange和Queue兩部分組成。Exchange是交換機(jī)，交換機(jī)是做路由的。Kafka生產(chǎn)者發(fā)到Broker也需要路由啊，來(lái)決定路由到哪個(gè)Partition(也就是隊(duì)列)中去。只不過(guò)Kafka的路由模式很固定，就是先找到哪個(gè)topic，然后使用負(fù)載均衡的策略找到一個(gè)Partition來(lái)投遞消息。Kafka是用了邏輯概念topic簡(jiǎn)化了exchange路由，所以Kafka的路由功能也很單一。
表面上，RabbitMQ的生產(chǎn)者和消費(fèi)者與服務(wù)端都是Channel信道來(lái)相連。Channel是復(fù)用連接來(lái)進(jìn)行通信的，Kafka也是需要的，只是它內(nèi)部幫我們把這些與核心功能關(guān)系不大的都自己內(nèi)置實(shí)現(xiàn)了。而RabbitMQ暴露給用戶，提供了更高的靈活性。
上面的兩段如果我沒(méi)有講明白，也沒(méi)有關(guān)系。只要知道更年輕的Kafka沒(méi)有Exchange和Channel的概念是類似于采取了約定大于配置的方式提供的服務(wù)。
核心功能
RabbitMQ的核心實(shí)際上就是AMQP的核心：MessageQueue、Exchange和Binding。
MessageQueue就是消息隊(duì)列，一個(gè)隊(duì)列里的一條消息，也就是同一個(gè)message ID對(duì)應(yīng)的消息，不管有多少個(gè)消費(fèi)者來(lái)分?jǐn)倝毫?，也只能被消費(fèi)一次。消息隊(duì)列和消費(fèi)者之間有ack機(jī)制，消息一旦確認(rèn)安全送達(dá)，RabbitMQ服務(wù)端就可以安全刪除消息了。
Binding是MessageQueue與Exchange之間的連接，Exchange只能給Binding的MessageQueue發(fā)送消息。
Exchange有四種類型：fanout、topic、direct和header。本質(zhì)上就是有一堆MessageQueue，一個(gè)消息是要被復(fù)制幾份，發(fā)到哪幾個(gè)Binding的消息隊(duì)列去。Exchange給定了規(guī)則：fanout是對(duì)每個(gè)消息隊(duì)列復(fù)制一份發(fā)送；direct意思是只發(fā)指定的一份，不復(fù)制；topic是發(fā)送通配符匹配的幾份；header可以指定一些其他的過(guò)濾條件發(fā)送。消息從生產(chǎn)者發(fā)送到exchange之后也有ack機(jī)制來(lái)保證消息的可靠傳輸。
Kafka只有topic的概念。這是因?yàn)镵afka的設(shè)計(jì)上消息只用存一份，通過(guò)游標(biāo)，發(fā)送后不立即刪除消息。多個(gè)消費(fèi)者組可以互不影響的消費(fèi)。這是Kafka的一大改進(jìn)。
內(nèi)部原理
大家面試時(shí)有沒(méi)有被問(wèn)過(guò)：Kafka怎么保證消息能且僅能收到一次？這是個(gè)埋坑題，是與面試官斗智斗勇的開(kāi)始。什么冪等、事務(wù)、流式EOS呀，其實(shí)呢，Kafka本身是不保證僅且僅收到一次的，所以這些實(shí)現(xiàn)方法都不優(yōu)雅。
RabbitMQ通過(guò)AMQP事務(wù)機(jī)制，還有上面已經(jīng)提過(guò)的ack也就是confirm兩種可選方式保證消息被收到。
但是最為優(yōu)雅的實(shí)現(xiàn)是IBM的Websphere MQ。因?yàn)檫@是收費(fèi)的，所以研究的人不多。它通過(guò)消息序列號(hào)保證消息不丟失、不重傳。
通道為每條消息的傳送分配一個(gè)序列號(hào)，它會(huì)自動(dòng)累積增值。消息序列號(hào)由發(fā)送通道分配，是通道的一個(gè)永久屬性，每當(dāng)發(fā)送一條消息，消息序列號(hào)就加一。通道的相關(guān)屬性SEQWRAP標(biāo)識(shí)序號(hào)的最大值，缺省為999,999,999。序列號(hào)越界后自動(dòng)歸零，從頭開(kāi)始。
正常情況下，通道兩端的消息序列號(hào)或者相等或相差為一。雙方對(duì)前面的某一條或一批消息是否發(fā)送成功理解不一致。在解決了不確定的消息后，可以用MQSC命令通過(guò)重置消息序號(hào)將雙方調(diào)整到一致。一旦連接斷開(kāi)后，通道重連時(shí)雙方會(huì)將消息序號(hào)同步。
聯(lián)系客服
