[[408564]]

本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚(yú)了」，作者陳煎魚(yú)。轉(zhuǎn)載本文請(qǐng)聯(lián)系腦子進(jìn)煎魚(yú)了公眾號(hào)。

大家好，我是煎魚(yú)。

前段時(shí)間我們分享了《漫談 MQ》的第一期《要消息隊(duì)列(MQ)有什么用?》，感覺(jué)打開(kāi)了一個(gè)新的世界。

但很快就有小伙伴意識(shí)到了不妙，既然 MQ 承接了多個(gè)系統(tǒng)，那豈不是該有的問(wèn)題，他都有，又或是更甚。如下：

今天我們就進(jìn)一步講講，設(shè)計(jì) MQ 時(shí)很有可能會(huì)遇到的幾個(gè)大難點(diǎn)，在業(yè)內(nèi)又配套用了什么解決方案去處理。

幾個(gè)難點(diǎn)

從結(jié)論上來(lái)看，設(shè)計(jì) MQ 這一個(gè)存在。會(huì)至少引發(fā)三大難點(diǎn)?？胺Q(chēng)互聯(lián)網(wǎng)經(jīng)典的，也是面試官們最?lèi)?ài)問(wèn)的：

• 高可用：代表系統(tǒng)的可用性程度，高可用性通常通過(guò)提高系統(tǒng)的容錯(cuò)能力來(lái)實(shí)現(xiàn)，從而減少系統(tǒng)宕機(jī)時(shí)間。
• 高并發(fā)：代表通過(guò)設(shè)計(jì)保證系統(tǒng)能夠同時(shí)并行處理很多請(qǐng)求，在同一個(gè)時(shí)間點(diǎn)，有很多用戶(hù)同時(shí)訪問(wèn)同一系統(tǒng)、API、URL。
• 高可靠：代表能夠滿(mǎn)足預(yù)計(jì)條件的一個(gè)系統(tǒng)或組件(例如：備份、故障處理、數(shù)據(jù)存儲(chǔ)以及訪問(wèn))，比較經(jīng)典的是 4 個(gè)9 等標(biāo)準(zhǔn)。

高可用

像前面評(píng)論區(qū)留言的兄弟截圖表述的一樣。

雖然請(qǐng)求不直接找系統(tǒng) A、B、C、D 了。但是請(qǐng)求都實(shí)打?qū)嵉耐ㄟ^(guò)異步的方式打到了 MQ 上，就可以不斷往 MQ 塞，變成了多個(gè)系統(tǒng)都在請(qǐng)求 MQ，可以認(rèn)為壓力比單系統(tǒng)同步調(diào)用大了不止一倍。

同時(shí) MQ 還要去做消費(fèi)關(guān)系的維護(hù)，存儲(chǔ)既有和新增的大量消息。是一個(gè)既要也要還要的典型場(chǎng)景。

這樣一來(lái)，新的一輪問(wèn)題就出現(xiàn)了。就是要保證 MQ 的高可用，否則他輕輕松松就會(huì)被壓到宕機(jī)，或是負(fù)載過(guò)高，出現(xiàn)一些匪夷所思的延遲。

如何保證 MQ 的高可用，是一個(gè)大問(wèn)題。

高并發(fā)

在高并發(fā)上的訴求上，其實(shí)是和高可用的場(chǎng)景是一樣的。既然各業(yè)務(wù)系統(tǒng)都是異步的了，自然他也就不會(huì)像同步阻塞一樣 “等” 你。

像是我有一個(gè)朋友，他們喜歡批量清洗多租戶(hù)的數(shù)據(jù)。業(yè)務(wù)程序也不怎么節(jié)制，幾十、幾百、上千萬(wàn)數(shù)據(jù)，利用 Go 語(yǔ)言寫(xiě)的，抄起 for-loop+go func 就是一把梭。刷刷刷一下子就就給打進(jìn) MQ 里。

再多來(lái)幾個(gè)業(yè)務(wù)系統(tǒng)這么干，這 MQ 并發(fā)就比較高了，單單維護(hù)就是頭疼。很有可能事故背著背著，年底就 3.25 了。因?yàn)? MQ，在業(yè)務(wù)中的依賴(lài)非常重，是標(biāo)準(zhǔn)的核心基礎(chǔ)設(shè)施。

如何保證 MQ 能夠承受高并發(fā)，是一個(gè)大問(wèn)題。

高可靠

對(duì) MQ 來(lái)講，高可靠性的訴求，又分為好幾個(gè)角度去理解。如下：

• 消息要靠譜：“我” 發(fā)的消息要能夠可靠的到達(dá) MQ，MQ 要能夠正確的讓消費(fèi)者能夠接收到推送或拉取。
• 存儲(chǔ)要靠譜：“我” 發(fā)的消息，還在 MQ 上時(shí)要存儲(chǔ)好，不能發(fā)到 MQ 上就因?yàn)榇罅繑?shù)據(jù)，丟了。又或是查詢(xún)很慢。
• 處理要靠譜：發(fā)了消息，可能會(huì)出現(xiàn)異常。發(fā)了消息，可能網(wǎng)絡(luò)抖動(dòng)，沒(méi)有接收到。

上述我們列了三點(diǎn) “要靠譜” 的內(nèi)容。實(shí)質(zhì)上，對(duì)于 MQ 來(lái)講，其每一塊領(lǐng)域都要保證其可靠性，否則查起問(wèn)題來(lái)，真的是會(huì)非常崩潰。

甚至更往上，還會(huì)對(duì) “高性能” 會(huì)有要求，不過(guò)這一塊我們就不進(jìn)一步展開(kāi)了。

解決方案

核心流程

在清楚了設(shè)計(jì) MQ 會(huì)遇到的三大難點(diǎn)后。我們需要先了解一下現(xiàn)代 MQ 的基礎(chǔ)應(yīng)用架構(gòu)會(huì)是怎么樣的。

MQ 包含如下三類(lèi)角色：

• 生產(chǎn)者(Producer)：負(fù)責(zé)生產(chǎn)消息。
• 消費(fèi)者(Consumer)：負(fù)責(zé)消費(fèi)消息。
• 服務(wù)端(Broker)：負(fù)責(zé)存儲(chǔ)和處理消息，是 MQ 的核心部分。由隊(duì)列(Queue)延伸而來(lái)，因?yàn)楣δ芤呀?jīng)不僅僅局限于隊(duì)列屬性了。

其核心流程如下：

核心流程

• 生產(chǎn)者(Producer)發(fā)送消息到達(dá)服務(wù)端(Broker)，服務(wù)端進(jìn)行消息存儲(chǔ)，核心邏輯處理等。
• 再根據(jù)先前注冊(cè)消費(fèi)的關(guān)系(例如：訂閱)，進(jìn)行消息的推送或被拉取。也就是消費(fèi)消息了。
• 在完成消費(fèi)消息后再返回確認(rèn)(ACK)給服務(wù)端。若出現(xiàn)一定時(shí)間內(nèi)未收到 ACK，則會(huì)觸發(fā)服務(wù)端的重試機(jī)制。
• 服務(wù)端確定消息處理完畢，刪除消息和進(jìn)行記錄。

對(duì)三高下手

設(shè)計(jì)高可用

在高可用上，主要要針對(duì)服務(wù)端(Broker)來(lái)做。目前常見(jiàn)的是保證服務(wù)端可以進(jìn)行水平擴(kuò)展，能夠做跨集群的部署。

因此相應(yīng)上得配套做服務(wù)的注冊(cè)和發(fā)現(xiàn)機(jī)制，負(fù)載均衡(確保服務(wù)端壓力均衡)。以此來(lái)構(gòu)成 MQ 高可用的基本維持。

設(shè)計(jì)高并發(fā)

在高并發(fā)上，服務(wù)端必然包含隊(duì)列(Queue)，會(huì)起到緩沖的作用。但仍然可能會(huì)出現(xiàn)單點(diǎn)流量過(guò)大。

因此通常會(huì)結(jié)合像是 RocketMQ 的 Topic，Kafka 的 Partition 等做隊(duì)列劃分，起到分而治之的作用。

設(shè)計(jì)高可靠

在高可靠上，主要是針對(duì)消息發(fā)送、存儲(chǔ)消息、處理消息這三塊進(jìn)行展開(kāi)。

消息發(fā)送上，會(huì)結(jié)合 SDK 和服務(wù)端兩者，發(fā)送和消費(fèi)消息的確認(rèn)(ACK)機(jī)制、重試機(jī)制等來(lái)實(shí)現(xiàn)消息的可靠性。

存儲(chǔ)消息上，常見(jiàn)分為：分布式緩存、分布式文件系統(tǒng)、數(shù)據(jù)庫(kù)方案等。目前主流的話，會(huì)采取落盤(pán)的方式，也就是將消息主體追加寫(xiě)入到日志文件，再配合索引文件來(lái)做快速的消息查找。

和 MySQL 數(shù)據(jù)庫(kù)的存儲(chǔ)模式是有一定的神似之處。

總結(jié)

在今天這篇文章中，我們面向設(shè)計(jì) MQ 中常見(jiàn)的 3 大難點(diǎn)(其實(shí)還有更多，以后再介紹...)進(jìn)行了逐一介紹和說(shuō)明。同時(shí)也針對(duì)業(yè)內(nèi)常見(jiàn)的解決方案進(jìn)行了剖析。

在我們了解了這些細(xì)節(jié)后，在真正應(yīng)用 MQ 時(shí)，就不會(huì)感到那么的無(wú)奈。因?yàn)槌３Ｄ闼龅降模G失，又或是消息重試導(dǎo)致裂變所導(dǎo)致宕機(jī)。

往往都來(lái)自于你所忽略的這些設(shè)計(jì)細(xì)節(jié)之中。即使對(duì)到用戶(hù)端上只是幾個(gè)簡(jiǎn)單的配置，你也應(yīng)當(dāng)理解這些知識(shí) ：)