這篇文章主要介紹“如何從業(yè)務(wù)場(chǎng)景看消息中間件”，在日常操作中，相信很多人在如何從業(yè)務(wù)場(chǎng)景看消息中間件問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”如何從業(yè)務(wù)場(chǎng)景看消息中間件”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

成都創(chuàng)新互聯(lián)堅(jiān)信：善待客戶，將會(huì)成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。十余年網(wǎng)站建設(shè)經(jīng)驗(yàn)成都創(chuàng)新互聯(lián)是成都老牌網(wǎng)站營(yíng)銷服務(wù)商,為您提供成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、H5建站、網(wǎng)站制作、成都品牌網(wǎng)站建設(shè)、微信小程序服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。

MQ的三大作用

MQ的三大作用：業(yè)務(wù)解耦、異步調(diào)用、流量削峰。

在介紹消息中間件之前，我們先想一下，如果不用MQ，業(yè)務(wù)之間最常用的調(diào)用方式是什么？比較常見的是RPC和REST方式。兩種簡(jiǎn)單的對(duì)比如下：

因?yàn)镽EST靈活度高、性能低；而RPC性能高而靈活度低，因此我們可以對(duì)外接口用REST，內(nèi)部通訊用RPC。

內(nèi)部采用RPC的架構(gòu)如下所示：

如果是核心應(yīng)用，上面架構(gòu)沒有問題。但如果業(yè)務(wù)邏輯被加入了有時(shí)效性的運(yùn)營(yíng)活動(dòng)邏輯，頻繁修改代碼邏輯顯然不靠譜。

借助于MQ，我們將運(yùn)行活動(dòng)業(yè)務(wù)邏輯單拎出來，放到MQ后面?？蛻舳说陌l(fā)起的請(qǐng)求，都發(fā)到MQ一份，后面的業(yè)務(wù)邏輯根據(jù)自己的需求進(jìn)行消費(fèi)。這樣，通過MQ，我們實(shí)現(xiàn)了業(yè)務(wù)解耦（運(yùn)營(yíng)活動(dòng)與核心業(yè)務(wù)）

上面我們提到很多時(shí)候內(nèi)部業(yè)務(wù)調(diào)用是RPC。在一些場(chǎng)景下，我們可以通過MQ替換RPC，實(shí)現(xiàn)業(yè)務(wù)異步調(diào)用。

那么，MQ能否完全替代RPC？理論上可以替代RPC。但是在這種情況下，整個(gè)系統(tǒng)的穩(wěn)定性都靠MQ，存在一定的風(fēng)險(xiǎn)。而PRC是個(gè)獨(dú)立的框架，業(yè)務(wù)節(jié)點(diǎn)有問題，對(duì)全局沒有影響。所以不建議把RPC都換成MQ。

接下來，我們看一個(gè)具體的場(chǎng)景（電商場(chǎng)景），如何通過MQ實(shí)現(xiàn)業(yè)務(wù)異步調(diào)用。

在下圖中，不使用MQ之前，交易服務(wù)向賣家推送服務(wù)、記錄交易數(shù)據(jù)等都是通過RPC實(shí)現(xiàn)。實(shí)際上，這與核心業(yè)務(wù)邏輯無關(guān)。因此可以改造成第二張圖的模式。

在介紹了MQ實(shí)現(xiàn)業(yè)務(wù)邏輯拆分和異步調(diào)用后，接下來我們查看MQ實(shí)現(xiàn)流量削峰的場(chǎng)景。

京東經(jīng)常舉辦秒殺的活動(dòng)。在秒殺開始那一刻，很多用戶發(fā)起請(qǐng)求，訪問量突增。此時(shí)為了保證業(yè)務(wù)邏輯層的平穩(wěn)運(yùn)行，需要在API網(wǎng)關(guān)和業(yè)務(wù)員邏輯之間增加一個(gè)MQ。客戶端請(qǐng)求都被堆積在MQ，然后業(yè)務(wù)邏輯處理。此時(shí)，我們可以給用戶開放一個(gè)秒殺結(jié)果的查詢接口，通過RPC調(diào)用業(yè)務(wù)邏輯層。

MQ雖然能夠?qū)崿F(xiàn)流量削峰、業(yè)務(wù)解耦、異步調(diào)用，但引入MQ也有一切缺點(diǎn)，例如增加了故障診斷的復(fù)雜度、增加了架構(gòu)的復(fù)雜度。因此MQ不能完全替代RPC，兩者要結(jié)合使用。在微服務(wù)的場(chǎng)景中，MQ通常放在API網(wǎng)關(guān)和業(yè)務(wù)邏輯層之間，如上圖所示。

幾種MQ的對(duì)比

接下來，我們對(duì)比一下幾種主流MQ的優(yōu)劣勢(shì)：

從上圖中，我們可以看到，RocketMQ在功能上是有一定的優(yōu)勢(shì)的。Rocket目前是一個(gè)很受歡迎的MQ開源項(xiàng)目：

如果要對(duì)比Kafka和RocketMQ的應(yīng)用場(chǎng)景，簡(jiǎn)單而言：Kafka做的不是業(yè)務(wù)的事情，它不保證業(yè)務(wù)的一致性，它是系統(tǒng)間的數(shù)據(jù)流通道；RocketMQ做的是業(yè)務(wù)相關(guān)的事情，它保證業(yè)務(wù)的一致性，它實(shí)現(xiàn)高性能可靠信息傳輸。

正常的消息會(huì)負(fù)載均衡發(fā)送。一個(gè)Topic會(huì)跨多個(gè)隊(duì)列。如果想要順序消息，就必須發(fā)到一個(gè)隊(duì)列，并且只有一個(gè)線程消費(fèi)消息。

RocketMQ被廣泛使用的幾個(gè)核心原因是：支持事務(wù)消息、支持延遲消息、支持消息重發(fā)、支持customer端tag過濾、支持消息回放。

RocketMQ的拓?fù)渑c邏輯圖

RocketMQ的拓?fù)鋱D如下。

RocketMQ的Name Server集群中每個(gè)節(jié)點(diǎn)都是相互獨(dú)立的，負(fù)責(zé)MQ集群的服務(wù)注冊(cè)發(fā)現(xiàn)。

邏輯圖如下：

由于RocketMQ不能實(shí)現(xiàn)主從切換，因此消息生產(chǎn)者只連接到主上，消費(fèi)者連接到主和從上。

結(jié)合RockerMQ的可靠性和可用性，我們通常的使用方式如下圖所示，即多Master多Salve+異步復(fù)制。

在RockerMQ中，消息生產(chǎn)者在寫消息是以順序追加的方式，寫在commitlog中的。commitlog是消息主體。然后dispatch線程把消息的偏移量和大小從commitlog中讀出來，放到按主題、以隊(duì)列的形式消費(fèi)隊(duì)列。也就是說，隊(duì)列放的不是消息主體。而是消息的索引信息。

CommitLog以物理文件的方式存放，每臺(tái)Broker上的CommitLog被本機(jī)器所有ConsumeQueue共享。為了提升消息讀取的性能，RocketMQ默認(rèn)會(huì)把commitlog以1G大小進(jìn)行拆分。此外，對(duì)于MQ系統(tǒng)，盡量使用SDD或NVRAM。

RocketMQ的消息傳遞方式

我們知道，服務(wù)之間消息傳遞主要有兩種模式：隊(duì)列（Queue）和主題（Topic）。

• Queue 模式是一種一對(duì)一的傳輸模式。在這種模式下，消息的生產(chǎn)者（Producer）將消息傳遞的目的地類型是 Queue。Queue 中一條消息只能傳遞給一個(gè)消費(fèi)者（Consumer），如果沒有消費(fèi)者在監(jiān)聽隊(duì)列，消息將會(huì)一直保留在隊(duì)列中，直至消息消費(fèi)者連接到隊(duì)列為止，消費(fèi)者會(huì)從隊(duì)列中請(qǐng)求獲得消息--->消費(fèi)者pull方式。

• Topic 模式是一種一對(duì)多的消息傳輸模式。在這種模式下，消息的生產(chǎn)者（Producer）將消息傳遞的目的地類型是 Topic。消息到達(dá) Topic 后，消息服務(wù)器將消息發(fā)送至所有訂閱此主題的消費(fèi)者。--->push給消費(fèi)者模式。

在RocketMQ中，Topic是個(gè)抽象的概念，每個(gè)Topic底層對(duì)應(yīng)N個(gè)queue，而數(shù)據(jù)也真實(shí)存在queue上的。Queue是Topic在一個(gè)Broker上的分片等分為指定份數(shù)后的其中一份，是負(fù)載均衡過程中資源分配的基本單元。也就是說，一個(gè)topic跨多個(gè)queue，每個(gè)queue在一個(gè)broker上，因此topic可以跨多個(gè)broker。

實(shí)際上，push和pull方式都各優(yōu)缺點(diǎn)。

push方式：消息實(shí)時(shí)性高，但沒有考慮客戶端的消費(fèi)能力、即消息處理速度。

pull方式：消息實(shí)時(shí)性低，可能造大量無效請(qǐng)求。

為了取長(zhǎng)補(bǔ)短，RocketMQ采用LongPoll方式，即長(zhǎng)輪詢方式。在這種方式下，消費(fèi)者主動(dòng)發(fā)送pull消息，然后broker hold住請(qǐng)求，直到有消息才返回。請(qǐng)求的超時(shí)時(shí)間是30s。當(dāng)請(qǐng)求超時(shí)后，消費(fèi)端再度發(fā)起請(qǐng)求。

RocketMQ的消費(fèi)者消費(fèi)方式

關(guān)于消費(fèi)者消費(fèi)消息的方式，主要有兩種：

集群消費(fèi)：?jiǎn)螚l消息只消費(fèi)一次，各階段均勻消費(fèi)Topic的消息。

廣播消費(fèi)：各集群消費(fèi)全量的消息，單條消息在每個(gè)集群都被消費(fèi)一次。

到此，關(guān)于“如何從業(yè)務(wù)場(chǎng)景看消息中間件”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！