消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件严衬，主要解決應(yīng)用解耦澄者，異步消息，流量削鋒等問題瞳步，實(shí)現(xiàn)高性能闷哆，高可用，可伸縮和最終一致性架構(gòu)单起。目前使用較多的消息隊(duì)列有ActiveMQ抱怔，RabbitMQ，ZeroMQ嘀倒，Kafka屈留，MetaMQ，RocketMQ测蘑。消息中間件到底該如何使用灌危，何時(shí)使用這是一個(gè)問題，胡亂地使用消息中間件增加了系統(tǒng)的復(fù)雜度碳胳，如果用不好消息中間件還不如不用勇蝙。

消息隊(duì)列通訊模式

點(diǎn)對(duì)點(diǎn)通訊

點(diǎn)對(duì)點(diǎn)方式是最為傳統(tǒng)和常見的通訊方式，它支持一對(duì)一挨约、一對(duì)多味混、多對(duì)多、多對(duì)一等多種配置方式诫惭，支持樹狀翁锡、網(wǎng)狀等多種拓?fù)浣Y(jié)構(gòu)。

多點(diǎn)廣播

MQ適用于不同類型的應(yīng)用夕土。其中重要的馆衔，也是正在發(fā)展中的是"多點(diǎn)廣播"應(yīng)用，即能夠?qū)⑾l(fā)送到多個(gè)目標(biāo)站點(diǎn)(DestinationList)怨绣〗抢＃可以使用一條MQ指令將單一消息發(fā)送到多個(gè)目標(biāo)站點(diǎn)，并確保為每一站點(diǎn)可靠地提供信息篮撑。MQ不僅提供了多點(diǎn)廣播的功能开镣，而且還擁有智能消息分發(fā)功能，在將一條消息發(fā)送到同一系統(tǒng)上的多個(gè)用戶時(shí)咽扇，MQ將消息的一個(gè)復(fù)制版本和該系統(tǒng)上接收者的名單發(fā)送到目標(biāo)MQ系統(tǒng)邪财。目標(biāo)MQ系統(tǒng)在本地復(fù)制這些消息，并將它們發(fā)送到名單上的隊(duì)列质欲，從而盡可能減少網(wǎng)絡(luò)的傳輸量树埠。

發(fā)布/訂閱(Publish/Subscribe)模式

發(fā)布/訂閱功能使消息的分發(fā)可以突破目的隊(duì)列地理指向的限制，使消息按照特定的主題甚至內(nèi)容進(jìn)行分發(fā)嘶伟，用戶或應(yīng)用程序可以根據(jù)主題或內(nèi)容接收到所需要的消息怎憋。發(fā)布/訂閱功能使得發(fā)送者和接收者之間的耦合關(guān)系變得更為松散，發(fā)送者不必關(guān)心接收者的目的地址九昧，而接收者也不必關(guān)心消息的發(fā)送地址绊袋，而只是根據(jù)消息的主題進(jìn)行消息的收發(fā)。在MQ家族產(chǎn)品中铸鹰，MQEventBroker是專門用于使用發(fā)布/訂閱技術(shù)進(jìn)行數(shù)據(jù)通訊的產(chǎn)品癌别，它支持基于隊(duì)列和直接基于TCP/IP兩種方式的發(fā)布和訂閱。

群集(Cluster)

為了簡(jiǎn)化點(diǎn)對(duì)點(diǎn)通訊模式中的系統(tǒng)配置蹋笼，MQ提供Cluster(群集)的解決方案展姐。群集類似于一個(gè)域(Domain)，群集內(nèi)部的隊(duì)列管理器之間通訊時(shí)剖毯，不需要兩兩之間建立消息通道圾笨，而是采用群集(Cluster)通道與其它成員通訊，從而大大簡(jiǎn)化了系統(tǒng)配置逊谋。此外擂达，群集中的隊(duì)列管理器之間能夠自動(dòng)進(jìn)行負(fù)載均衡，當(dāng)某一隊(duì)列管理器出現(xiàn)故障時(shí)胶滋，其它隊(duì)列管理器可以接管它的工作板鬓，從而大大提高系統(tǒng)的高可靠性。

使用消息隊(duì)列的理由

過去幾年中镀钓，我們一直在使用穗熬、構(gòu)建和宣傳消息隊(duì)列，我們認(rèn)為它們是很令人敬畏的丁溅，這也不是什么秘密唤蔗。我們相信對(duì)任何架構(gòu)或應(yīng)用來說，消息隊(duì)列都是一個(gè)至關(guān)重要的組件窟赏，下面是十個(gè)理由:

1. 1解耦

在項(xiàng)目啟動(dòng)之初來預(yù)測(cè)將來項(xiàng)目會(huì)碰到什么需求妓柜，是極其困難的。消息隊(duì)列在處理過程中間插入了一個(gè)隱含的涯穷、基于數(shù)據(jù)的接口層棍掐，兩邊的處理過程都要實(shí)現(xiàn)這一接口。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程拷况，只要確保它們遵守同樣的接口約束作煌。

1.2 冗余

有時(shí)在處理數(shù)據(jù)的時(shí)候處理過程會(huì)失敗掘殴。除非數(shù)據(jù)被持久化，否則將永遠(yuǎn)丟失粟誓。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理奏寨，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。在被許多消息隊(duì)列所采用的"插入-獲取-刪除"范式中鹰服，在把一個(gè)消息從隊(duì)列中刪除之前病瞳，需要你的處理過程明確的指出該消息已經(jīng)被處理完畢，確保你的數(shù)據(jù)被安全的保存直到你使用完畢悲酷。

1.3 擴(kuò)展性

因?yàn)橄㈥?duì)列解耦了你的處理過程套菜，所以增大消息入隊(duì)和處理的頻率是很容易的；只要另外增加處理過程即可设易。不需要改變代碼逗柴、不需要調(diào)節(jié)參數(shù)。擴(kuò)展就像調(diào)大電力按鈕一樣簡(jiǎn)單亡嫌。

1.4 靈活性 & 峰值處理能力

當(dāng)你的應(yīng)用上了Hacker News的首頁嚎于，你將發(fā)現(xiàn)訪問流量攀升到一個(gè)不同尋常的水平。在訪問量劇增的情況下挟冠，你的應(yīng)用仍然需要繼續(xù)發(fā)揮作用于购，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時(shí)待命無疑是巨大的浪費(fèi)知染。使用消息隊(duì)列能夠使關(guān)鍵組件頂住增長(zhǎng)的訪問壓力肋僧，而不是因?yàn)槌鲐?fù)荷的請(qǐng)求而完全崩潰。請(qǐng)查看我們關(guān)于峰值處理能力的博客文章了解更多此方面的信息控淡。

1.5可恢復(fù)性

當(dāng)體系的一部分組件失效嫌吠，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度掺炭，所以即使一個(gè)處理消息的進(jìn)程掛掉辫诅，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。而這種允許重試或者延后處理請(qǐng)求的能力通常是造就一個(gè)略感不便的用戶和一個(gè)沮喪透頂?shù)挠脩糁g的區(qū)別涧狮。

1.6送達(dá)保證

消息隊(duì)列提供的冗余機(jī)制保證了消息能被實(shí)際的處理炕矮，只要一個(gè)進(jìn)程讀取了該隊(duì)列即可。在此基礎(chǔ)上者冤，IronMQ提供了一個(gè)"只送達(dá)一次"保證肤视。無論有多少進(jìn)程在從隊(duì)列中領(lǐng)取數(shù)據(jù)，每一個(gè)消息只能被處理一次涉枫。這之所以成為可能邢滑，是因?yàn)楂@取一個(gè)消息只是"預(yù)定"了這個(gè)消息，暫時(shí)把它移出了隊(duì)列愿汰。除非客戶端明確的表示已經(jīng)處理完了這個(gè)消息困后，否則這個(gè)消息會(huì)被放回隊(duì)列中去乐纸，在一段可配置的時(shí)間之后可再次被處理。

1.7排序保證

在許多情況下操灿，數(shù)據(jù)處理的順序都很重要锯仪。消息隊(duì)列本來就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來處理趾盐。IronMO保證消息漿糊通過FIFO（先進(jìn)先出）的順序來處理，因此消息在隊(duì)列中的位置就是從隊(duì)列中檢索他們的位置小腊。

1.8緩沖

在任何重要的系統(tǒng)中救鲤，都會(huì)有需要不同的處理時(shí)間的元素。例如,加載一張圖片比應(yīng)用過濾器花費(fèi)更少的時(shí)間秩冈。消息隊(duì)列通過一個(gè)緩沖層來幫助任務(wù)最高效率的執(zhí)行–寫入隊(duì)列的處理會(huì)盡可能的快速本缠，而不受從隊(duì)列讀的預(yù)備處理的約束。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度入问。

1.9 理解數(shù)據(jù)流

在一個(gè)分布式系統(tǒng)里丹锹，要得到一個(gè)關(guān)于用戶操作會(huì)用多長(zhǎng)時(shí)間及其原因的總體印象，是個(gè)巨大的挑戰(zhàn)芬失。消息系列通過消息被處理的頻率楣黍，來方便的輔助確定那些表現(xiàn)不佳的處理過程或領(lǐng)域，這些地方的數(shù)據(jù)流都不夠優(yōu)化棱烂。

1.10 異步通信

很多時(shí)候租漂，你不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制颊糜，允許你把一個(gè)消息放入隊(duì)列哩治，但并不立即處理它。你想向隊(duì)列中放入多少消息就放多少衬鱼，然后在你樂意的時(shí)候再去處理它們业筏。

消息隊(duì)列應(yīng)用場(chǎng)景

以下介紹消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場(chǎng)景。異步處理鸟赫，應(yīng)用解耦蒜胖，流量削鋒和消息通訊四個(gè)場(chǎng)景。

異步處理

以下介紹消息隊(duì)列在實(shí)際應(yīng)用中常用的使用場(chǎng)景惯疙。異步處理翠勉，應(yīng)用解耦，流量削鋒和消息通訊四個(gè)場(chǎng)景霉颠。

場(chǎng)景說明： 用戶注冊(cè)后对碌，需要發(fā)注冊(cè)郵件和注冊(cè)短信。傳統(tǒng)的做法有兩種 1.串行的方式蒿偎；2.并行方式.

串行方式： 將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后朽们，發(fā)送注冊(cè)郵件怀读，再發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)全部完成后骑脱，返回給客戶端菜枷。

image.png

并行方式：將注冊(cè)信息寫入數(shù)據(jù)庫(kù)成功后，發(fā)送注冊(cè)郵件的同時(shí)叁丧，發(fā)送注冊(cè)短信啤誊。以上三個(gè)任務(wù)完成后，返回給客戶端拥娄。與串行的差別是蚊锹，并行的方式可以提高處理的時(shí)間

image.png

假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒鐘，不考慮網(wǎng)絡(luò)等其他開銷稚瘾，則串行方式的時(shí)間是150毫秒牡昆，并行的時(shí)間可能是100毫秒。
因?yàn)镃PU在單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)是一定的摊欠，假設(shè)CPU1秒內(nèi)吞吐量是100次丢烘。則串行方式1秒內(nèi)CPU可處理的請(qǐng)求量是7次（1000/150）。并行方式處理的請(qǐng)求量是10次（1000/100）
小結(jié)：如以上案例描述些椒，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量播瞳，吞吐量，響應(yīng)時(shí)間）會(huì)有瓶頸摊沉。如何解決這個(gè)問題呢狐史？

引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯说墨，異步處理骏全。改造后的架構(gòu)如下：

image.png

應(yīng)用解耦

場(chǎng)景說明： 用戶下單后，訂單系統(tǒng)需要通知庫(kù)存系統(tǒng)尼斧。傳統(tǒng)的做法是姜贡，訂單系統(tǒng)調(diào)用庫(kù)存系統(tǒng)的接口。如下圖：

image.png

傳統(tǒng)模式的缺點(diǎn)： 假如庫(kù)存系統(tǒng)無法訪問棺棵，則訂單減庫(kù)存將失敗楼咳，從而導(dǎo)致訂單失敗，訂單系統(tǒng)與庫(kù)存系統(tǒng)耦合

如何解決以上問題呢烛恤？引入應(yīng)用消息隊(duì)列后的方案母怜，如下圖：

image.png

訂單系統(tǒng)： 用戶下單后，訂單系統(tǒng)完成持久化處理缚柏，將消息寫入消息隊(duì)列苹熏，返回用戶訂單下單成功庫(kù)存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息轨域，庫(kù)存系統(tǒng)根據(jù)下單信息袱耽，進(jìn)行庫(kù)存操作假如：在下單時(shí)庫(kù)存系統(tǒng)不能正常使用。也不影響正常下單干发，因?yàn)橄聠魏笾炀蓿唵蜗到y(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫(kù)存系統(tǒng)的應(yīng)用解耦

流量削鋒

流量削鋒也是消息隊(duì)列中的常用場(chǎng)景枉长，一般在秒殺或團(tuán)搶活動(dòng)中使用廣泛冀续。應(yīng)用場(chǎng)景：秒殺活動(dòng)，一般會(huì)因?yàn)榱髁窟^大必峰，導(dǎo)致流量暴增沥阳，應(yīng)用掛掉。為解決這個(gè)問題自点，一般需要在應(yīng)用前端加入消息隊(duì)列。

a脉让、可以控制活動(dòng)的人數(shù)
b桂敛、可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用

image.png

用戶的請(qǐng)求，服務(wù)器接收后溅潜，首先寫入消息隊(duì)列术唬。假如消息隊(duì)列長(zhǎng)度超過最大數(shù)量，則直接拋棄用戶請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁面滚澜。
秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請(qǐng)求信息粗仓，再做后續(xù)處理

日志處理

日志處理是指將消息隊(duì)列用在日志處理中，比如Kafka的應(yīng)用设捐，解決大量日志傳輸?shù)膯栴}借浊。架構(gòu)簡(jiǎn)化如下

image.png

日志采集客戶端，負(fù)責(zé)日志數(shù)據(jù)采集萝招，定時(shí)寫受寫入Kafka隊(duì)列
Kafka消息隊(duì)列蚂斤，負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)
日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)

消息通訊

消息通訊是指槐沼，消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制曙蒸，因此也可以用在純的消息通訊。比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列岗钩，或者聊天室等

點(diǎn)對(duì)點(diǎn)通訊：

image.png

客戶端A和客戶端B使用同一隊(duì)列纽窟，進(jìn)行消息通訊。

聊天室通訊：

image.png

客戶端A兼吓，客戶端B臂港，客戶端N訂閱同一主題，進(jìn)行消息發(fā)布和接收。實(shí)現(xiàn)類似聊天室效果趋艘。

以上實(shí)際是消息隊(duì)列的兩種消息模式疲恢，點(diǎn)對(duì)點(diǎn)或發(fā)布訂閱模式。模型為示意圖瓷胧，供參考显拳。

消息中間件使用案例

電商系統(tǒng)

image.png

消息隊(duì)列采用高可用，可持久化的消息中間件搓萧。比如Active MQ杂数，Rabbit MQ，Rocket Mq瘸洛。
1揍移、應(yīng)用將主干邏輯處理完成后，寫入消息隊(duì)列反肋。消息發(fā)送是否成功可以開啟消息的確認(rèn)模式那伐。（消息隊(duì)列返回消息接收成功狀態(tài)后，應(yīng)用再返回石蔗，這樣保障消息的完整性）
2罕邀、擴(kuò)展流程（發(fā)短信，配送處理）訂閱隊(duì)列消息养距。采用推或拉的方式獲取消息并處理诉探。
3、消息將應(yīng)用解耦的同時(shí)棍厌，帶來了數(shù)據(jù)一致性問題肾胯，可以采用最終一致性方式解決。比如主數(shù)據(jù)寫入數(shù)據(jù)庫(kù)耘纱，擴(kuò)展應(yīng)用根據(jù)消息隊(duì)列敬肚，并結(jié)合數(shù)據(jù)庫(kù)方式實(shí)現(xiàn)基于消息隊(duì)列的后續(xù)處理。

歡迎大家加入粉絲群：963944895揣炕，群內(nèi)免費(fèi)分享Spring框架帘皿、Mybatis框架SpringBoot框架、SpringMVC框架畸陡、SpringCloud微服務(wù)鹰溜、Dubbo框架、Redis緩存丁恭、RabbitMq消息曹动、JVM調(diào)優(yōu)、Tomcat容器牲览、MySQL數(shù)據(jù)庫(kù)教學(xué)視頻及架構(gòu)學(xué)習(xí)思維導(dǎo)圖

日志收集系統(tǒng)

分為Zookeeper注冊(cè)中心墓陈，日志收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。

Zookeeper注冊(cè)中心： 提出負(fù)載均衡和地址查找服務(wù)日志收集客戶端*：用于采集應(yīng)用系統(tǒng)的日志贡必，并將數(shù)據(jù)推送到kafka隊(duì)列Kafka集群：接收兔港，路由，存儲(chǔ)仔拟，轉(zhuǎn)發(fā)等消息處理Storm集群：與OtherApp處于同一級(jí)別衫樊，采用拉的方式消費(fèi)隊(duì)列中的數(shù)據(jù)

以下是新浪kafka日志處理應(yīng)用案例：

image.png

1、Kafka ：接收用戶日志的消息隊(duì)列
2利花、Logstash：做日志解析科侈，統(tǒng)一成JSON輸出給Elasticsearch
3、Elasticsearch ：實(shí)時(shí)日志分析服務(wù)的核心技術(shù)炒事，一個(gè)schemaless臀栈，實(shí)時(shí)的數(shù)據(jù)存儲(chǔ)服務(wù)，通過index組織數(shù)據(jù)挠乳，兼具強(qiáng)大的搜索和統(tǒng)計(jì)功能
4权薯、Kibana ：基于Elasticsearch的數(shù)據(jù)可視化組件，超強(qiáng)的數(shù)據(jù)可視化能力是眾多公司選擇ELK stack的重要原因

寫在最后：

既然看到這里了睡扬，覺得筆者寫的還不錯(cuò)的就點(diǎn)個(gè)贊崭闲，加個(gè)關(guān)注唄！點(diǎn)關(guān)注威蕉，不迷路，持續(xù)更新ｉ先浴Ｈ驼恰！