Java進階必備：優雅的告訴面試官消息中間件該如何實現高可用架構？【石杉的架構筆記】

時間 2019-11-07

標籤 java 進階必備優雅告訴面試消息中間件如何實現可用架構石杉的架構筆記欄目 Java 简体版

原文原文鏈接

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）程序員

週一至週五早8點半！精品技術文章準時送上！面試

（1）背景引入

這篇文章，咱們來聊一下消息中間件高可用架構的一些原理。微服務

對於一個合格的高級Java工程師而言，你確定會碰到在系統裏用到MQ的場景，那麼這個時候你須要基於你的業務場景和需求，考慮在使用MQ的時候可能遇到的一些技術問題。高併發

接着，你必須得針對這些技術問題設計一套完整的技術方案。

你須要從消息的訂閱模式、消息的生產到消費全鏈路不丟數據、消息中間件自己如何保證高可用，等各個角度切入，來考慮好你的系統和MQ對接以後的完整技術方案。

因此，本文就來聊聊消息中間件高可用的架構原理。

（2）先來思考一下消息中間件的可用性問題

我們先拋開各類具體的技術，就來思考一下，啥是MQ的可用性問題？

你們看看下面的圖，其實道理很簡單，假如你的MQ就部署在一臺機器上，那麼正常狀況下，生產者都會發送消息到MQ去，而後讓消費者獲取到。

可是萬一天有不測風雲，MQ部署的那臺機器，由於一些莫名的緣由，MQ本身自己的進程掛掉了，或者是那臺機器直接就宕機了，那麼此時怎麼辦呢？

很尷尬，是否是，結果是很明顯的，生產者無法發送數據出去，而後消費者也無法獲取到數據了。

而後整個系統不就完蛋了？由於系統的核心流程根本沒法跑通了，對不對？

MQ宕機就直接致使你的系統自己也故障了，而後可能會致使你的公司對外的APP、網站等產品就沒法運做了，用戶沒法使用大家公司的服務了。

若是大家公司是電商平臺、外賣平臺、社交平臺。那麼來這麼一出，不是會致使公司損失慘重？

若是你的系統持續幾個小時沒法被人使用，原本你公司電商平臺一天營收能夠達到1億，結果如今致使幾個小時內沒法下單購買商品，最後當天營收就5000萬，那麼你的公司是否是直接活生生損失了5000萬？

這個真的不是開玩笑的，若是你們留意互聯網行業的新聞的話和小道消息的話，就應該知道近幾年一些大型互聯網公司都出現過相似的狀況，損失慘重，我們作碼農的就得被祭天了是否是？

（3）集羣化部署 + 數據多副本冗餘

好，問題來了！如今你感受一個MQ中間件應該如何實現高可用呢？

這裏的方式有不少種，好比說數據多副本冗餘，集羣鏡像同步機制，咱們就拋開具體的技術來從本質層面思考一下MQ集羣實現高可用的幾種方式。

先來看下面的一張圖，假設咱們寫到MQ的數據都被多副本冗餘了，也就是你寫的每一條消息都被複制到了其餘的機器上去了。

那麼此時任何一臺機器宕機，彷佛都不會影響咱們跟MQ繼續通訊，並且寫出去的數據彷佛也都還在。

上面的圖裏，MQ採用集羣模式部署到了2臺機器上去，而後生產者給其中一臺機器寫入一條消息，該機器自動同步複製給另一臺機器。

此時數據在2臺機器上，就有2個副本了，那麼若是第一臺機器宕機了，會影響咱們嗎？

答案是：不會。

由於數據自己是多副本冗餘的，此時消費者徹底能夠從第二臺機器消費到這條消息，而且生產者還能夠繼續給第二臺機器寫入消息，數據沒丟失。

並且，系統根本不用中斷流程，還能夠繼續運行，咱們看下面的圖。

這種感受是否是很棒？實際上這種MQ集羣化部署架構以及數據多副本冗餘機制，是很是常見的一種高可用架構。

Kafka這個極爲優秀的消息中間件，就是採用的這種架構保證高可用、數據容錯性。

（4）多副本同步複製強制要求

可是這裏你要思考另外幾個問題，第一個就是：你在寫數據到其中一臺機器的時候，是否是得要求，必須得讓那臺機器複製數據到另一臺機器了，保證集羣裏必定有這條數據雙副本了，才能夠認爲本次寫成功了？

沒錯，假如你要是不能保證這一點，好比你就寫數據給了其中一臺機器，而後他還沒來得及複製給另一臺機器呢，直接第一臺機器就宕機了。

此時雖然你能夠繼續基於第二臺機器發送消息和消費消息，可是你剛纔發送的一條消息就丟失了。

你們看下面的圖來理解一下這個場景。

因此對於採用這種機制的時候，你必須得讓生產者經過一些參數的設置，保證說寫一條消息到某臺機器，他必須同步這條消息到另一臺機器成功，集羣裏有雙副本了，而後此時才能夠認爲這條消息寫成功了。

但凡剛寫一臺機器他就宕機，還沒來得及複製到另一臺機器的話，本次寫應該報錯失敗，而後你應該重試再次寫入數據到MQ集羣裏去。

你們看看下面的圖。只要你一次寫成功了，他就保證確定已經同步數據爲雙副本了，此時哪怕一臺機器宕機，數據不會丟失，生產和消費均可以有條不紊的繼續進行。

（5）多機器承載多副本強制要求

第二個問題，假如說如今你的集羣中原本有兩臺機器，如今宕機了其中的一臺，只有一臺機器了，你還能容許你的生產者對惟一的一臺機器繼續寫入數據嗎？

答案是：否。

由於若是集羣裏只有一臺機器能夠承載寫入，那麼萬一剩餘的一臺機器又宕機了呢？是否是仍是會致使數據丟失，集羣完蛋？

因此說，你的生產者同理應該基於參數設置一下，集羣裏必須有超過2臺機器能夠接收你的數據副本複製。

不然若是隻有1臺機器能夠接受你的數據副本複製的話，那麼仍是算了。

你們看看下面的圖，感覺一下那個場景。

假設集羣裏有3臺機器，那麼其中一臺宕機了，你後續再寫入另一臺的時候，判斷一下集羣裏還有剩餘兩臺機器，足以保證數據雙副本的高可用性和容錯性，因此能夠繼續正常的寫入數據到MQ集羣裏去。

實際上，上面說的那一整套的機制，在Kafka裏均可以採用，他有對應的一些參數能夠配置數據有幾個副本，包括你每次寫入必須複製到幾臺機器才能夠算成功，不然就要從新發送，以及你的集羣剩餘機器必須能夠承載幾個副本才能繼續寫入數據。

經過這一整套方案的設計和基於具體技術的落地，才能夠保證在集羣化部署的狀況下，集羣必須有幾臺機器承載多副本，同時數據寫入以後必須是保證多副本冗餘的。

此時，任何機器宕機，數據都不會丟失，還能夠正常讓系統繼續運行。

（6）架構原理與技術無關性

其實本文對消息中間件的集羣高可用架構的探討，是徹底脫離於某個具體技術的，很是樸素的從本質的原理層面來討論這個話題。

具體的RabbitMQ、Kafka、RocketMQ等各類不一樣的消息中間件，對這種高可用架構的實現，都有必定的類似想通性，可是也都有各自不一樣的技術實現，以及相對應的區別。

後面咱們再經過不一樣的文章，以各類MQ中間件的具體技術實現舉例來討論一下相關的架構是如何落地的。

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授