本文主要講解 MQ 的通用知識(shí),讓大家先弄明白:如果讓你來(lái)設(shè)計(jì)一個(gè) MQ,該如何下手?需要考慮哪些問(wèn)題?又有哪些技術(shù)挑戰(zhàn)?
有了這個(gè)基礎(chǔ)后,我相信后面幾篇文章再講 Kafka 和 RocketMQ 這兩種具體的消息中間件時(shí),大家能很快地抓住主脈絡(luò),同時(shí)分辨出它們各自的特點(diǎn)。
對(duì)于 MQ 來(lái)說(shuō),不管是 RocketMQ、Kafka 還是其他消息隊(duì)列,它們的本質(zhì)都是:一發(fā)一存一消費(fèi)。下面我們以這個(gè)本質(zhì)作為根,一起由淺入深地聊聊 MQ。
01 從 MQ 的本質(zhì)說(shuō)起 將 MQ 掰開了揉碎了來(lái)看,都是「一發(fā)一存一消費(fèi)」,再直白點(diǎn)就是一個(gè)「轉(zhuǎn)發(fā)器」。
生產(chǎn)者先將消息投遞一個(gè)叫做「隊(duì)列」的容器中,然后再?gòu)倪@個(gè)容器中取出消息,最后再轉(zhuǎn)發(fā)給消費(fèi)者,僅此而已。
上面這個(gè)圖便是消息隊(duì)列最原始的模型,它包含了兩個(gè)關(guān)鍵詞:消息和隊(duì)列。
1、消息:就是要傳輸?shù)臄?shù)據(jù),可以是最簡(jiǎn)單的文本字符串,也可以是自定義的復(fù)雜格式(只要能按預(yù)定格式解析出來(lái)即可)。
2、隊(duì)列:大家應(yīng)該再熟悉不過(guò)了,是一種先進(jìn)先出數(shù)據(jù)結(jié)構(gòu)。它是存放消息的容器,消息從隊(duì)尾入隊(duì),從隊(duì)頭出隊(duì),入隊(duì)即發(fā)消息的過(guò)程,出隊(duì)即收消息的過(guò)程。
02 原始模型的進(jìn)化 再看今天我們最常用的消息隊(duì)列產(chǎn)品(RocketMQ、Kafka 等等),你會(huì)發(fā)現(xiàn):它們都在最原始的消息模型上做了擴(kuò)展,同時(shí)提出了一些新名詞,比如:主題(topic)、分區(qū)(partition)、隊(duì)列(queue)等等。
要徹底理解這些五花八門的新概念,我們化繁為簡(jiǎn),先從消息模型的演進(jìn)說(shuō)起(道理好比:架構(gòu)從來(lái)不是設(shè)計(jì)出來(lái)的,而是演進(jìn)而來(lái)的)
2.1 隊(duì)列模型最初的消息隊(duì)列就是上一節(jié)講的原始模型,它是一個(gè)嚴(yán)格意義上的隊(duì)列(Queue)。消息按照什么順序?qū)戇M(jìn)去,就按照什么順序讀出來(lái)。不過(guò),隊(duì)列沒(méi)有 “讀” 這個(gè)操作,讀就是出隊(duì),從隊(duì)頭中 “刪除” 這個(gè)消息
這便是隊(duì)列模型:它允許多個(gè)生產(chǎn)者往同一個(gè)隊(duì)列發(fā)送消息。但是,如果有多個(gè)消費(fèi)者,實(shí)際上是競(jìng)爭(zhēng)的關(guān)系,也就是一條消息只能被其中一個(gè)消費(fèi)者接收到,讀完即被刪除。
2.2 發(fā)布-訂閱模型如果需要將一份消息數(shù)據(jù)分發(fā)給多個(gè)消費(fèi)者,并且每個(gè)消費(fèi)者都要求收到全量的消息。很顯然,隊(duì)列模型無(wú)法滿足這個(gè)需求。
一個(gè)可行的方案是:為每個(gè)消費(fèi)者創(chuàng)建一個(gè)單獨(dú)的隊(duì)列,讓生產(chǎn)者發(fā)送多份。這種做法比較笨,而且同一份數(shù)據(jù)會(huì)被復(fù)制多份,也很浪費(fèi)空間。
為了解決這個(gè)問(wèn)題,就演化出了另外一種消息模型:發(fā)布-訂閱模型。
在發(fā)布-訂閱模型中,存放消息的容器變成了 “主題”,訂閱者在接收消息之前需要先 “訂閱主題”。最終,每個(gè)訂閱者都可以收到同一個(gè)主題的全量消息。
仔細(xì)對(duì)比下它和 “隊(duì)列模式” 的異同:生產(chǎn)者就是發(fā)布者,隊(duì)列就是主題,消費(fèi)者就是訂閱者,無(wú)本質(zhì)區(qū)別。唯一的不同點(diǎn)在于:一份消息數(shù)據(jù)是否可以被多次消費(fèi)。
2.3 小結(jié)最后做個(gè)小結(jié),上面兩種模型說(shuō)白了就是:?jiǎn)尾ズ蛷V播的區(qū)別。而且,當(dāng)發(fā)布-訂閱模型中只有 1 個(gè)訂閱者時(shí),它和隊(duì)列模型就一樣了,因此在功能上是完全兼容隊(duì)列模型的。
這也解釋了為什么現(xiàn)代主流的 RocketMQ、Kafka 都是直接基于發(fā)布-訂閱模型實(shí)現(xiàn)的?此外,RabbitMQ 中之所以有一個(gè) Exchange 模塊?其實(shí)也是為了解決消息的投遞問(wèn)題,可以變相實(shí)現(xiàn)發(fā)布-訂閱模型。
包括大家接觸到的 “消費(fèi)組”、“集群消費(fèi)”、“廣播消費(fèi)” 這些概念,都和上面這兩種模型相關(guān),以及在應(yīng)用層面大家最常見的情形:組間廣播、組內(nèi)單播,也屬于此范疇。
所以,先掌握一些共性的理論,對(duì)于大家再去學(xué)習(xí)各個(gè)消息中間件的具體實(shí)現(xiàn)原理時(shí),其實(shí)能更好地抓住本質(zhì),分清概念。
03 透過(guò)模型看 MQ 的應(yīng)用場(chǎng)景 目前,MQ 的應(yīng)用場(chǎng)景非常多,大家能倒背如流的是:系統(tǒng)解耦、異步通信和流量削峰。除此之外,還有延遲通知、最終一致性保證、順序消息、流式處理等等。
那到底是先有消息模型,還是先有應(yīng)用場(chǎng)景呢?答案肯定是:先有應(yīng)用場(chǎng)景(也就是先有問(wèn)題),再有消息模型,因?yàn)橄⒛P椭皇墙鉀Q方案的抽象而已。
MQ 經(jīng)過(guò) 30 多年的發(fā)展,能從最原始的隊(duì)列模型發(fā)展到今天百花齊放的各種消息中間件(平臺(tái)級(jí)的解決方案),我覺(jué)得萬(wàn)變不離其宗,還是得益于:消息模型的適配性很廣。
我們?cè)囍匦吕斫庀孪㈥?duì)列的模型。它其實(shí)解決的是:生產(chǎn)者和消費(fèi)者的通信問(wèn)題。那它對(duì)比 RPC 有什么聯(lián)系和區(qū)別呢?
通過(guò)對(duì)比,能很明顯地看出兩點(diǎn)差異:
1、引入 MQ 后,由之前的一次 RPC 變成了現(xiàn)在的兩次 RPC,而且生產(chǎn)者只跟隊(duì)列耦合,它根本無(wú)需知道消費(fèi)者的存在。
2、多了一個(gè)中間節(jié)點(diǎn)「隊(duì)列」進(jìn)行消息轉(zhuǎn)儲(chǔ),相當(dāng)于將同步變成了異步。
再返過(guò)來(lái)思考 MQ 的所有應(yīng)用場(chǎng)景,就不難理解 MQ 為什么適用了?因?yàn)檫@些應(yīng)用場(chǎng)景無(wú)外乎都利用了上面兩個(gè)特性。
舉一個(gè)實(shí)際例子,比如說(shuō)電商業(yè)務(wù)中最常見的「訂單支付」場(chǎng)景:在訂單支付成功后,需要更新訂單狀態(tài)、更新用戶積分、通知商家有新訂單、更新推薦系統(tǒng)中的用戶畫像等等。
引入 MQ 后,訂單支付現(xiàn)在只需要關(guān)注它最重要的流程:更新訂單狀態(tài)即可。其他不重要的事情全部交給 MQ 來(lái)通知。這便是 MQ 解決的最核心的問(wèn)題:系統(tǒng)解耦。
改造前訂單系統(tǒng)依賴 3 個(gè)外部系統(tǒng),改造后僅僅依賴 MQ,而且后續(xù)業(yè)務(wù)再擴(kuò)展(比如:營(yíng)銷系統(tǒng)打算針對(duì)支付用戶獎(jiǎng)勵(lì)優(yōu)惠券),也不涉及訂單系統(tǒng)的修改,從而保證了核心流程的穩(wěn)定性,降低了維護(hù)成本。
這個(gè)改造還帶來(lái)了另外一個(gè)好處:因?yàn)?MQ 的引入,更新用戶積分、通知商家、更新用戶畫像這些步驟全部變成了異步執(zhí)行,能減少訂單支付的整體耗時(shí),提升訂單系統(tǒng)的吞吐量。這便是 MQ 的另一個(gè)典型應(yīng)用場(chǎng)景:異步通信。
除此以外,由于隊(duì)列能轉(zhuǎn)儲(chǔ)消息,對(duì)于超出系統(tǒng)承載能力的場(chǎng)景,可以用 MQ 作為 “漏斗” 進(jìn)行限流保護(hù),即所謂的流量削峰。
我們還可以利用隊(duì)列本身的順序性,來(lái)滿足消息必須按順序投遞的場(chǎng)景;利用隊(duì)列 + 定時(shí)任務(wù)來(lái)實(shí)現(xiàn)消息的延時(shí)消費(fèi) ……
MQ 其他的應(yīng)用場(chǎng)景基本類似,都能回歸到消息模型的特性上,找到它適用的原因,這里就不一一分析了。
總之,就是建議大家多從復(fù)雜多變的實(shí)踐場(chǎng)景再回歸到理論層面進(jìn)行思考和抽象,這樣能吃得更透。
04 如何設(shè)計(jì)一個(gè) MQ? 了解了上面這些理論知識(shí)以及應(yīng)用場(chǎng)景后,下面我們?cè)僖黄鹂聪拢旱降兹绾卧O(shè)計(jì)一個(gè) MQ?
4.1 MQ 的雛形我們還是先從簡(jiǎn)單版的 MQ 入手,如果只是實(shí)現(xiàn)一個(gè)很粗糙的 MQ,完全不考慮生產(chǎn)環(huán)境的要求,該如何設(shè)計(jì)呢?
文章開頭說(shuō)過(guò),任何 MQ 無(wú)外乎:一發(fā)一存一消費(fèi),這是 MQ 最核心的功能需求。另外,從技術(shù)維度來(lái)看 MQ 的通信模型,可以理解成:兩次 RPC + 消息轉(zhuǎn)儲(chǔ)。
有了這些理解,我相信只要有一定的編程基礎(chǔ),不用 1 個(gè)小時(shí)就能寫出一個(gè) MQ 雛形:
1、直接利用成熟的 RPC 框架(Dubbo 或者 Thrift),實(shí)現(xiàn)兩個(gè)接口:發(fā)消息和讀消息。
2、消息放在本地內(nèi)存中即可,數(shù)據(jù)結(jié)構(gòu)可以用 JDK 自帶的 ArrayBlockingQueue 。
4.2 寫一個(gè)適用于生產(chǎn)環(huán)境的 MQ 當(dāng)然,我們的目標(biāo)絕不止于一個(gè) MQ 雛形,而是希望實(shí)現(xiàn)一個(gè)可用于生產(chǎn)環(huán)境的消息中間件,那難度肯定就不是一個(gè)量級(jí)了,具體我們?cè)撊绾蜗率帜兀?/p>
1、先把握這個(gè)問(wèn)題的關(guān)鍵點(diǎn)假如我們還是只考慮最基礎(chǔ)的功能:發(fā)消息、存消息、消費(fèi)消息(支持發(fā)布-訂閱模式)。那在生產(chǎn)環(huán)境中,這些基礎(chǔ)功能將面臨哪些挑戰(zhàn)呢?我們能很快想到下面這些:
1、高并發(fā)場(chǎng)景下,如何保證收發(fā)消息的性能?
2、如何保證消息服務(wù)的高可用和高可靠?
3、如何保證服務(wù)是可以水平任意擴(kuò)展的?
4、如何保證消息存儲(chǔ)也是水平可擴(kuò)展的?
5、各種元數(shù)據(jù)(比如集群中的各個(gè)節(jié)點(diǎn)、主題、消費(fèi)關(guān)系等)如何管理,需不需要考慮數(shù)據(jù)的一致性?
可見,高并發(fā)場(chǎng)景下的三高問(wèn)題在你設(shè)計(jì)一個(gè) MQ 時(shí)都會(huì)遇到,「如何滿足高性能、高可靠等非功能性需求」才是這個(gè)問(wèn)題的關(guān)鍵所在。
2、整體設(shè)計(jì)思路
先來(lái)看下整體架構(gòu),會(huì)涉及三類角色
另外,將「一發(fā)一存一消費(fèi)」這個(gè)核心流程進(jìn)一步細(xì)化后,比較完整的數(shù)據(jù)流如下
基于上面兩個(gè)圖,我們可以很快明確出 3 類角色的作用,分別如下:
1、Broker(服務(wù)端):MQ 中最核心的部分,是 MQ 的服務(wù)端,核心邏輯幾乎全在這里,它為生產(chǎn)者和消費(fèi)者提供 RPC 接口,負(fù)責(zé)消息的存儲(chǔ)、備份和刪除,以及消費(fèi)關(guān)系的維護(hù)等。
2、Producer(生產(chǎn)者):MQ 的客戶端之一,調(diào)用 Broker 提供的 RPC 接口發(fā)送消息。
3、Consumer(消費(fèi)者):MQ 的另外一個(gè)客戶端,調(diào)用 Broker 提供的 RPC 接口接收消息,同時(shí)完成消費(fèi)確認(rèn)。
3、詳細(xì)設(shè)計(jì)下面,再展開討論下一些具體的技術(shù)難點(diǎn)和可行的解決方案。
難點(diǎn)1:RPC 通信
解決的是 Broker 與 Producer 以及 Consumer 之間的通信問(wèn)題。如果不重復(fù)造輪子,直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 實(shí)現(xiàn)即可,這樣不需要考慮服務(wù)注冊(cè)與發(fā)現(xiàn)、負(fù)載均衡、通信協(xié)議、序列化方式等一系列問(wèn)題了。
當(dāng)然,你也可以基于 Netty 來(lái)做底層通信,用 Zookeeper、Euraka 等來(lái)做注冊(cè)中心,然后自定義一套新的通信協(xié)議(類似 Kafka),也可以基于 AMQP 這種標(biāo)準(zhǔn)化的 MQ 協(xié)議來(lái)做實(shí)現(xiàn)(類似 RabbitMQ)。對(duì)比直接用 RPC 框架,這種方案的定制化能力和優(yōu)化空間更大。
難點(diǎn)2:高可用設(shè)計(jì)
高可用主要涉及兩方面:Broker 服務(wù)的高可用、存儲(chǔ)方案的高可用??梢圆痖_討論。
Broker 服務(wù)的高可用,只需要保證 Broker 可水平擴(kuò)展進(jìn)行集群部署即可,進(jìn)一步通過(guò)服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)、負(fù)載均衡、超時(shí)重試機(jī)制、發(fā)送和消費(fèi)消息時(shí)的 ack 機(jī)制來(lái)保證。
存儲(chǔ)方案的高可用有兩個(gè)思路:1)參考 Kafka 的分區(qū) + 多副本模式,但是需要考慮分布式場(chǎng)景下數(shù)據(jù)復(fù)制和一致性方案(類似 Zab、Raft等協(xié)議),并實(shí)現(xiàn)自動(dòng)故障轉(zhuǎn)移;2)還可以用主流的 DB、分布式文件系統(tǒng)、帶持久化能力的 KV 系統(tǒng),它們都有自己的高可用方案。
難點(diǎn)3:存儲(chǔ)設(shè)計(jì)
消息的存儲(chǔ)方案是 MQ 的核心部分,可靠性保證已經(jīng)在高可用設(shè)計(jì)中談過(guò)了,可靠性要求不高的話直接用內(nèi)存或者分布式緩存也可以。這里重點(diǎn)說(shuō)一下存儲(chǔ)的高性能如何保證?這個(gè)問(wèn)題的決定因素在于存儲(chǔ)結(jié)構(gòu)的設(shè)計(jì)。
目前主流的方案是:追加寫日志文件(數(shù)據(jù)部分) + 索引文件的方式(很多主流的開源 MQ 都是這種方式),索引設(shè)計(jì)上可以考慮稠密索引或者稀疏索引,查找消息可以利用跳轉(zhuǎn)表、二分查找等,還可以通過(guò)操作系統(tǒng)的頁(yè)緩存、零拷貝等技術(shù)來(lái)提升磁盤文件的讀寫性能。
如果不追求很高的性能,也可以考慮現(xiàn)成的分布式文件系統(tǒng)、KV 存儲(chǔ)或者數(shù)據(jù)庫(kù)方案。
難點(diǎn)4:消費(fèi)關(guān)系管理
為了支持發(fā)布-訂閱的廣播模式,Broker 需要知道每個(gè)主題都有哪些 Consumer 訂閱了,基于這個(gè)關(guān)系進(jìn)行消息投遞。
由于 Broker 是集群部署的,所以消費(fèi)關(guān)系通常維護(hù)在公共存儲(chǔ)上,可以基于 Zookeeper、Apollo 等配置中心來(lái)管理以及進(jìn)行變更通知。
難點(diǎn)5:高性能設(shè)計(jì)
存儲(chǔ)的高性能前面已經(jīng)談過(guò)了,當(dāng)然還可以從其他方面進(jìn)一步優(yōu)化性能。
比如 Reactor 網(wǎng)絡(luò) IO 模型、業(yè)務(wù)線程池的設(shè)計(jì)、生產(chǎn)端的批量發(fā)送、Broker 端的異步刷盤、消費(fèi)端的批量拉取等等。
4.3 小結(jié)再總結(jié)下,要回答好:如何設(shè)計(jì)一個(gè) MQ?
1、需要從功能性需求(收發(fā)消息)和非功能性需求(高性能、高可用、高擴(kuò)展等)兩方面入手。
2、功能性需求不是重點(diǎn),能覆蓋 MQ 最基礎(chǔ)的功能即可,至于延時(shí)消息、事務(wù)消息、重試隊(duì)列等高級(jí)特性只是錦上添花的東西。
3、最核心的是:能結(jié)合功能性需求,理清楚整體的數(shù)據(jù)流,然后順著這個(gè)思路去考慮非功能性的訴求如何滿足,這才是技術(shù)難點(diǎn)所在。
05 寫在最后 這篇文章從 MQ 一發(fā)一存一消費(fèi)這個(gè)本質(zhì)出發(fā),講解了消息模型的演進(jìn)過(guò)程,這是 MQ 最核心的理論基礎(chǔ)?;诖?,大家也能更容易理解 MQ 的各種新名詞以及應(yīng)用場(chǎng)景。
最后通過(guò)回答:如何設(shè)計(jì)一個(gè) MQ?目的是讓大家對(duì) MQ 的核心組件和技術(shù)難點(diǎn)有一個(gè)清晰的認(rèn)識(shí)。另外,帶著這個(gè)問(wèn)題的答案再去學(xué)習(xí) Kafka、RocketMQ 等具體的消息中間件時(shí),也會(huì)更有側(cè)重點(diǎn)。
責(zé)任編輯:haq
-
數(shù)據(jù)
+關(guān)注
關(guān)注
8文章
6767瀏覽量
88644 -
模型
+關(guān)注
關(guān)注
1文章
3073瀏覽量
48587
原文標(biāo)題:吃透 MQ
文章出處:【微信號(hào):DBDevs,微信公眾號(hào):數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論