前言

學(xué)完了Redis，那你一定不能錯過消息隊列，要說他倆之間的關(guān)聯(lián)？關(guān)聯(lián)是有的，但也不見得很大，只是他們都是大數(shù)據(jù)領(lǐng)域常用的一種工具，一種用來提高程序運行效率的工具。常見于高并發(fā)，大數(shù)據(jù)，都是微服務(wù)領(lǐng)域不可獲取的工具。要說微服務(wù)的工具，還有很多，包括我們前面學(xué)過dubbo，es，nacos，seata，sentinel等，值得一提的是，大部分的工具其實都不需要我們寫太多的代碼，這也是工具本身的特點，它會在內(nèi)部幫我們處理好要走的流程，提高開發(fā)效率。消息隊列也是一樣的，下面，我們就來了解一下消息隊列吧。

消息隊列

什么是消息隊列

消息隊列中間件是分布式系統(tǒng)中的重要組件，主要用于解決應(yīng)用解耦，異步消息，流量削鋒等問題，實現(xiàn)高性能，高可用，可伸縮的最終目的。說人話就是：消息隊列是通過異步的方式來傳遞數(shù)據(jù)的過程。比如我們又想聽歌，又要吃飯，異步方式下，邊聽歌邊吃飯，互不影響，就是這么簡單。

為什么使用消息隊列

我們前面學(xué)習(xí)微服務(wù)時有一個創(chuàng)建訂單的操作，使用Dubbo處理的調(diào)用，分別是減庫存，刪購物車數(shù)據(jù)，生成訂單，分成了這三步，我們來思考下，這三步有什么必然聯(lián)系嗎？我可不可以打亂順序來做？我在微服務(wù)中使用了Seata，就是為了解決分布式事務(wù)同步問題，即使某一步出了問題，我也可以自動回滾，那么這三步之前其實就沒有任何聯(lián)系了。

但是Dubbo中，這三步是按照代碼順序來執(zhí)行的，而且是等待返回后才執(zhí)行下一步的，如果同一時間有很多創(chuàng)建訂單的請求過來，在不使用消息隊列異步的情況下，服務(wù)器的壓力就要翻好幾倍了，這不符合我們對程序高可用性的設(shè)計，所以這里最好的辦法就是讓他們并發(fā)的，異步的執(zhí)行。

誠然，有些調(diào)用是需要等待的，比如要先查一個id，再通過id獲取詳情的。但并不是所有的請求都需要如此，所以在使用中需要根據(jù)實際情況來做。

消息隊列的特點

這在上面我們已經(jīng)提到了，網(wǎng)上普遍流傳的特征主要是三個：解耦，異步，削峰。但根據(jù)實際使用，它還有另外兩個功能：日志和通訊。這兩個功能也是不可忽視的，像日志，雖然在業(yè)務(wù)上不體現(xiàn)出其重要性，一旦出現(xiàn)問題，其重要性自然不言而喻。下面，我們來看看他們分別都是做什么的。

解耦

解耦是針對業(yè)務(wù)的，是業(yè)務(wù)就有生產(chǎn)者和消費者，而生產(chǎn)者和消費者也絕對不可能只有一對，所以是一對多的關(guān)系，還有一些模塊或者對象，既是生產(chǎn)者，也是消費者。

生產(chǎn)者和消費者之間的關(guān)系是：生產(chǎn)者負(fù)責(zé)將消息正確的寫入消息隊列，其他的不關(guān)心。消費者負(fù)責(zé)從消息隊列中讀取消息，在進行邏輯處理。你會發(fā)現(xiàn)，生產(chǎn)者和消費者之間沒有任何的直接交互。

沒有交互，就沒有耦合。而耦合度越低的代碼，越有利于維護和擴展。說起來，很像是移動端里的通知或者廣播。

異步

說到異步，不得不說說同步：同步是請求的調(diào)用方直到調(diào)用結(jié)果返回之前一直處于等待狀態(tài)，這期間，調(diào)用方之后的業(yè)務(wù)將不會執(zhí)行，一直等待調(diào)用結(jié)束后再執(zhí)行。

異步，我相信不需要我說太多，大家都知道它的工作方式：無需等待，直接執(zhí)行。

異步處理的主要目的是：減少請求響應(yīng)時間，實現(xiàn)非核心流程異步化，提高系統(tǒng)響應(yīng)性能。所以說，同步還是異步，都是需要的，只是看業(yè)務(wù)能接受等待的程度有多少，根據(jù)需要選擇即可。

但是異步有一個明顯的缺點，我寫進異步隊列的任務(wù)是存在延時的。調(diào)用方無法得知何時能得到響應(yīng)，所以使用異步時，也要考慮業(yè)務(wù)是否能接受這樣的延時，舉個例子：發(fā)送驗證碼。這就是個典型的消息隊列，同一時間誰也不知道有多少條短信需要發(fā)送，都是放在隊列里執(zhí)行的，如果執(zhí)行的任務(wù)很多，那么你收到驗證碼的時間就會很長。

削峰

削峰的完整表達(dá)應(yīng)該是削峰填谷。在并發(fā)峰值超過當(dāng)前系統(tǒng)處理能力時，將沒處理的信息保存在消息隊列中，在后面較閑的時間中去處理，直到所有數(shù)據(jù)依次處理完成。這能夠防止在并發(fā)峰值時短時間大量請求而導(dǎo)致的系統(tǒng)不穩(wěn)定。上面提到的短信驗證碼也是這樣的，所以延時是無法避免的。

消息日志

我們當(dāng)然希望日志可以實時保存，這樣出了問題才能很好的定位。甚至我們在講Redis的時候提到過AOF，忘記的童鞋回頭再看看：Java開發(fā) - Redis初體驗

AOF保存的就是日志，1s一次，Redis的保存機制是什么，博主不清楚，但我非常清楚的是，這種實時的日志保存必然會造成服務(wù)器的巨大消耗，前提是數(shù)據(jù)量非常大的情況。此時如果將日志放在消息隊列中，忙的時候等待，在不忙的時候處理，也不失為一種好的效率機制。在這里，我們要區(qū)分日志登等級，如果是Redis這種可斷電恢復(fù)的日志級別，我們可能不太希望它出現(xiàn)延時，是吧？

通訊

消息隊列一般都內(nèi)置了高效的通信機制，因此可以用于單純的消息通訊，比如實現(xiàn)點對點消息隊列或者聊天室。關(guān)于此，涉及到的知識很廣，刨根問題的話還是自己查吧，說實話，博主也不可能講太清楚。

常見消息隊列

目前博主所知的消息隊列有以下幾種：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。排名不分先后！！！

ActiveMQ

ActiveMQ是前幾年流行的，一些老項目可能用到。Apache ActiveMQ是Apache軟件基金會所研發(fā)的開放源代碼消息中間件；由于ActiveMQ是一個純Java程序，因此只需要操作系統(tǒng)支持Java虛擬機，ActiveMQ便可執(zhí)行。但目前主流的消息隊列更好用，這個便慢慢被擱淺了，目前用的人應(yīng)該會慢慢減少，畢竟沒有幾個人擋得住Kafka和RabbitMQ的摧殘。

RabbitMQ

RabbitMQ是使用Erlang語言開發(fā)的開源消息隊列系統(tǒng)，基于AMQP協(xié)議來實現(xiàn)。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發(fā)布/訂閱)、可靠性、安全。AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。所以在Java業(yè)務(wù)中使用很多，目前我所知道的很多都是用的此消息隊列，只不過大家評價都是：功能強，性能一般。與其相反的，就是Kafka了：性能強，功能弱。

這是因為他們設(shè)計的目的不一樣，RabbitMQ 在有大量消息堆積的情況下性能會下降，其優(yōu)勢體現(xiàn)在功能上。而Kafka一開始是用來處理海量日志的，所以體現(xiàn)出來就是性能強，功能弱。

所謂，尺有所短，寸有所長，正是這個道理。全都兼顧的幾乎是不存在的。

ZeroMQ

ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內(nèi)核和主機盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進入Linux內(nèi)核”。還未看到它們的成功。但是，它無疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一層封裝。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡單和有趣。

以上是官方的自high，具體怎么樣，還需要大家的評判。不過由于其提供跨越多種傳輸協(xié)議的套接字，基于此，還是有一部分人在用的。

Kafka

Kafka是由Apache軟件基金會開發(fā)的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費者在網(wǎng)站中的所有動作流數(shù)據(jù)。 這種動作（網(wǎng)頁瀏覽，搜索和其他用戶的行動）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決。 對于像Hadoop一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的并行加載機制來統(tǒng)一線上和離線的消息處理，也是為了通過集群來提供實時的消息。

值得一提的是，kafka的誕生，是為了解決linkedin的數(shù)據(jù)管道問題，起初linkedin采用了ActiveMQ來進行數(shù)據(jù)交換，不過，這也已經(jīng)是十幾年前的事了。

哦，另外要說的是，Kafka自身服務(wù)和消費者都需要依賴Zookeeper，而Zookeeper的作用是：可以修改服務(wù)器系統(tǒng)中的所有軟件配置。所以，長此以往，很多軟件就刪除了自己寫配置文件的功能，而直接從Zookeeper中獲取。

MetaMQ

MetaMQ是一個基于以太坊的可擴展分布式消息隊列，由于其介紹非常少，所以使用的人也不多，此消息隊列就不再說明了，有興趣的可自行了解。

RocketMQ

RocketMQ是阿里開源的消息中間件，它是純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點。其起源于Kafka，但Kafka無法滿足其需求，尤其表現(xiàn)在低延遲和高可靠性方面，在這種情況下，RocketMQ誕生了，它是通過一個新的消息傳遞引擎來處理更廣泛的消息用例，覆蓋從傳統(tǒng)的pub/sub場景到高容量的實時零誤差的交易系統(tǒng)。

Apache RocketMQ 自誕生以來，因其架構(gòu)簡單、業(yè)務(wù)功能豐富、具備極強可擴展性等特點被眾多企業(yè)開發(fā)者以及云廠商廣泛采用。歷經(jīng)十余年的大規(guī)模場景打磨，RocketMQ 已經(jīng)成為業(yè)內(nèi)共識的金融級可靠業(yè)務(wù)消息首選方案，被廣泛應(yīng)用于互聯(lián)網(wǎng)、大數(shù)據(jù)、移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等領(lǐng)域的業(yè)務(wù)場景。

不過據(jù)說其沒有?Web?管理界面，提供了一個?CLI?(命令行界面) 管理工具來?查詢、管理?和?診斷各種問題。但是在新版本中，博主注意到，已經(jīng)有管理頁面了。具體，推薦查看此博客：Rocketmq單機部署以及管理界面 - 知乎

感興趣的可以看看其官網(wǎng)：為什么選擇RocketMQ | RocketMQ

總結(jié)

總結(jié)，也沒什么好總結(jié)的，各有千秋吧，不過目前使用最多的還是RabbitMQ和Kafka，關(guān)于消息隊列，想了解的更詳細(xì)的話，推薦這篇博客，講的很深：常見消息隊列 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等詳解和對比 - 知乎

結(jié)語

最后了，說點啥？還是說說關(guān)于消息隊列博主的教程方向吧。后續(xù)，博主會通過兩篇博客來分別講解RabbitMQ和Kafka的實戰(zhàn)用法，此篇權(quán)當(dāng)給大家一個前瞻，了解下即可。里面內(nèi)容都是博主的一些體會和參考一些詞條寫成的，如有不準(zhǔn)確的地方，歡迎指正，碼文不易，覺得不錯，請不要吝惜你們的贊，收藏和評論，謝謝。