建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲 。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。
我們提供的服務(wù)有：網(wǎng)站建設(shè)、成都做網(wǎng)站、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、原陽(yáng)ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的原陽(yáng)網(wǎng)站制作公司
關(guān)于消息隊(duì)列，斷斷續(xù)續(xù)的看了很多資料，一直想抽個(gè)時(shí)間把這些知識(shí)整理記錄下來(lái)，但是沒(méi)騰出時(shí)間來(lái)寫(xiě)，正好所在的項(xiàng)目在實(shí)際業(yè)務(wù)中使用到了消息隊(duì)列，索性就將這方面的知識(shí)整理一下，可能有理解不到位的地方，望網(wǎng)友批評(píng)指出!
一、消息隊(duì)列由來(lái)
可能在你沒(méi)了解消息隊(duì)列之前，已經(jīng)聽(tīng)過(guò)很多概念了，例如 JMS，AMQP，ActiveMQ，RabbitMQ，RocketMQ，Kafka 等等。
一個(gè)消息中間件，咋搞出這么多概念?
別慌，我們先從歷史角度來(lái)理清這些 MQ 和協(xié)議之間的關(guān)系!
消息中間件其實(shí)誕生的很早，在互聯(lián)網(wǎng)應(yīng)用還是一片荒蕪的年代，有個(gè)在美國(guó)的印度小哥 Vivek Ranadive 就設(shè)想了一種通用軟件總線，采用發(fā)布訂閱的模式，類似于電腦主板上的總線，新的設(shè)備或者程序如果想和電腦上其他的設(shè)備軟件通信，只需要按照協(xié)議對(duì)接總線就可以完成接入和通信!
在 1983 年，26歲的印度小哥 Vivek Ranadive 創(chuàng)辦了一家公司 Teknekron，實(shí)現(xiàn)了世界上第一個(gè)消息中間件The Information Bus(TIB)。
很快 TIB 軟件受到了企業(yè)的歡迎，最初被高盛集團(tuán)用于解決金融交易，Teknekron 的業(yè)務(wù)發(fā)展速度甚至引起了當(dāng)時(shí)最牛逼的 IT 公司 IBM 的注意。
于是 IBM 也開(kāi)始組建團(tuán)隊(duì)來(lái)研發(fā)自己的消息隊(duì)列軟件，這才有了后來(lái)的wesphere mq，不久微軟也加入了戰(zhàn)團(tuán)。
由于商業(yè)壁壘，每個(gè)軟件廠商都按照自己的標(biāo)準(zhǔn)來(lái)實(shí)現(xiàn)軟件通信，導(dǎo)致企業(yè)客戶不能隨便更換 MQ 平臺(tái)。
為了打破這個(gè)壁壘，同時(shí)為了能夠讓消息在各個(gè)消息隊(duì)列平臺(tái)間互融互通， JMS (Java Message Service) 應(yīng)運(yùn)而生 。
JMS 試圖通過(guò)提供公共 Java API 的方式，隱藏單獨(dú) MQ 產(chǎn)品供應(yīng)商提供的實(shí)現(xiàn)接口，從而跨越了壁壘，已解決互通問(wèn)題。
從技術(shù)上講， Java 應(yīng)用程序只需針對(duì) JMS API 進(jìn)行編程，選擇合適的 MQ 驅(qū)動(dòng)即可， JMS 會(huì)打理好其他部分，就好比類似于 JDBC，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，只需要編寫(xiě)好 sql，具體是使用 oracle 還是 mysql 或者 sqlserver，由具體的廠商來(lái)提供驅(qū)動(dòng)包文件即可，開(kāi)發(fā)者無(wú)需關(guān)心具體的數(shù)據(jù)庫(kù)廠商，從而大大的提升了開(kāi)發(fā)效率、降低了開(kāi)發(fā)難度。
ActiveMQ 就是 JMS 的 一種具體實(shí)現(xiàn)。
- JMS - 點(diǎn)對(duì)點(diǎn)模型
JMS - 點(diǎn)對(duì)點(diǎn)模型
- JMS - 發(fā)布訂閱模型
JMS - 發(fā)布訂閱模型
盡管使用標(biāo)準(zhǔn)化接口能有效的融合眾多不同的 MQ 產(chǎn)品，但是也暴露出很多問(wèn)題，例如有些 MQ 產(chǎn)品提供了非常高級(jí)的功能，但由于標(biāo)準(zhǔn)化接口的限制，導(dǎo)致用戶無(wú)法使用，所以急需一種新的消息通信標(biāo)準(zhǔn)化方案。
在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等人聯(lián)合制定了 AMQP 的公開(kāi)標(biāo)準(zhǔn)，由此 AMQP 登上了歷史的舞臺(tái)。
AMQP 是應(yīng)用層協(xié)議的一個(gè)開(kāi)放標(biāo)準(zhǔn)，以解決眾多消息中間件的需求和拓?fù)浣Y(jié)構(gòu)問(wèn)題，它為面向消息的中間件設(shè)計(jì)，基于此協(xié)議的客戶端與消息中間件可傳遞消息，同時(shí)并不受產(chǎn)品、開(kāi)發(fā)語(yǔ)言等條件的限制。
JMS vs AMQP
RabbitMQ 就是 AMQP 的一種具體實(shí)現(xiàn)。
AMQP - 模型
隨著時(shí)間的推進(jìn)，雖然 AMQP 規(guī)范能適用的業(yè)務(wù)場(chǎng)景很多，但是 LinkedIn(領(lǐng)英) 在實(shí)現(xiàn)消息隊(duì)列的時(shí)候覺(jué)得 AMQP 規(guī)范并不適合自己，于是在設(shè)計(jì) Kafka 的時(shí)候，并不支持 AMQP 所有的特性。
同時(shí)阿里巴巴的 RocketMQ 在實(shí)現(xiàn)上也借鑒了 Kakfa 的思想，也不支持 AMQP 協(xié)議，并且你會(huì)發(fā)現(xiàn)在 Kafka 和 RocketMQ 中都有類似 Topic 和 Consumer Group 的概念，而這些概念在 AMQP 協(xié)議中并不存在。
二、為什么要使用消息隊(duì)列
消息中間件雖然發(fā)展了很多年，但是不是每個(gè)項(xiàng)目都有機(jī)會(huì)能接觸到消息隊(duì)列，對(duì)于初次接觸 MQ 的同學(xué)，難免會(huì)發(fā)出一些疑問(wèn)!
什么是消息隊(duì)列?為什么要使用消息隊(duì)列?使用消息隊(duì)列有哪些弊端?
對(duì)于傳統(tǒng)的應(yīng)用程序，如果需要向另一個(gè)應(yīng)用程序發(fā)送信息，只需要向其發(fā)出請(qǐng)求即可!
這種方式雖然簡(jiǎn)單直接，但是如果應(yīng)用程序2突然掛了，應(yīng)用程序1可能會(huì)因?yàn)榉?wù)異常，而無(wú)法繼續(xù)提供服務(wù)!
設(shè)想一下，在應(yīng)用程序1和應(yīng)用程序2之間，插入一個(gè)消息服務(wù)，主要用于接受消息和發(fā)送消息，這樣應(yīng)用程序1和應(yīng)用程序2之間的依賴關(guān)系就解耦了，同時(shí)也不會(huì)因?yàn)槿魏我环疆?dāng)服務(wù)不可用時(shí)，無(wú)法繼續(xù)提供服務(wù)!
其中插入的消息服務(wù)被稱為消息隊(duì)列!
由此可見(jiàn)，引入消息隊(duì)列帶來(lái)的優(yōu)勢(shì)很明顯：
- 程序解耦：應(yīng)用程序1和應(yīng)用程序2在進(jìn)行交互時(shí)，不會(huì)因?yàn)橐环椒?wù)中斷而導(dǎo)致服務(wù)停止;
- 異步處理：程序解耦之后，帶來(lái)的最大的好處就是可以異步處理，應(yīng)用程序1只管把消息發(fā)送到消息中間件，應(yīng)用程序2只需要從消息中間件中接受消息然后進(jìn)行處理即可;
同時(shí)，基于異步處理特性，在某些業(yè)務(wù)場(chǎng)景下，例如商品秒殺活動(dòng)，引入消息隊(duì)列之后，當(dāng)客戶端請(qǐng)求量很大的時(shí)候，可以有效的進(jìn)行流量削峰!
如果沒(méi)有中間層做緩沖，當(dāng)進(jìn)行商品秒殺時(shí)，一下突然大量請(qǐng)求涌入，很可能造成系統(tǒng)直接癱瘓，甚至宕機(jī)!
在大型網(wǎng)站系統(tǒng)中，如何通過(guò)日志快速實(shí)時(shí)定位系統(tǒng)異常的代碼，可以說(shuō)至關(guān)重要!
LinkedIn 開(kāi)發(fā)的消息隊(duì)列 Kafka，可以說(shuō)是日志采集方面的王者，在中、大型系統(tǒng)開(kāi)發(fā)中，將消息隊(duì)列 Kafka 用在日志處理中，可以有效的解決大量日志傳輸?shù)膯?wèn)題。
當(dāng)然，引入消息隊(duì)列也會(huì)帶來(lái)很明顯的弊端：
- 系統(tǒng)可用性降低：在引入消息隊(duì)列之前，你不用考慮消息丟失或者消息隊(duì)列服務(wù)掛掉等等的情況，但是引入消息隊(duì)列之后你就需要去考慮這些問(wèn)題!
- 系統(tǒng)復(fù)雜性提高：加入消息隊(duì)列之后，你需要保證消息沒(méi)有被重復(fù)消費(fèi)、處理消息沒(méi)有被正確處理的情況等等問(wèn)題!
引入消息隊(duì)列雖然會(huì)帶來(lái)一些問(wèn)題，俗話說(shuō)，兵來(lái)將擋、水來(lái)土掩，這句話同樣適用于 IT 開(kāi)發(fā)者，有坑填坑!
對(duì)于系統(tǒng)可用性降低方面，通常常用的解決方案就是搭建消息服務(wù)集群，具體技術(shù)實(shí)現(xiàn)上可以是主從架構(gòu)或者分布式架構(gòu)，即時(shí)一臺(tái)消息隊(duì)列服務(wù)機(jī)器掛了，也不會(huì)影響消息隊(duì)列無(wú)法提供服務(wù)!
對(duì)于系統(tǒng)復(fù)雜性提高方面，常用的解決方案也很多，例如接受者接受到消息之后，可以先將消息寫(xiě)入數(shù)據(jù)庫(kù)，即時(shí)沒(méi)有被正確處理，還可以走人工處理，或者消息消費(fèi)失敗，將消息重新入隊(duì)等待下一次消費(fèi)等等。
三、常見(jiàn)的消息隊(duì)列對(duì)比
目前比較主流的 MQ 產(chǎn)品，有 ActiveMQ，RabbitMQ，RocketMQ，Kafka，并且他們都是開(kāi)源的，他們各自也有各自的特點(diǎn)。
總結(jié)內(nèi)容如下
- 1.ActiveMQ 的社區(qū)算是比較成熟，但是較目前來(lái)說(shuō)，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。
- 2.RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ，但是由于它基于 erlang 開(kāi)發(fā)，所以并發(fā)能力很強(qiáng)，性能極其好，延時(shí)很低，達(dá)到微秒級(jí)。但是也因?yàn)?RabbitMQ 基于 erlang 開(kāi)發(fā)，所以國(guó)內(nèi)很少有公司有實(shí)力做erlang源碼級(jí)別的研究和定制。如果業(yè)務(wù)場(chǎng)景對(duì)并發(fā)量要求不是太高(十萬(wàn)級(jí)、百萬(wàn)級(jí))，那這四種消息隊(duì)列中，首選 RabbitMQ。如果是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算、日志采集等場(chǎng)景，用 Kafka 是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對(duì)沒(méi)問(wèn)題，社區(qū)活躍度很高，絕對(duì)不會(huì)黃，何況幾乎是全世界這個(gè)領(lǐng)域的事實(shí)性規(guī)范。
- 3.RocketMQ 阿里出品，Java 系開(kāi)源項(xiàng)目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的實(shí)際業(yè)務(wù)場(chǎng)景的實(shí)戰(zhàn)考驗(yàn)。RocketMQ 社區(qū)活躍度相對(duì)較為一般，不過(guò)也還可以，文檔相對(duì)來(lái)說(shuō)簡(jiǎn)單一些。還有就是阿里出臺(tái)的技術(shù)，你得應(yīng)對(duì)這個(gè)技術(shù)萬(wàn)一被拋棄，社區(qū)黃掉的風(fēng)險(xiǎn)，如果你們公司有技術(shù)實(shí)力我覺(jué)得用RocketMQ 挺好的。
- 4.Kafka 的特點(diǎn)其實(shí)很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級(jí)的延遲，極高的可用性以及可靠性，而且分布式可以任意擴(kuò)展。同時(shí) Kafka 最好是支撐較少的 topic 數(shù)量即可，保證其超高吞吐量。Kafka 唯一的一點(diǎn)劣勢(shì)是有可能消息重復(fù)消費(fèi)，那么對(duì)數(shù)據(jù)準(zhǔn)確性會(huì)造成極其輕微的影響，在大數(shù)據(jù)領(lǐng)域中以及日志采集中，這點(diǎn)輕微影響可以忽略。Kafka天然適合大數(shù)據(jù)實(shí)時(shí)計(jì)算以及日志收集。
四、總結(jié)
本文主要對(duì)消息隊(duì)列的歷史和基礎(chǔ)知識(shí)進(jìn)行梳理和初步介紹，如果有理解不對(duì)的地方，望網(wǎng)友批評(píng)指出!
五、參考
1、Java工程師面試突擊第1季-中華石杉老師
2、消息中間件的發(fā)展史
3、JavaGuide - 消息隊(duì)列
標(biāo)題名稱：面試官提問(wèn)：說(shuō)說(shuō)你對(duì)消息隊(duì)列的理解
標(biāo)題URL：http://m.5511xx.com/article/cdgojoj.html
