想使用消息隊列,先考慮下這些問題!

消息隊列優勢

消息隊列(Message Queue,簡稱MQ),其主要用于在復雜的微服務系統中進行消息通信,它的優點可以大致整理成以下幾點:

  1. 服務間解耦
  2. 提高服務并發、性能
  3. 突發流量削峰
  4. ...

服務間解耦

微服務系統業務之間相互依賴,各種調用錯綜復雜,如果不能良好對服務進行解耦那一個服務的可用性、并發都會受到其他服務的影響。

在沒有引用MQ的之前服務調用大概是這些步驟:

圖上的A服務是直接調用的,這是沒啥問題的,但是服務上線后要迭代更新的麻,這個時候要是服務C的開發人員有點代碼小潔癖說:我這個C服務接口命名不太好,我需要重新更新下,當A服務的小哥哥還戴著小耳機聽著小歌曲,突然就得改代碼了~~。

后來負責服務C的那小哥哥也不好意思了,提出大家一起使用MQ吧,于是A、C的調用就變成下面這個樣子了:

服務A不直接調用C而是向消息隊列中發送消息(生產者),另一邊的C取出隊列中的消息(消費者)進行處理,這樣A、C就完成了解耦。

提高服務并發、性能

舉個例子,在沒引入MQ之前服務調用多個服務都是同步調用,比如像這樣:

服務A要順序的調用B、C服務來完成業務邏輯如果A->B需要200ms,A->C需要200ms,再加上自身業務邏輯處理可能需要花費500ms,其中有400ms是調用A和B的花費,明明自身100ms就能處理完還白白浪費400ms,不能忍啊于是可以引入MQ做一下改造:

這下有了MQ,A服務只需要發一條消息比如花費50ms,再加上自身業務邏輯的100ms,那整個調用過程只需要花費150ms了,這樣對并發和性能都有一定的改善。

突發流量削峰

突發流量就是互聯網很常見的情況,有時候有熱點、突發事件,那平常QPS為100的接口,突然提升10-20倍這個時候沒有MQ所有流量直接進入服務,這對服務和數據庫都是很大的挑戰:

再次引入MQ就情況就不一樣了,服務A先將請求丟給MQ,然后可以慢慢消費掉:

消息隊列帶來的一些問題

使用MQ還有很多好處,但是他也會帶一些麻煩事。首先就是會降低系統的可用性,比如MQ掛了怎么辦呢?所以在引入MQ之前就需要考慮之后帶來的哪些問題,不能只看它的好處也需要考慮它不好的地方。比如下面列出的這些問題要如果解決:

  1. 如何保證消息隊列的高可用?
  2. 如何保證消息不被重復消費?
  3. 如何保證消息不丟失?
  4. 如何保證消息的消費順序?

下面我們來分析下這些問題。

如何保證消息隊列的高可用?

如果是單機消息隊列,一臺機器掛了消息隊列都就不用了,這是不能接受的,如果是一個消息隊列群集,一臺機器掛了還有其他機器能正常提供服務,所以要保證消息隊列的高可用,我們就需要做消息隊列集群。

以RabbitMQ為例它有兩種集群模式:

  1. 普通模式
  2. 鏡像模式

普通模式

普通模式,RabbitMQ會同步各個節點的數據/狀態,但不包括消息隊列,默認情況下,消息隊列駐留在一個節點上,盡管它們在所有節點上都是可見且可訪問的。

在這種模式下,每個節點都有會所有節點的元數據信息,所以當發送消息到隊列時,無論連接的是哪一個節點都能正確的發送,但是節點只會同步其他節點的元數據,消息隊列的數據還是在一個節點上,如果這個節點掛了那就意味著發消息就會失敗,無法保證消息隊列的高可用。

鏡像模式

默認情況下,RabbitMQ中Queue與Binding、Exchange不一樣,它只會存于聲明隊列的節點中,但是可以選擇使Queue跨多個節點進行鏡像。

每一個鏡像隊列由一個Master和一個或多個鏡像組成,任何隊列的的操作,都會先應用到Master節點上然后傳播到多個鏡像節點。如果Master節點掛了,最老的鏡像節點將會成為新的Master節點。

總結

RabbitMQ有兩種集群方法:普通模式鏡像模式,要實現消息隊列的高可用可以選一種合適的集群方式來達到,關于RabbitMQ的集群搭建方式,由于篇幅有限這里就不多說,可自行查看 Distributed RabbitMQ文章。

如何保證消息不被重復消費?

想象下消費者收到重復的消息會發生什么情況,比如訂單支付消息,如果支付服務收到兩條重復的消息讓用戶去支付兩次,那用戶肯定是不愿意的,明明已經支付過了還要支付。

如上圖中第四步消費消息B的時候失敗了,如果支付服務在做完業務之后,發送ACK之前服務掛了,MQ沒有收到ACK,由于消息還存在隊列中,服務恢復正常后會再次收到消息,如果支付不做檢查那用戶就會發生兩次支付。

要避免這個重復消費的問題,可以在消費端引入內存、Redis、數據庫來保存消息消費記錄,根據消息Id來判斷消息是否已經被消費過。

如何保證消息不丟失?

假設有訂單服務和支付服務,正常流程是用戶下單成功,然后向支付服務發送支付消息,這里面就涉及訂單服務、支付服務、MQ的交互了,消息丟失可以分為三種情況:

  1. 生產者消息丟失
  2. MQ消息丟失
  3. 消費者消息丟失

生產者消息丟失

生產者消息丟失,可以使用本地消息表解決、消息確認/重發等方式來解決。以RabbitMQ為例,它有confirm機制,發出去的消息是否入隊列,會使用回調的形式告知生產者,生產者收到消息后判斷是Ack還是Nak,如果是Nak則重發消息。

此時還會有問題,如果極端情況下訂單服務掛了,再次重啟后消息就真丟失了,所以最好還是在生產中對消息做持久化,待訂單服務恢復后使用Job重新發送消息。

MQ消息丟失

MQ消息丟失一般為未開啟持久化,MQ掛了再次重啟后消息丟失,所以應當將消息持久化到磁盤中。如果MQ收到消息后在同步到磁盤之前MQ掛了,那磁盤中也沒有消息,這樣還是會導致消息丟失消息,不過這只是小概率事件。

消費者消息丟失

消費者消息丟失,大都為開啟了autoAck選項,消費者收到消息后還未完成處理,此時服務掛了,由于開啟了autoAck, MQ會以為此消息已經被成功消費,將消息從隊列中移除,而服務恢復過后也不會收到原來的消息了。

如果保證消息的消費順序?

有些場景下要保持消息的順序消費怎么辦?比如寫Log都是一條條打印出來,如果發到消息隊列后出現消費順序不一致那消息的那日志就會亂掉,給看日志的人帶來不必要的麻煩。比如為了加快日志的處理速度使用三個消費都處理日志:

按圖上的流程,消費者A、B、C可能分別消費日志1、2、3,這時候就無法保證消息的處理順序。要保證消息的消費順序,首先讓消息都發送到同一個隊列,然后使用一個消費者去處理消息:

這樣消息的處理速度就大大降低,要保持消息的順序,則又想讓消息的處理速度不至于太慢,可以引用本地隊列:





《架構文摘》每天一篇架構領域重磅好文,涉及一線互聯網公司應用架構(高可用、高性 能、高穩定)、大數據、機器學習等各個熱門領域。

posted @ 2019-10-26 13:55  架構文摘  閱讀(...)  評論(... 編輯 收藏
三d开奖结果走势图