1. MQ 的相關(guān)概念
1.1 什么是 MQ
MQ(message queue),從字面意思上看,本質(zhì)是個(gè)隊(duì)列,F(xiàn)IFO 先入先出,只不過隊(duì)列中存放的內(nèi)容是message 而已,還是一種跨進(jìn)程的通信機(jī)制,用于上下游傳遞消息。在互聯(lián)網(wǎng)架構(gòu)中,MQ 是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務(wù)。使用了 MQ 之后,消息發(fā)送上游只需要依賴 MQ,不用依賴其他服務(wù)。
1.2 為什么要用 MQ
- 流量消峰
舉個(gè)例子,如果訂單系統(tǒng)最多能處理一萬次訂單,這個(gè)處理能力應(yīng)付正常時(shí)段的下單時(shí)綽綽有余,正常時(shí)段我們下單一秒后就能返回結(jié)果。但是在高峰期,如果有兩萬次下單操作系統(tǒng)是處理不了的,只能限制訂單超過一萬后不允許用戶下單。使用消息隊(duì)列做緩沖,我們可以取消這個(gè)限制,把一秒內(nèi)下的訂單分散成一段時(shí)間來處理,這時(shí)有些用戶可能在下單十幾秒后才能收到下單成功的操作,但是比不能下單的體驗(yàn)要好。
- 應(yīng)用解耦
以電商應(yīng)用為例,應(yīng)用中有訂單系統(tǒng)、庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)。用戶創(chuàng)建訂單后,如果耦合調(diào)用庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng),任何一個(gè)子系統(tǒng)出了故障,都會(huì)造成下單操作異常。當(dāng)轉(zhuǎn)變成基于消息隊(duì)列的方式后,系統(tǒng)間調(diào)用的問題會(huì)減少很多,比如物流系統(tǒng)因?yàn)榘l(fā)生故障,需要幾分鐘來修復(fù)。在這幾分鐘的時(shí)間里,物流系統(tǒng)要處理的內(nèi)存被緩存在消息隊(duì)列中,用戶的下單操作可以正常完成。當(dāng)物流系統(tǒng)恢復(fù)后,繼續(xù)處理訂單信息即可,中單用戶感受不到物流系統(tǒng)的故障,提升系統(tǒng)的可用性。
- 異步處理
有些服務(wù)間調(diào)用是異步的,例如 A 調(diào)用 B,B 需要花費(fèi)很長時(shí)間執(zhí)行,但是 A 需要知道 B 什么時(shí)候可以執(zhí)行完,以前一般有兩種方式,A 過一段時(shí)間去調(diào)用 B 的查詢 api 查詢?;蛘?A 提供一個(gè) callback api,B 執(zhí)行完之后調(diào)用 api 通知 A 服務(wù)。這兩種方式都不是很優(yōu)雅,使用消息隊(duì)列,可以很方便解決這個(gè)問題,A 調(diào)用 B 服務(wù)后,只需要監(jiān)聽 B 處理完成的消息,當(dāng) B 處理完成后,會(huì)發(fā)送一條消息給 MQ,MQ 會(huì)將此消息轉(zhuǎn)發(fā)給 A 服務(wù)。這樣 A 服務(wù)既不用循環(huán)調(diào)用 B 的查詢 api,也不用提供 callback api。同樣 B 服務(wù)也不用做這些操作。A 服務(wù)還能及時(shí)的得到異步處理成功的消息。
1.3 MQ 的分類
- ActiveMQ
優(yōu)點(diǎn):?jiǎn)螜C(jī)吞吐量萬級(jí),時(shí)效性 ms 級(jí),可用性高,基于框架實(shí)現(xiàn)高可用性,消息可靠性較低,概率丟失數(shù)據(jù)。
缺點(diǎn):官方社區(qū)現(xiàn)在對(duì) ActiveMQ 5.x 維護(hù)越來越少,高吞吐量場(chǎng)景較少使用。
- Kafka
大數(shù)據(jù)的殺手锏,談到大數(shù)據(jù)領(lǐng)域內(nèi)的消息傳輸,則繞不開 Kafka,這款為大數(shù)據(jù)而生的消息中間件,以其百萬級(jí) TPS 的吞吐量名聲大噪,迅速成為大數(shù)據(jù)領(lǐng)域的寵兒,在數(shù)據(jù)采集、傳輸、存儲(chǔ)的過程中發(fā)揮著舉足輕重的作用。目前已經(jīng)被 LinkedIn,Uber, Twitter, Netflix 等大公司所采納。
優(yōu)點(diǎn):性能卓越,最大的優(yōu)點(diǎn)就是吞吐量高,百萬級(jí)別,時(shí)效性 ms 級(jí),可用性高,kafka 是分布式的,一個(gè)數(shù)據(jù)多個(gè)副本,少數(shù)機(jī)器當(dāng)即,不會(huì)丟失數(shù)據(jù),不會(huì)導(dǎo)致不可用,消費(fèi)者采用 Pull 方式獲取消息,消息有序,通過控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次。
缺點(diǎn):kafka 單機(jī)超過 64 個(gè)隊(duì)列/分區(qū),Load 會(huì)發(fā)生明顯的飆高現(xiàn)象,隊(duì)列越多,load 越高,發(fā)生消息響應(yīng)時(shí)間變長,使用短輪詢方式,實(shí)時(shí)性取決于輪詢間隔時(shí)間,消費(fèi)失敗不支持重試;支持消息順序,但是一臺(tái)代理宕機(jī)后,就會(huì)產(chǎn)生消息亂序。
- RocketMQ
RocketMQ 出自阿里巴巴的開源產(chǎn)品,用 Java 語言實(shí)現(xiàn),在設(shè)計(jì)時(shí)參考了 Kafka,并做出了自己的一些改進(jìn)。被阿里巴巴廣泛應(yīng)用在訂單,交易,充值,流計(jì)算,消息推送,日志流式處理,binglog 分發(fā)等場(chǎng)景。
優(yōu)點(diǎn):吞吐量十萬級(jí),可用性非常高,分布式架構(gòu),消息可以做到0丟失,支持10億級(jí)別的消息堆積。
缺點(diǎn):支持的客戶端語言不多。
- RabbitMQ
2007 年發(fā)布,是一個(gè)在 AMQP(高級(jí)消息隊(duì)列協(xié)議)基礎(chǔ)上完成的,可復(fù)用的企業(yè)消息系統(tǒng),是當(dāng)前最主流的消息中間件之一。
優(yōu)點(diǎn):erlang 語言編寫,高并發(fā)特性,吞吐量萬級(jí),支持多種語言。
缺點(diǎn):商業(yè)版需要收費(fèi)。
1.4 MQ 的選擇
- kafka
Kafka 主要特點(diǎn)是基于 Pull 的模式來處理消息消費(fèi),追求高吞吐量,一開始的目的就是用于日志收集和傳輸,適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。大型公司建議可以選用,如果有日志采集功能,肯定是首選 kafka 了。
- RocketMQ
天生為金融互聯(lián)網(wǎng)領(lǐng)域而生,對(duì)于可靠性要求很高的場(chǎng)景,尤其是電商里面的訂單扣款,以及業(yè)務(wù)削峰,在大量交易涌入時(shí),后端可能無法及時(shí)處理的情況。RoketMQ 在穩(wěn)定性上可能更值得信賴,這些業(yè)務(wù)場(chǎng)景在阿里雙 11 已經(jīng)經(jīng)歷了多次考驗(yàn),如果你的業(yè)務(wù)有上述并發(fā)場(chǎng)景,建議可以選擇 RocketMQ。
- RabbitMQ
結(jié)合 erlang 語言本身的并發(fā)優(yōu)勢(shì),性能好時(shí)效性微秒級(jí),社區(qū)活躍度也比較高,管理界面用起來十分方便,如果你的數(shù)據(jù)量沒有那么大,中小型公司優(yōu)先選擇功能比較完備的 RabbitMQ。
2. RabbitMQ
2.1 RabbitMQ 的概念
RabbitMQ 是一個(gè)消息中間件:它接受并轉(zhuǎn)發(fā)消息。你可以把它當(dāng)做一個(gè)快遞站點(diǎn),當(dāng)你要發(fā)送一個(gè)包裹時(shí),你把你的包裹放到快遞站,快遞員最終會(huì)把你的快遞送到收件人那里,按照這種邏輯 RabbitMQ 是一個(gè)快遞站,一個(gè)快遞員幫你傳遞快件。RabbitMQ 與快遞站的主要區(qū)別在于,它不處理快件而是接收,存儲(chǔ)和轉(zhuǎn)發(fā)消息數(shù)據(jù)。
2.2 四大核心概念
生產(chǎn)者: 產(chǎn)生數(shù)據(jù)發(fā)送數(shù)據(jù)的程序就是生產(chǎn)者。
交換機(jī): 接收來自生產(chǎn)者的消息,將消息推送到隊(duì)列中。
隊(duì)列: 本質(zhì)上是一個(gè)大的消息緩沖區(qū),存放生成者產(chǎn)生的消息。
消費(fèi)者: 接收和消費(fèi)隊(duì)列中的消息。
同一個(gè)應(yīng)用程序既可以是生產(chǎn)者又可以是消費(fèi)者
2.3 RabbitMQ 核心部分
2.4 各個(gè)名詞介紹
Broker: 接收和分發(fā)消息的應(yīng)用,RabbitMQ Server 就是 Message Broker。
Virtual host: 出于多租戶和安全因素設(shè)計(jì)的,把 AMQP 的基本組件劃分到一個(gè)虛擬的分組中,類似于網(wǎng)絡(luò)中的 namespace 概念。當(dāng)多個(gè)不同的用戶使用同一個(gè) RabbitMQ server 提供的服務(wù)時(shí),可以劃分出多個(gè) vhost,每個(gè)用戶在自己的 vhost 創(chuàng)建 exchange/queue 等。
Connection: publisher / consumer 和 broker 之間的 TCP 連接。
Channel: 如果每一次訪問 RabbitMQ 都建立一個(gè) Connection,在消息量大的時(shí)候建立 TCP Connection 的開銷將是巨大的,效率也較低。Channel 是在 connection 內(nèi)部建立的邏輯連接,如果應(yīng)用程序支持多線程,通常每個(gè) thread 創(chuàng)建單獨(dú)的 channel 進(jìn)行通訊,AMQP method 包含了 channel id 幫助客戶端和 message broker 識(shí)別 channel,所以 channel 之間是完全隔離的。Channel 作為輕量級(jí)的Connection 極大減少了操作系統(tǒng)建立 TCP connection 的開銷。
Exchange: message 到達(dá) broker 的第一站,根據(jù)分發(fā)規(guī)則,匹配查詢表中 routing key,分發(fā)消息到 queue 中去。常用的類型有:direct (point-to-point), topic (publish-subscribe) and fanout (multicast)。
Queue: 消息最終被送到這里等到 consumer 取走。
Binding: exchange 和 queue 之間的虛擬連接,binding 中可以包含 routing key,Binding 信息被保存到 exchange 中的查詢表中,用于 message 的分發(fā)依據(jù)。
2.5 安裝
- 官網(wǎng)地址
https://www.rabbitmq.com/download.html
- 文件上傳
上傳到 /usr/local/software 目錄下(沒有就自己創(chuàng)建)
- 安裝文件(分別按以下順序安裝)
rpm -ivh erlang-21.3-1.el7.x86_64.rpm
yum install socat -y
rpm -ivh rabbitmq-server-3.8.8-1.el7.noarch.rpm
- 常用命令(按照以下順序執(zhí)行)
添加開機(jī)啟動(dòng) RabbitMQ 服務(wù)
chkconfig rabbitmq-server on
啟動(dòng)服務(wù)
/sbin/service rabbitmq-server start
查看服務(wù)狀態(tài)
/sbin/service rabbitmq-server status
停止服務(wù)
/sbin/service rabbitmq-server stop
開啟 web 管理插件
rabbitmq-plugins enable rabbitmq_management
使用默認(rèn)賬號(hào)密碼(guest)訪問地址 http://192.168.10.100:15672
- 添加一個(gè)新的用戶
創(chuàng)建賬號(hào)
rabbitmqctl add_user admin 123
設(shè)置用戶角色
rabbitmqctl set_user_tags admin administrator
設(shè)置用戶權(quán)限
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"
用戶 user_admin 具有/vhost1 這個(gè) virtual host 中所有資源的配置、寫、讀權(quán)限
當(dāng)前用戶和角色
rabbitmqctl list_users
- 再次利用 admin 用戶登錄
- 重置命令
關(guān)閉應(yīng)用的命令為
rabbitmqctl stop_app
清除的命令為文章來源:http://www.zghlxwxcb.cn/news/detail-560193.html
rabbitmqctl reset
重新啟動(dòng)命令為文章來源地址http://www.zghlxwxcb.cn/news/detail-560193.html
rabbitmqctl start_app
到了這里,關(guān)于RabbitMQ ---- 消息隊(duì)列的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!