如果讓你設計一個高併發的訊息中介軟體,你會怎麼做?

冰河團隊發表於2021-01-18

寫在前面

很多小夥伴去大廠面試,幾乎都會遇到一些開放式的題目,這些開放式的題目沒有固定的答案,但是它能夠實實在在的體現面試者較為真實的系統設計能力和技術功底。如果你回答的比較完美,那麼,通過這種開放式題目,就能夠讓你從眾多的面試者中脫穎而出。今天,我們就一起來聊聊,去大廠面試時,一個較為常見的開放式題目:如果讓你設計一個高併發的訊息中介軟體,你會怎麼做?

訊息中介軟體涉及的知識點

要想設計一個具有高併發的訊息中介軟體,那麼首先就要了解下訊息中介軟體涉及哪些具體的知識點。通常,設計一個良好的訊息中介軟體最少需要滿足如下條件:

  • 生產者、消費者模型。
  • 支援分散式架構。
  • 資料的高可用。
  • 訊息資料不丟失。

接下來,我們就針對訊息中介軟體來分別談談這些技術點。

生產者消費者模型

相信很多小夥伴對於生產者和消費者模型都比較瞭解了,簡單的說:就是訊息中介軟體能夠使其他應用來生產訊息,也能夠使其他應用來消費相應的訊息。

對於生產者和消費者模型,我們需要考慮的問題點就比較多了。接下來,我就一步步來引導大家進行思考。

首先,我們來思考這樣一個問題: 如果生產者生產了訊息,那麼訊息中介軟體應該怎樣儲存相應的資料呢? 儲存在記憶體? 儲存在磁碟? 還是同時儲存在記憶體和磁碟中呢?

如果是將訊息資料同時儲存在記憶體和磁碟中,我們又該如何處理這些資料呢? 是生產者將訊息投遞到訊息中介軟體之後,我們就立刻將資料寫入磁碟?還是說資料先駐留到記憶體,然後每隔一段時間刷到磁碟上? 如果是每隔一段時間刷到磁碟上,那我們又要考慮磁碟檔案的切分問題,也就是說,需要將訊息資料分成多少個磁碟檔案?(總不能把所有的資料放到一個磁碟檔案中吧)。如果是需要切分成多個磁碟檔案,那切分的規則又是什麼呢?

上面這些問題都是我們在設計一個訊息中介軟體時需要考慮的問題。然而,這還只是一小部分問題。如果想在面試時脫穎而出,那就還需要繼續往下看,還有一些重要的問題點需要注意。

如果檔案按照一定的規則切分到多個磁碟檔案中了,那是不是還需要管理後設資料來標識資料的具體訊息(就像是Hadoop中的NameNode節點中儲存著DataNode的後設資料資訊,NameNode節點通過這些後設資料資訊就能夠更好的管理DataNode節點)?這些後設資料可以包括:訊息資料的偏移量、也可以是訊息資料的唯一ID。

考慮完資料的儲存問題,我們還需要考慮的是:訊息中介軟體是如何將資料投遞到對應的消費者的?

在設計生產者和消費者時,還一個很重要的問題需要我們考慮:我們在設計訊息中介軟體時,採用的消費模式是什麼?會不會將資料均勻的分配給消費者?還是會通過一些其他的規則將資料投遞到消費者?

支援分散式架構

如果我們設計的訊息中介軟體,每天會承載TB級別的資料高併發和高吞吐量的寫入操作。這裡,我們就需要考慮將訊息中介軟體設計成分散式架構。

在設計分散式架構時,我們還需要考慮將儲存的比較大的資料,做成分片儲存,對資料進行分片等操作。

除了這些,我們還需要考慮另外一個核心問題:對於訊息中介軟體來說,需要支援自動擴容操作。

還有就是是否支援資料分片,如何實現資料分片的擴容和自動資料負載均衡遷移等。

資料的高可用

一般網際網路應用的高可用,是通過本地堆記憶體,分散式快取,和一份資料在不同的伺服器上都搞一個副本來實現的。此時,任何一個儲存節點當機,都不會影響整體的高可用。我們在設計訊息中介軟體時也可以參考這個思路。

訊息資料不丟失

此時,我們就需要提供手動ACK的機制,也就是說:當消費者真正消費訊息完畢後,向訊息中介軟體返回“ 處理完成” 的標識,訊息中介軟體刪除相應的已處理的訊息。

但是,細化的話,這裡,我們就需要兩套ACK機制:

  • 一種ACK對應的是生產端。如果一直沒有接收到ACK訊息,則需要通過生產者來重新傳送一條訊息來保證生產訊息成功。
  • 另一種ACK對應的是消費端。一旦一條訊息消費並處理成功,必須返回一個ack給訊息中介軟體,然後訊息中介軟體才能刪除這條訊息。否則一旦消費者當機,就必須重發這條訊息給其他的消費者例項,保證訊息一定會被處理成功。

今天,我們沒有聊具體的業務點,而是從整體上考慮:如果實現一個訊息中介軟體,需要我們注意的各項知識點和專業技能!好了,今天就到這兒吧,我是冰河,我們下期見大家有啥問題可以在下方留言,也可以加我微信:sun_shine_lyz,我拉你進群,一起交流技術,一起進階,一起牛逼~~

相關文章