1. 程式人生 > >天天都用訊息佇列,卻不知道為啥要用MQ,這就有點尷尬了

天天都用訊息佇列,卻不知道為啥要用MQ,這就有點尷尬了

1、為什麼要使用訊息佇列?

分析:一個用訊息佇列的人,不知道為啥用,有點尷尬。沒有複習這點,很容易被問蒙,然後就開始胡扯了。

回答:這個問題,咱只答三個最主要的應用場景(不可否認還有其他的,但是隻答三個主要的),即以下六個字:解耦、非同步、削峰

(1)解耦

傳統模式:

 

傳統模式的缺點:

  • 系統間耦合性太強,如上圖所示,系統A在程式碼中直接呼叫系統B和系統C的程式碼,如果將來D系統接入,系統A還需要修改程式碼,過於麻煩!

 

中介軟體模式:

 

中介軟體模式的的優點:

  • 將訊息寫入訊息佇列,需要訊息的系統自己從訊息佇列中訂閱,從而系統A不需要做任何修改。

 

(2)非同步

傳統模式:

 

傳統模式的缺點:

  • 一些非必要的業務邏輯以同步的方式執行,太耗費時間。

中介軟體模式:

 

中介軟體模式的的優點:

  • 將訊息寫入訊息佇列,非必要的業務邏輯以非同步的方式執行,加快響應速度

(3)削峰

傳統模式

 

傳統模式的缺點:

  • 併發量大的時候,所有的請求直接懟到資料庫,造成資料庫連線異常

 

中介軟體模式:

 

中介軟體模式的的優點:

  • 系統A慢慢的按照資料庫能處理的併發量,從訊息佇列中慢慢拉取訊息。在生產中,這個短暫的高峰期積壓是允許的。

2、使用了訊息佇列會有什麼缺點?

分析:一個使用了MQ的專案,如果連這個問題都沒有考慮過,就把MQ引進去了,那就給自己的專案帶來了風險。

我們引入一個技術,要對這個技術的弊端有充分的認識,才能做好預防。要記住,不要給公司挖坑!

回答:回答也很容易,從以下兩個個角度來答

  • 系統可用性降低:
  • 你想啊,本來其他系統只要執行好好的,那你的系統就是正常的。
  • 現在你非要加個訊息佇列進去,那訊息佇列掛了,你的系統不是呵呵了。因此,系統可用性降低
  • 系統複雜性增加:
  • 要多考慮很多方面的問題,比如一致性問題、如何保證訊息不被重複消費,如何保證保證訊息可靠傳輸。
  • 因此,需要考慮的東西更多,系統複雜性增大。

但是,我們該用還是要用的。

3、訊息佇列如何選型?

先說一下,博主只會ActiveMQ,RabbitMQ,RocketMQ,Kafka,對什麼ZeroMQ等其他MQ沒啥理解,因此只能基於這四種MQ給出回答。

分析:既然在專案中用了MQ,肯定事先要對業界流行的MQ進行調研,如果連每種MQ的優缺點都沒了解清楚,就拍腦袋依據喜好,用了某種MQ,還是給專案挖坑。

如果面試官問:"你為什麼用這種MQ?。"你直接回答"領導決定的。"這種回答就很LOW了。

還是那句話,不要給公司挖坑。

我們可以看出,RabbitMQ版本釋出比ActiveMq頻繁很多。至於RocketMQ和kafka就不帶大家看了,總之也比ActiveMQ活躍的多。詳情,可自行查閱。

再來一個效能對比表

 

 

 

綜合上面的材料得出以下兩點:

(1)中小型軟體公司,建議選RabbitMQ.

一方面,erlang語言天生具備高併發的特性,而且他的管理介面用起來十分方便。

正所謂,成也蕭何,敗也蕭何!他的弊端也在這裡,雖然RabbitMQ是開源的,然而國內有幾個能定製化開發erlang的程式設計師呢?

所幸,RabbitMQ的社群十分活躍,可以解決開發過程中遇到的bug,這點對於中小型公司來說十分重要。

不考慮rocketmq和kafka的原因是,一方面中小型軟體公司不如網際網路公司,資料量沒那麼大,選訊息中介軟體,應首選功能比較完備的,所以kafka排除。

不考慮rocketmq的原因是,rocketmq是阿里出品,如果阿里放棄維護rocketmq,中小型公司一般抽不出人來進行rocketmq的定製化開發,因此不推薦。

(2)大型軟體公司,根據具體使用在rocketMq和kafka之間二選一

一方面,大型軟體公司,具備足夠的資金搭建分散式環境,也具備足夠大的資料量。

針對rocketMQ,大型軟體公司也可以抽出人手對rocketMQ進行定製化開發,畢竟國內有能力改JAVA原始碼的人,還是相當多的。

至於kafka,根據業務場景選擇,如果有日誌採集功能,肯定是首選kafka了。具體該選哪個,看使用場景。

4、如何保證訊息佇列是高可用的?

分析:在第二點說過了,引入訊息佇列後,系統的可用性下降。在生產中,沒人使用單機模式的訊息佇列。

因此,作為一個合格的程式設計師,應該對訊息佇列的高可用有很深刻的瞭解。

如果面試的時候,面試官問,你們的訊息中介軟體如何保證高可用的?

如果你的回答只是表明自己只會訂閱和釋出訊息,面試官就會懷疑你是不是隻是自己搭著玩,壓根沒在生產用過。

因此,請做一個愛思考,會思考,懂思考的程式設計師。

回答:這問題,其實要對訊息佇列的叢集模式要有深刻了解,才好回答。

以rcoketMQ為例,他的叢集就有多master 模式、多master多slave非同步複製模式、多 master多slave同步雙寫模式。

多master多slave模式部署架構圖(網上找的,偷個懶,懶得畫):

 

其實博主第一眼看到這個圖,就覺得和kafka好像,只是NameServer叢集,在kafka中是用zookeeper代替,都是用來儲存和發現master和slave用的。

通訊過程如下:

Producer 與 NameServer叢集中的其中一個節點(隨機選擇)建立長連線,定期從 NameServer 獲取 Topic 路由資訊,並向提供 Topic 服務的 Broker Master 建立長連線,且定時向 Broker 傳送心跳。

Producer 只能將訊息傳送到 Broker master,但是 Consumer 則不一樣,它同時和提供 Topic 服務的 Master 和 Slave建立長連線,既可以從 Broker Master 訂閱訊息,也可以從 Broker Slave 訂閱訊息。

那麼kafka呢,為了對比說明直接上kafka的拓補架構圖(也是找的,懶得畫)

 

如上圖所示,一個典型的Kafka叢集中包含若干Producer(可以是web前端產生的Page View,或者是伺服器日誌,系統CPU、Memory等),若干broker(Kafka支援水平擴充套件,一般broker數量越多,叢集吞吐率越高),若干Consumer Group,以及一個Zookeeper叢集。

Kafka通過Zookeeper管理叢集配置,選舉leader,以及在Consumer Group發生變化時進行rebalance。

Producer使用push模式將訊息釋出到broker,Consumer使用pull模式從broker訂閱並消費訊息。

至於rabbitMQ,也有普通叢集和映象叢集模式,自行去了解,比較簡單,兩小時即懂。

要求,在回答高可用的問題時,應該能邏輯清晰的畫出自己的MQ叢集架構或清晰的敘述出來。

5、如何保證訊息不被重複消費?

分析:這個問題其實換一種問法就是,如何保證訊息佇列的冪等性?

這個問題可以認為是訊息佇列領域的基本問題。換句話來說,是在考察你的設計能力,這個問題的回答可以根據具體的業務場景來答,沒有固定的答案。

回答:先來說一下為什麼會造成重複消費?

其實無論是那種訊息佇列,造成重複消費原因其實都是類似的。

正常情況下,消費者在消費訊息時候,消費完畢後,會發送一個確認資訊給訊息佇列,訊息佇列就知道該訊息被消費了,就會將該訊息從訊息佇列中刪除。只是不同的訊息佇列傳送的確認資訊形式不同

例如RabbitMQ是傳送一個ACK確認訊息,RocketMQ是返回一個CONSUME_SUCCESS成功標誌,kafka實際上有個offset的概念

簡單說一下(如果還不懂,出門找一個kafka入門到精通教程),就是每一個訊息都有一個offset,kafka消費過訊息後,需要提交offset,讓訊息佇列知道自己已經消費過了。

那造成重複消費的原因?

就是因為網路傳輸等等故障,確認資訊沒有傳送到訊息佇列,導致訊息佇列不知道自己已經消費過該訊息了,再次將該訊息分發給其他的消費者。

如何解決?這個問題針對業務場景來答分以下幾點

(1)比如,你拿到這個訊息做資料庫的insert操作。

那就容易了,給這個訊息做一個唯一主鍵,那麼就算出現重複消費的情況,就會導致主鍵衝突,避免資料庫出現髒資料。

(2)再比如,你拿到這個訊息做redis的set的操作

那就容易了,不用解決。因為你無論set幾次結果都是一樣的,set操作本來就算冪等操作。

(3)如果上面兩種情況還不行,上大招。

準備一個第三方介質,來做消費記錄。以redis為例,給訊息分配一個全域性id,只要消費過該訊息,將以K-V形式寫入redis。那消費者開始消費前,先去redis中查詢有沒消費記錄即可。

6、如何保證消費的可靠性傳輸?

分析:我們在使用訊息佇列的過程中,應該做到訊息不能多消費,也不能少消費。如果無法做到可靠性傳輸,可能給公司帶來千萬級別的財產損失。

同樣的,如果可靠性傳輸在使用過程中,沒有考慮到,這不是給公司挖坑麼,你可以拍拍屁股走了,公司損失的錢,誰承擔。

還是那句話,認真對待每一個專案,不要給公司挖坑

回答:其實這個可靠性傳輸,每種MQ都要從三個角度來分析:生產者弄丟資料、訊息佇列弄丟資料、消費者弄丟資料

RabbitMQ

(1)生產者丟資料

從生產者弄丟資料這個角度來看,RabbitMQ提供transaction和confirm模式來確保生產者不丟訊息。

transaction機制就是說,傳送訊息前,開啟事物(channel.txSelect()),然後傳送訊息,如果傳送過程中出現什麼異常,事物就會回滾(channel.txRollback()),如果傳送成功則提交事物(channel.txCommit())。

然而缺點就是吞吐量下降了。因此,按照博主的經驗,生產上用confirm模式的居多。

一旦channel進入confirm模式,所有在該通道上面釋出的訊息都將會被指派一個唯一的ID(從1開始)

一旦訊息被投遞到所有匹配的佇列之後,rabbitMQ就會發送一個Ack給生產者(包含訊息的唯一ID)

這就使得生產者知道訊息已經正確到達目的隊列了.如果rabiitMQ沒能處理該訊息,則會發送一個Nack訊息給你,你可以進行重試操作。

處理Ack和Nack的程式碼如下所示(說好不上程式碼的,偷偷上了):

 

(2)訊息佇列丟資料

處理訊息佇列丟資料的情況,一般是開啟持久化磁碟的配置。

這個持久化配置可以和confirm機制配合使用,你可以在訊息持久化磁碟後,再給生產者傳送一個Ack訊號。

這樣,如果訊息持久化磁碟之前,rabbitMQ陣亡了,那麼生產者收不到Ack訊號,生產者會自動重發。

那麼如何持久化呢,這裡順便說一下吧,其實也很容易,就下面兩步

1、將queue的持久化標識durable設定為true,則代表是一個持久的佇列

2、傳送訊息的時候將deliveryMode=2

這樣設定以後,rabbitMQ就算掛了,重啟後也能恢復資料

(3)消費者丟資料

消費者丟資料一般是因為採用了自動確認訊息模式。

這種模式下,消費者會自動確認收到資訊。這時rahbitMQ會立即將訊息刪除,這種情況下如果消費者出現異常而沒能處理該訊息,就會丟失該訊息。

至於解決方案,採用手動確認訊息即可。

kafka

 

Producer在釋出訊息到某個Partition時,先通過ZooKeeper找到該Partition的Leader

然後無論該Topic的Replication Factor為多少(也即該Partition有多少個Replica),Producer只將該訊息傳送到該Partition的Leader。

Leader會將該訊息寫入其本地Log。每個Follower都從Leader中pull資料。

針對上述情況,得出如下分析

(1)生產者丟資料

在kafka生產中,基本都有一個leader和多個follwer。follwer會去同步leader的資訊。

因此,為了避免生產者丟資料,做如下兩點配置

  1. 第一個配置要在producer端設定acks=all。這個配置保證了,follwer同步完成後,才認為訊息傳送成功。
  2. 在producer端設定retries=MAX,一旦寫入失敗,這無限重試

(2)訊息佇列丟資料

針對訊息佇列丟資料的情況,無外乎就是,資料還沒同步,leader就掛了,這時zookpeer會將其他的follwer切換為leader,那資料就丟失了。

針對這種情況,應該做兩個配置。

  1. replication.factor引數,這個值必須大於1,即要求每個partition必須有至少2個副本
  2. min.insync.replicas引數,這個值必須大於1,這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯絡

這兩個配置加上上面生產者的配置聯合起來用,基本可確保kafka不丟資料

(3)消費者丟資料

這種情況一般是自動提交了offset,然後你處理程式過程中掛了。kafka以為你處理好了。

再強調一次offset是幹嘛的

offset:指的是kafka的topic中的每個消費組消費的下標。

簡單的來說就是一條訊息對應一個offset下標,每次消費資料的時候如果提交offset,那麼下次消費就會從提交的offset加一那裡開始消費。

比如一個topic中有100條資料,我消費了50條並且提交了,那麼此時的kafka服務端記錄提交的offset就是49(offset從0開始),那麼下次消費的時候offset就從50開始消費。

解決方案也很簡單,改成手動提交即可。

ActiveMQ和RocketMQ

大家自行查閱吧

7、如何保證訊息的順序性?

分析:其實並非所有的公司都有這種業務需求,但是還是對這個問題要有所複習。

回答:針對這個問題,通過某種演算法,將需要保持先後順序的訊息放到同一個訊息佇列中(kafka中就是partition,rabbitMq中就是queue)。然後只用一個消費者去消費該佇列。

有的人會問:那如果為了吞吐量,有多個消費者去消費怎麼辦?

這個問題,沒有固定回答的套路。比如我們有一個微博的操作,發微博、寫評論、刪除微博,這三個非同步操作。如果是這樣一個業務場景,那隻要重試就行。

比如你一個消費者先執行了寫評論的操作,但是這時候,微博都還沒發,寫評論一定是失敗的,等一段時間。等另一個消費者,先執行寫評論的操作後,再執行,就可以成功。

總之,針對這個問題,我的觀點是保證入隊有序就行,出隊以後的順序交給消費者自己去保證,沒有固定套路。

總結

寫到這裡,希望讀者把本文提出的這幾個問題,經過深刻的準備後,一般來說,能囊括大部分的訊息佇列的知識點。

如果面試官不問這幾個問題怎麼辦,簡單,自己把幾個問題講清楚,突出以下自己考慮的全面性。

最後,其實我不太提倡這樣突擊複習,希望大家打好基本功,做一個愛思考,懂思考,會思考的程式