開篇思考

1. MQ 為什么在系統(tǒng)中使用？一定要在分布式系統(tǒng)中使用嗎？
2. MQ 有哪些中間件？他們有哪些特點(diǎn)？
3. MQ 給系統(tǒng)帶來好處的同時(shí)有沒有帶來什么問題？如何解決？

在阿里的面試中，面試官問到關(guān)于 MQ 的幾個(gè)問題：

• 你的項(xiàng)目中 MQ 的作用？
• 為什么選擇這款 MQ 作為消息中間件？
• 重復(fù)消費(fèi)怎么辦？
• 如何確保消息被消費(fèi)？
• 有遇到其他問題嗎？
  那么接下來帶著問題先思考下，有好的想法可以在評(píng)論區(qū)留言，大家一起分享。

消息中間件在系統(tǒng)中的使用

我之前寫過一篇關(guān)于 rocketMQ 實(shí)現(xiàn)分布式鎖的文章，主要介紹如何使用 RocketMQ 實(shí)現(xiàn)分布式鎖，
《Springcloud + RocketMQ 解決分布式事務(wù)》
但是這個(gè)功能并不是 MQ 基本功能，也不是所有 MQ 都有的功能。

MQ 在系統(tǒng)中到底有哪些作用呢？拋開基本的消息發(fā)布訂閱不說，還有以下幾點(diǎn)：

1. 分布式系統(tǒng)解耦
2. 不需要立即返回的業(yè)務(wù)異步處理
3. 削峰填谷，不直接訪問服務(wù)，緩解服務(wù)壓力，增加性能
4. 日志記錄

分布式系統(tǒng)解耦

解耦

在分布式系統(tǒng)中，要么是通過 rest 調(diào)用，要么是通過 dubbo 等 RPC 調(diào)用，但是有些場(chǎng)景需要解耦設(shè)計(jì)，不能直接調(diào)用。
比如消息驅(qū)動(dòng)的系統(tǒng)中，消息發(fā)送者完成本地業(yè)務(wù)，發(fā)送消息，多平臺(tái)的消息消費(fèi)者服務(wù)需要收到推送的消息，然后繼續(xù)處理其他業(yè)務(wù)。

看這兩個(gè)架構(gòu)圖，第一種 BC 都直接依賴 A 服務(wù)，那么如果 A 中的接口修改，BC 都要跟著做修改，耦合度高。
第二種，通過 MQ 來作為中間件收發(fā)消息，BC 只依賴收到的消息而不是具體的接口，這樣即使 A 服務(wù)修改或者增加其他服務(wù)，都只要訂閱MQ就行。

不要求實(shí)時(shí)的業(yè)務(wù)異步處理

用戶注冊(cè)業(yè)務(wù)流程為例，

1. 用戶注冊(cè)入庫(kù)
2. 用戶驗(yàn)證郵件發(fā)送
3. 用戶驗(yàn)證短信發(fā)送

原來的系統(tǒng)設(shè)計(jì)，這樣的服務(wù)流程會(huì)串行處理，即先 1-2-3 ；但是這里可以思考下，如果單個(gè)服務(wù)單臺(tái)機(jī)器的情況下，注冊(cè)用戶特別多，系統(tǒng)能不能抗住？

這里假設(shè)各個(gè)階段的時(shí)間 1 = 50ms ， 2 = 50ms ， 3 = 50ms，那么一個(gè)請(qǐng)求下來就是 all = 150ms；
這里再假設(shè)，這個(gè)服務(wù)器 CPU = 1 ， 且只能處理單線程，那么以這種單臺(tái)服務(wù)器單線程的 QPS 來算；QPS = 1000/150 ≈ 7
現(xiàn)在我要讓這個(gè) QPS * 3 提升三倍，這個(gè)時(shí)候引入 MQ 服務(wù)作為中間件

異步

如圖可見，我在 A 服務(wù)用戶注冊(cè)完成后，就直接返回了，這個(gè)時(shí)候 MQ 用來發(fā)送異步處理消息，B，C 服務(wù)分別處理。
A 不用等待 B、C 的返回結(jié)果 ，這樣用戶體驗(yàn)就是只有 50ms 等待時(shí)間。而在郵件、短信這個(gè)階段，因?yàn)榫W(wǎng)絡(luò)延遲原因，
用戶可以接受一定時(shí)間的等待。

削峰填谷

一般的服務(wù)，我們的請(qǐng)求訪問到系統(tǒng)都是直接請(qǐng)求，這樣的模式在用戶訪問量不大的情況下，問題不是很大。
但是如果用戶請(qǐng)求達(dá)到了一定的瓶頸或者產(chǎn)生了一些問題，我們就需要考慮優(yōu)化我們的架構(gòu)設(shè)計(jì)，MQ 中間件正是解決辦法之一。

下面以秒殺系統(tǒng)為例分析問題
秒殺系統(tǒng)瞬間百萬并發(fā)，怎么處理？一般秒殺系統(tǒng)會(huì)進(jìn)行請(qǐng)求過濾，無效、重復(fù)都會(huì)被過濾一遍，剩下的才真正進(jìn)入到秒殺服務(wù)、訂單服務(wù)。
但即使這樣并發(fā)仍然很高，如果網(wǎng)關(guān)把全部請(qǐng)求都轉(zhuǎn)發(fā)到下游訂單服務(wù)，一樣會(huì)壓垮下游系統(tǒng)，造成服務(wù)不可用甚至雪崩。

秒殺的隊(duì)列使用

真實(shí)的秒殺系統(tǒng)更復(fù)雜 ，包含 Nginx 、網(wǎng)關(guān)、注冊(cè)中心、redis 緩存、mysql 集群、消息隊(duì)列集群

解決方式就是將上游處理的較快的任務(wù)，加入到隊(duì)列處理，下游逐一消費(fèi)隊(duì)列，直到所有隊(duì)列消費(fèi)完成。
假如秒殺服務(wù)處理請(qǐng)求數(shù)：1000/s，
下游訂單服務(wù)處理請(qǐng)求書：10/s，
為了不給下游訂單服務(wù)造成壓力，秒殺后的信息發(fā)送到隊(duì)列，訂單服務(wù)就可以從容淡定的每秒處理十個(gè)，而不是直接塞 1000 個(gè)請(qǐng)求
也不管人家愿意不愿意。

到這里，可以總結(jié)下秒殺系統(tǒng)的過濾方式：

1. 頁(yè)面按鈕點(diǎn)擊一次置灰
2. 每秒透過請(qǐng)求數(shù)限制，例如 100/s，可以使用 Nginx ，sentinel
3. 過濾同一用戶的重復(fù)請(qǐng)求，通過用戶唯一標(biāo)識(shí)、商品信息，
4. 通過消息隊(duì)列存儲(chǔ)成功的秒殺信息，下游訂單系統(tǒng)處理

日志

所有服務(wù)都將日志發(fā)送到 MQ 服務(wù)用來作為日志存儲(chǔ)。
MQ 作為中間件對(duì)日志進(jìn)行持久化、轉(zhuǎn)發(fā)
大數(shù)據(jù)服務(wù)對(duì) MQ 讀取和進(jìn)行日志分析

日志處理基本流程

MQ 怎么選

有人上來就是一通性能比較，然后說 RabbitMQ 是世界上最好的 MQ...
你把挑選 MQ 比作挑老婆吧，上來就要全套，膚白貌美、前凸后翹、性感火辣、勤勞能干。。。
真是缺乏社會(huì)的教育啊，兄弟
養(yǎng)得起嗎？動(dòng)不動(dòng)一套保養(yǎng)套餐，1W/月
守得住嗎？隔壁老王經(jīng)常來你家吃飯吧，瘋狂腦補(bǔ)。。。
吃的消嗎？紅棗+枸杞+腎寶片，怕是心有余力不足吧

言歸正傳，其實(shí)我覺得這是一個(gè)思考題，首先我們要看的應(yīng)該是條件是哪些？

1. 用途？是用來做日志、解耦、還是異步處理
2. 公司情況？人員是否充足，現(xiàn)有人員技術(shù)棧情況，人員的技術(shù)棧實(shí)力
3. 項(xiàng)目情況？項(xiàng)目周期，人員，用戶量，架構(gòu)設(shè)計(jì)，是否老項(xiàng)目
4. 主流 MQ 現(xiàn)狀？穩(wěn)定可靠度，社區(qū)活躍度，文檔全面性，云服務(wù)支持情況

上圖的例子日志消息就是使用的 kafka，為什么是kafka？
Kafka是LinkedIn開源的分布式發(fā)布-訂閱消息系統(tǒng)，屬于 Apache 頂級(jí)項(xiàng)目，社區(qū)活躍。
Kafka主要特點(diǎn)是基于Pull的模式來處理消息消費(fèi)，追求高吞吐量，一開始的目的就是用于日志收集和傳輸。
后來版本開始支持復(fù)制，不支持事務(wù)，對(duì)消息的重復(fù)、丟失、錯(cuò)誤沒有嚴(yán)格要求，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。
但是 kafka 相對(duì)來說很重，需要依賴 zookeeper，大公司里使用沒問題，也少不了專人維護(hù)。

RocketMQ 是阿里開源的一套可靠消息系統(tǒng)，已經(jīng)捐贈(zèng) Apache 成為頂級(jí)項(xiàng)目。剛開始定位于非日志的可靠消息傳輸，其實(shí)在日志處理方面性能也不錯(cuò)。
目前支持的客戶端包括 java，c++，GO ，社區(qū)比較活躍，文檔還算全面。但是涉及到核心的要修改還是有難度的，畢竟阿里云靠賣這個(gè)服務(wù)賺錢呢。
所以如果公司實(shí)力不自信還是慎重選擇吧，實(shí)在不行可以直接購(gòu)買云服務(wù)，省心省力，還是那句話，看實(shí)際情況。

主流 MQ 的特點(diǎn)

下圖是來源網(wǎng)絡(luò)的圖片，部分描述已經(jīng)過時(shí)，但是基本不差，僅供參考：

主流 MQ 比較（網(wǎng)絡(luò)圖）

如何確保消息不被重復(fù)消費(fèi)

這里簡(jiǎn)單說說，后面專門針對(duì)這個(gè)問題進(jìn)行書寫招供。
大致就是一些特殊原因例如網(wǎng)絡(luò)原因，服務(wù)重啟造成消息消費(fèi)未被記錄，造成重復(fù)消費(fèi)的可能。
一般的處理方式就是保證接口設(shè)計(jì)的冪等性，主旨通過唯一標(biāo)識(shí)判斷是否存在。

1. redis 緩存使用，唯一性 token 保存redis，每次消費(fèi)后刪除 token
2. 唯一主鍵判斷，數(shù)據(jù)庫(kù)判斷是否存在該主鍵記錄，存在則更新，不存在則插入

喜歡文章請(qǐng)關(guān)注我

程序領(lǐng)域
點(diǎn)擊關(guān)注+轉(zhuǎn)發(fā)，私信發(fā)送【面試】或者【資料】可以收獲更多資源

公眾號(hào)